ZFX + Developia

Verfasst: **27.04.2012, 11:39**

So langsam versteh ich, warum Code in China Geld kostet: Der ist einfach billig. Im negativen Sinn. Am Ende schauen sich das dann doch 1-2 Leute von uns an und schreiben Teile neu, weil es so nicht ins System passt :?

Verfasst: **27.04.2012, 19:36**

Doxygen at its best:

Source:

Code: Alles auswählen

namespace A
{
	class Foo
	{
	};
}

namespace B
{
	using namespace A;
	class Foo
	{
	};
	class Bar : public B::Foo
	{
	};
}

Doxygens Inheritance Diagram:
B::Foo
B::Bar : public A::Foo

Argh :x

Wozu habe ich denn bitte schön Namespaces, wenn ich dann aufgrund des Doku-Tools doch wieder Präfixes brauche?

EDIT: Habe den Reproduziercode mal gefixt, so dass das Problem tatsächlich damit auftritt, und ihn auch simplifiziert . Das Problem ist offensichtlich das "using namespace". Der Compiler hat dagen hingegen keine Probleme.
Im Originalcode ist das using natürlich in einer Sourcedatei, während die Deklarationen in Headern sind, sonst könnt ich mir die namespaces ja gleich sparen.

Verfasst: **28.04.2012, 14:36**

Ein halber Tag DirectCompute, und schon fangen GPU-beschleunigte Anwendungen (Browser, Plugins) an zu spinnen. :roll:

Verfasst: **28.04.2012, 20:27**

Und es stellte sich heraus, dass eine default-konstruierte std::map eben doch gleich was allokiert. Damit verbietet es sich, dass ich all meinen Objekten eine Sammlung beliebiger Eigenschaften mitgebe - die werden nur selten genutzt, aber wenn selbst die Nicht-Nutzung so teuer ist, kann ich das nicht verantworten.

Verfasst: **29.04.2012, 12:12**

Micrsofts Umschreibung für Sie können die Datei nicht überschreiben, da sie in einem anderen Programm gemappt ist.

: mapped.png (9.69 KiB) 5228 mal betrachtet

Verfasst: **29.04.2012, 12:36**

sizeof(A::B) ist verboten?!? Und wo wir schon dabei sind, warum gibt es kein offsetof(A::B) ...

Verfasst: **29.04.2012, 13:17**

Krishty hat geschrieben:Micrsofts Umschreibung für Sie können die Datei nicht überschreiben, da sie in einem anderen Programm gemappt ist.

Ich würde ja fast sagen, dass das an deiner deutschen Windows-Version liegt. Aber dazu müsste man mit der englischen Meldung vergleichen ;)

Verfasst: **29.04.2012, 13:49**

FormatMessage hat geschrieben:The requested operation cannot be performed on a file with a user-mapped section open.

Ein 08/15-Benutzer kann so wie so weder mit der deutschen noch der englischen Fehlermeldung etwas anfangen. ;)

Verfasst: **29.04.2012, 13:58**

eXile hat geschrieben:
FormatMessage hat geschrieben:The requested operation cannot be performed on a file with a user-mapped section open.
Ein 08/15-Benutzer kann so wie so weder mit der deutschen noch der englischen Fehlermeldung etwas anfangen. ;)

Das ist vollkommen richtig, aber die englische Message hätte Krishty mehr geholfen, right?

Verfasst: **29.04.2012, 14:17**

Eine interessante Frage ist: Würde die Fehlermeldung anders aussehen, falls ich die Datei beim Mappen nicht schließen würde? (Meine File Mapping-Funktion ist ziemlich hoch optimiert.) Gleich mal ausprobieren.

Vorher:
Blah::FooFile foo(reinterpreted<ASCIICharacter>(fileRepository[Text::range("i\\dont.care")])); // warning C4709: comma operator within array index expression
wtf

Nachtrag: Wow; tatsächlich: Wenn geprüft wird, ob eine Datei überschrieben werden kann, wird die Fehlermeldung anhand der User Handles auf die Datei bestimmt; nicht anhand der Kernel Handles. Außerdem beharrt der Explorer bei offenem User Handle darauf, dass es sich bei der Datei um den übergeordneten Ordner handelt:

Da sieht man mal wieder, was für bekloppte Konsequenzen es haben kann, wenn man um jedes Handle kämpft.

Verfasst: **29.04.2012, 19:48**

== hat in C++ Vorrang vor bitweisem &

Verfasst: **30.04.2012, 08:33**

CodingCat hat geschrieben:Ein halber Tag DirectCompute, und schon fangen GPU-beschleunigte Anwendungen (Browser, Plugins) an zu spinnen. :roll:

Kein Wunder, wenn du dir das Design einer Grafikkarte anschaust. Die ist einfach nicht für Mehrbenutzer- oder gar Mehrprogrammbetrieb geeignet.

Verfasst: **30.04.2012, 08:53**

antisteo hat geschrieben:
CodingCat hat geschrieben:Ein halber Tag DirectCompute, und schon fangen GPU-beschleunigte Anwendungen (Browser, Plugins) an zu spinnen. :roll:
Kein Wunder, wenn du dir das Design einer Grafikkarte anschaust. Die ist einfach nicht für Mehrbenutzer- oder gar Mehrprogrammbetrieb geeignet.

Öhm, doch? Nvidia hat seit Ewigkeiten (Riva TNT) Hardwarekontexte und bei den Radeons gibt es in den letzten Generationen auch mehrere Ringe. Und ein ordentliches Virtual Memory System mit MMU auf der Grafikkarte gibt es seit NV50 bzw. Cayman. Du hast also sehr wohl die Möglichkeit einzelne Prozesse auf Hardwareebene zu isolieren.

Verfasst: **30.04.2012, 14:19**

Oxygen kommt echt überhaupt nicht mit namespaces klar:

Code: Alles auswählen

namespace A
{
	class Foo
	{
	};
}

namespace B
{
	class Foo : A::Foo
	{
	};
}

namespace C
{
	class Foo : B::Foo
	{
	};
}

namespace D
{
	class Foo : C::Foo
	{
	};
}

führt mit Option "hide scope names" zu folgendem interessanten Vererbungsgraphen:

Bild

Verfasst: **01.05.2012, 13:42**

Die einzige Wirkung, die __declspec(noalias) hat, ist, dass Peephole Optimizations wegfallen und mein Text größer wird, weil überall nutzlose movs zusätzliche Register verschwenden.

Verfasst: **01.05.2012, 18:19**

http://connect.microsoft.com/VisualStudio/feedback/details/668639/c-c4709-when-not-even-using-comma-inside-the-array-index-expression-w4 hat geschrieben:Thank you for reporting the issue to Microsoft. There is indeed a comma in the expression but it's the one the compiler itself generated!

it's the one the compiler itself generated

one the compiler itself generated

Ich versuche mir gerade vorzustellen, wie Visual C++ Quelltext in eine textbasierte Intermediate Representation übersetzt

Bild

Verfasst: **02.05.2012, 11:16**

Entbinden von UAVs im Compute Shader:
deviceContext->CSSetUnorderedAccessViews(0, D3D11_PS_CS_UAV_REGISTER_COUNT, NullUAVs, nullptr);

Entbinden von UAVs im Pixel Shader:
deviceContext->OMSetRenderTargetsAndUnorderedAccessViews(0, nullptr, nullptr, 0, 0, nullptr, nullptr);

Und wehe ihr versuchts hiermit, dann crasht euch Parallel NSight gleich mal ohne Fehlermeldung weg:
deviceContext->OMSetRenderTargetsAndUnorderedAccessViews(0, nullptr, nullptr, 0, D3D11_PS_CS_UAV_REGISTER_COUNT, NullUAVs, nullptr);

Der Vollständigkeit halber, folgendes hat absolut keine Wirkung:
deviceContext->CSSetUnorderedAccessViews(0, 0, nullptr, nullptr);

Verfasst: **03.05.2012, 00:01**

Der Lohn eines langen Arbeitstages ... Fehler ohne Ende und 1 FPS

Aber voll "dynamisch"! ;)

Verfasst: **03.05.2012, 00:14**

Sind das Real-time Reflektionen? xD

Verfasst: **03.05.2012, 07:57**

Artificial Mind hat geschrieben:Sind das Real-time Reflektionen? xD

Das Real-Time kannst du streichen

CodingCat hat geschrieben:und 1 FPS

Verfasst: **03.05.2012, 09:09**

Wenn sie realistisch sind, reicht es auch nur das "-Time" zu streichen. :P

Verfasst: **03.05.2012, 10:31**

Code: Alles auswählen

Entity::~Entity()	
{	
    mCustomProperties = new QHash<QString, QString>();
}

Dies ist auf mehrere Art und Weisen eklig ...
Ich liebe Studenten-Projekte mit mehreren Mitgliedern :)

Nachtrag:
dazu kommt:

Code: Alles auswählen

std::string Entity::getCustomProperty(std::string id)
{
    return ((QString*) mCustomProperties->find(QString.fromStdString(id).value()))->toStdString();
}

Verfasst: **03.05.2012, 16:40**

glassbear hat geschrieben:So langsam versteh ich, warum Code in China Geld kostet: Der ist einfach billig. Im negativen Sinn. Am Ende schauen sich das dann doch 1-2 Leute von uns an und schreiben Teile neu, weil es so nicht ins System passt :?

Das ist nicht nur in China so. Merkt euch: Source nie etwas aus, bei dem der Coder auch mal denken muss...
Ich finde die WTFs von jeweils intergalaktischen Ausmaßen gerade wieder containerschiffweise.

Verfasst: **03.05.2012, 18:43**

Erst zwei Wochen echte GPU-Programmierung und schon kann ich sämtlichen Hass der GPU-Rendering-R&D-Community auf die Rendering Pipeline voll und ganz nachvollziehen. Eigentlich ist alles da, man kommt nur nicht ran. Konservative Rasterisierung? Nach dem Clipping ein Kinderspiel, aber sorry, letzter Stop Geometry Shader. Der ist nicht nur unendlich umständlich, und ohne eigene Clipping-Implementierung im Shader gegenüber Near-Plane-Clipping kaum robust zu bekommen, sondern obendrein noch unfassbar lahm (extra Geometrie!). Fertig verarbeitete Geometrie statt in den Pixel Shader in den Compute Shader weiterleiten? Pustekuchen, parallel ist nicht. Mindestens mal riesige temporäre Puffer anlegen. :evil:

Verfasst: **03.05.2012, 19:41**

Never change a running system. Hab mal eben schnell von AngelScript 2.20.3 auf 2.23.1 aktualisiert, weil ich eine kleine Skript-Helferklasse nicht für den alten Stand runterladen wollte. Und jetzt läuft KEIN EINZIGES verdammtes Skript mehr im Spiel. Nach einigen Stunden bin ich zur Erkenntnis gelangt, dass AngelScript anscheinend seit Neuestem alle bisherigen Skripte zerstört, bevor es ein neues Stück Code kompiliert. Demzufolge verweisen alle Code-IDs bis auf die letzte auf ungültigen Code. Tolle Wurst.

Verfasst: **03.05.2012, 19:45**

Visual C++’ /Ox (Full Optimization) impliziert nicht /GF (Enable String Pooling). Wenn String Pooling nicht eingeschaltet ist, landen völlig wahllos unreferenzierte Strings in der Exe.

Nachtrag: Ach; klar – jetzt habe auch ich verstanden, warum /O2 besser ist als /Ox …

Verfasst: **03.05.2012, 20:29**

Ich hätte tatsächlich schon dreimal beinahe auf deinen Post geantwortet, ob /O2 nicht besser wäre; irgendwie zeigt sich, dass man im Zweifelsfall doch lieber posten sollte, als es zu unterlassen.

Daher direkt mein Nachschlag: /fp:fast verändert auch hier nichts, /arsch:AVX verändert auch nichts (das kriegt man mit der XState-API raus, brandneu für Windows 7 SP1, es gilt tatsächlich (FeatureMask & XSTATE_MASK_AVX) == 0; hier noch beliebigen Rant über die Operatorreihenfolge von & und == einfügen), das Fused-Multiply-Add ist in letzten Sekunde aus dem AVX-Standard geflogen (obwohl es noch in der offiziellen Intel-Doku drin ist, aber es gibt in Visual Studio keine Intrinsics für FMA), und ich darf mich gerade in die Verwendung von RWTexture2Ds und atomare Operatoren reinlesen. Darüber hinaus kann man anscheinend mit MiniMax-Polynomen die Standard-Implementierungen von sin/cos/etc. um einiges schlagen, und hier ist wieder ein grandioses Beispiel, wie ein Blogpost nicht aussehen sollte, ich bastelte an einem eigenen alloca das bisher nur um die Ohren fliegt, und wer eine Begründung haben will, warum Phong/Blinn-Phong der meistüberladene Begriff überhaupt ist, schaut mal hier rein.

Ich weiß nicht, ob das Leben tatsächlich so sein sollte; ich glaube aber schon.

Verfasst: **04.05.2012, 18:38**

Ich will die von meiner GPU fertig geclippte Geometrie. Jetzt sofort! :(

Verfasst: **04.05.2012, 21:37**

Wieso denn? Ich bezweifle dass eine GPU überhaupt irgendwas in Richtung Clipping betreibt...

http://www.cs.unc.edu/~olano/papers/2dh-tri/2dh-tri.pdf ;)

Verfasst: **04.05.2012, 22:02**

http://msdn.microsoft.com/en-us/library/windows/desktop/hh404489 hat geschrieben:When you set DepthClipEnable to FALSE, the hardware skips the z clipping (that is, the last step in the preceding algorithm). However, the hardware still performs the "0 < w" clipping.

ZFX + Developia

Jammer-Thread

Re: Jammer-Thread

Re: Jammer-Thread

Re: Jammer-Thread

Re: Jammer-Thread

Re: Jammer-Thread

Re: Jammer-Thread

Re: Jammer-Thread

Re: Jammer-Thread

Re: Jammer-Thread

Re: Jammer-Thread

Re: Jammer-Thread

Re: Jammer-Thread

Re: Jammer-Thread

Re: Jammer-Thread

Re: Jammer-Thread

Re: Jammer-Thread

Re: Jammer-Thread

Re: Jammer-Thread

Re: Jammer-Thread

Re: Jammer-Thread

Re: Jammer-Thread

Re: Jammer-Thread

Re: Jammer-Thread

Re: Jammer-Thread

Re: Jammer-Thread

Re: Jammer-Thread

Re: Jammer-Thread

Re: Jammer-Thread

Re: Jammer-Thread

Re: Jammer-Thread