ZFX + Developia

Chromanoid hat geschrieben:Seit wann weißt du denn das es sowas gibt? Ich erst seit eben :) Vielleicht fällt einem sowas vor allem auf, wenn weiß, dass es das gibt. Einen Gorilla, der beim Basketballspiel auftaucht, sieht man ja auch nicht unbedingt.

Ich auch erst seit dem Morgen – ich wusste zwar, dass es Halos gibt, und habe die auch schon öfters an Vollmond gesehen; aber nicht an der Sonne und auch nie diese Nebensonnen. Ich hatte auch das Glück, dass meine Straße exakt auf die Wolke zeigte. Trotzdem war eine in Regenbogenfarben glühende Wolke schon ziemlich auffällig.

Ich lerne zunehmend ereignisbasierende Programmierung zu schätzen. Das SpielModul mit dem aktuellen SpielModus ackert auf der einen Seite vor sich hin, auf der anderen Seite leben verschiedene Dialoge im GUI-System. Und ich muss die beiden nicht mehr einander bekannt machen, damit sie Änderungen beieinander auslösen können. Stattdessen feuert die GUI ein Signal, wenn sie einen Spielmodus anwerfen will, und jeder Spielmodus feuert ein Signal, wenn er einen Dialog in den Vordergrund bringen will. Und plötzlich reduziert sich das ganze State Management rund um x verschiedene Spielmodi mit grundverschiedenen Regeln und Mensch-Schnittstellen auf ein banales
Ich freue mich immer, wenn ich was gelernt habe. Was trotz all der Jahre immernoch täglich passiert :-)

Automation?
Ne ne, alles mit Maus und Entf-Taste Etwas schlampig ist es schon, aber sauber mach ich es dann im 2ten Arbeitschritt

IEEE-Floats lassen sich aufgrund ihres Bitmusters auch als Signed Integers sortieren. Damit lassen sich Materialsortierung und Tiefensortierung ohne jegliche Unterscheidung in Daten oder Verarbeitung vereinheitlichen!

Unions können Konstruktoren, Destruktoren und Memberfunktionen haben... :shock: Love my C++!

Spalte 1	Spalte 2	Spalte 3
Text 1-1	Text 1-2	Text 1-3
Text 2-1	Text 2-2	Text 2-3
Text 3-1	Text 3-2	Text 3-3

Man kann hier Tabellen machen.

Ich habe in einem Tool, dass ich gerade schreibe, tatsächlich einen sinnvollen Verwendungszweck für einen 4-dimensionalen Arrray aus Stringliteralen gefunden :ugeek:

Die Dateiformate von drei uralten Spielen sind quasi-identisch mit dem, was ich schon laden kann. Ich habe nun drei- bis viermal so viel Content zum Rumspielen wie bisher, und 97 % davon laden bereits problemlos

Ich habe gerade zehn Minuten in einem fast völlig abgedunkelten Raum damit verbracht, durch das Bokeh der Reflektion der tiefstehenden Sonne auf einer meiner angefeuchteten Wimpern meine eigene rechte Pupille inklusive der Augenflüssigkeit von innen zu beobachten. Wahrscheinlich gibt es wenige Menschen auf der Welt, die kaputter sind als ich, aber das war sehr geil.

Die Geschichte wie sich Newton eine Nadel ins Auge gestochen hat kennst du aber?

eXile hat geschrieben:

Spalte 1	Spalte 2	Spalte 3
Text 1-1	Text 1-2	Text 1-3
Text 2-1	Text 2-2	Text 2-3
Text 3-1	Text 3-2	Text 3-3

Man kann hier Tabellen machen.

Das kool! Wer weiß was sonst noch....

Alexander Kornrumpf hat geschrieben:Die Geschichte wie sich Newton eine Nadel ins Auge gestochen hat kennst du aber?

Jetzt schon; thx

Krishty hat geschrieben:

Alexander Kornrumpf hat geschrieben:Die Geschichte wie sich Newton eine Nadel ins Auge gestochen hat kennst du aber?

Jetzt schon; thx

Wenn ich jemandem zutraue das nachzumachen...

Ich freu mich einfach nur....
Kann am Pfeffi oder am Bier oder am Wetter liegen...
Wer weiß das schon :geek:

Hab gerade rausgefunden, das ich meinem VS ja als InternetBrowser benutzen kann :D

Gerade meinen ersten Geometry Shader geschrieben. Der Wahnsinn, dank D3DX11Effects muss ich dafür keine einzige Zeile API-Code schreiben, sondern nur entspannt im Shader-Code rumschmieren. Schon beachtlich, wie man da plötzlich auf Dreiecksebene hantieren kann, auch wenn mir im Moment abgesehen von mäßigem Instancing (ich kann hier scheinbar jedes Dreieck nur 33x kopieren) nur sinnlose Spielereien einfallen. :D

:D

wtf!!
Aus deiner Feder?
Verdammt... hätte das Copyright lesen sollen!
Frag mich aber trotzdem, wie das gemacht wurde... sieht "gerendert" aus.

Ich schätze mal zwei oder drei Modelle/Animationen geschickt zusammen gekittet. Hat mich an unser Zeichen erinnert, daher der Post :) Das unmögliche Dreieck sieht man ja gar nicht so häufig...

Viele sehr schöne Dinge, die man u.a. schon aus Eclipse (und auch aus der VC# IDE?) kennt, endlich auch für C++ in Visual Studio vNext: http://blogs.msdn.com/b/vcblog/archive/ ... 00097.aspx

jeah: für meine thesis ein teilprogramm fertig. und zwar eines, was nun 15GB an beschreibungsdaten eines FPGAs runter auf 15MB quetscht. war ne riesen altion, aber es läuft endlich!

erkenntnis am rande: solltet ihr jemals große textdatenmengen parsen wollen, so verwendet auf keinen fall std::string oder den boost::tokenizer. das wird brüllend lahm! selber machen, und alles mit fixen char[] buffern machen, und schon rennts.

erkenntnis nummer zwei: das angebliche puffern der fstreams ist fürn ar...! selber eine pufferung implementiert, die in 16MB blöcken arbeitet, und es ist wesentlich schneller.

FlorianB82 hat geschrieben:jeah: für meine thesis ein teilprogramm fertig. und zwar eines, was nun 15GB an beschreibungsdaten eines FPGAs runter auf 15MB quetscht. war ne riesen altion, aber es läuft endlich!

Glückwunsch! :)

FlorianB82 hat geschrieben:erkenntnis am rande: solltet ihr jemals große textdatenmengen parsen wollen, so verwendet auf keinen fall std::string oder den boost::tokenizer. das wird brüllend lahm! selber machen, und alles mit fixen char[] buffern machen, und schon rennts.

Ohja, mit Zeigerintervallen ins Ausgangsdokument lassen sich oftmals fast sämtliche Kopien sparen. Macht z.B. auch rapidxml so, falls jemand mal Inspiration brauchen sollte (auch der dort implementierte Memory Pool ist für sowas immer interessant).

FlorianB82 hat geschrieben:erkenntnis nummer zwei: das angebliche puffern der fstreams ist fürn ar...! selber eine pufferung implementiert, die in 16MB blöcken arbeitet, und es ist wesentlich schneller.

Rein aus Interesse, nutzt du Memory-Mapped Files bzw. hast du es probiert?

Rein aus Interesse, nutzt du Memory-Mapped Files bzw. hast du es probiert?

nein, habe ich nicht probiert. das liegt daran, dass mein ganzes projekt multiplatform ist (nur standard c++ verwendet + boost library). ich könnte mir zwar vorstellen, dass auch für memory-mapped-files boost ne lösung hat, aber so weit habe ich dann nicht gesehen.

ich weiss auch nicht, ob man mit denn m-m-files auch die geschwindigkeit bekommt, die ich mit meinem eigenen puffer habe. ich könnte mir vorstellen, dass meine puffer lösung schneller ist. gründe wären bspw.:

- ein gewissen teil des overheads beim ungepufferten lesen machen gar nicht die dateizugriffe aus (in gewissem umfang wird das OS ohnehin puffern), sondern die inflationär vielen read() aufrufe an den stream (also die function call kosten + die eigentliche funktion). wenn ich selber puffere, dann rufe ich read() nur auf wenns nötig ist. bei besagten 15GB sind das mit 16MB puffer rund 1000 aufrufe, bei lesen nach bedarf (sagen wir mal pro aufruf durchschnittlich 20Bytes) wären das ca 800 millionen aufrufe. noch fragen?

- wer weiss, wie das OS diese memory mapped files implementiert. da könnte einiges an speicherschubsereien anfallen. wenn ich dagegen immer eine fixe größe in einen fixen puffer einlese, komme ich da günstiger weg.

- der cache könnte da auch eine nicht unwesentliche rolle spielen, ebenfalls zugunsten von meinen größenunveränderlichen nicht reallokierbaren puffern.

nebenbei: hat man mit den m-m-files auch genügend kontrolle? sprich: kann man das OS anweisen, nicht die ganze datei in den speicher zu ziehen (15GB, sicher...), sondern nur ein teil?

CodingCat hat geschrieben:Gerade meinen ersten Geometry Shader geschrieben. Der Wahnsinn, dank D3DX11Effects muss ich dafür keine einzige Zeile API-Code schreiben, sondern nur entspannt im Shader-Code rumschmieren.

Solange man nicht irgendwelche Sachen umstellen muss, welche das Input-Layout betreffen, ist das sicherlich sinnvoll. Gerade weil ja der Geometry Shader mitten in der Pipeline sitzt, ist das bei dir sehr einfach. Sobald man aber zwischen den Passes Sachen vom IA ändern muss, ist das leider nicht mehr mit dem Effects-Framework möglich.

Ja, du kannst bei Memory-Mapped Files Ausschnitte festlegen. Die können schon ordentlich schnell sein, weil sie den Dateiinhalt seitenweise direkt in den Speicher deiner Anwendung schieben, d.h. es fallen sämtliche manuellen read()-Aufrufe und ggf. Kopien und Pufferungen durch interne I/O-Aufrufe weg. Stattdessen greifst du einfach auf den beim Mapping zurückgegebenen Speicherbereich zu, als wäre die Datei bereits geladen, das Betriebssystem liest und cachet den Dateiinhalt bei Zugriff automatisch. Ob das in deinem konkreten Fall allerdings noch was bringt, hängt sehr stark davon ab, wieviel Overhead die übrigen read()-Aufrufe im Vergleich dazu aufweisen.

eXile hat geschrieben:Solange man nicht irgendwelche Sachen umstellen muss, welche das Input-Layout betreffen, ist das sicherlich sinnvoll. Gerade weil ja der Geometry Shader mitten in der Pipeline sitzt, ist das bei dir sehr einfach. Sobald man aber zwischen den Passes Sachen vom IA ändern muss, ist das leider nicht mehr mit dem Effects-Framework möglich.

Was meinst du mit "zwischen den Passes"? Das Input Layout betrifft doch nur die Bindung des Vertexpuffers als Vertex Shader Input, zwischen Vertex Shader und Geometry Shader sowie Geometry Shader und Pixel Shader wird das dagegen alleine durch die Input-/Output-Strukturen und darin angegebenen Semantiken der einzelnen Stage Shaders festgelegt?!
Oder sprichst du jetzt vom Zurücklesen / Speichern der durch den GS generierten Vertexdaten für subsequente Renderaufrufe? In so einem Anwendungsfall brauchts natürlich Code, aber das hat man ja wohl auch eher so selten, dass ein bisschen Extracode dafür kein Problem ist. :)

CodingCat hat geschrieben:Ja, du kannst bei Memory-Mapped Files Ausschnitte festlegen. Die können schon ordentlich schnell sein, weil sie den Dateiinhalt seitenweise direkt in den Speicher deiner Anwendung schieben, d.h. es fallen sämtliche manuellen read()-Aufrufe und ggf. Kopien und Pufferungen durch interne I/O-Aufrufe weg. Stattdessen greifst du einfach auf den beim Mapping zurückgegebenen Speicherbereich zu, als wäre die Datei bereits geladen, das Betriebssystem liest und cachet den Dateiinhalt bei Zugriff automatisch. Ob das in deinem konkreten Fall allerdings noch was bringt, hängt sehr stark davon ab, wieviel Overhead die übrigen read()-Aufrufe im Vergleich dazu aufweisen.

hm. auch ein argument. soweit habe ich gar nicht gedacht, aber ich habe mich halt auch noch nie tiefer mit m-m-files beschäftigt. ich glaube, ich muss das mal demnächst wo testen...=)

CodingCat hat geschrieben:Was meinst du mit "zwischen den Passes"? Das Input Layout betrifft doch nur die Bindung des Vertexpuffers als Vertex Shader Input, zwischen Vertex Shader und Geometry Shader sowie Geometry Shader und Pixel Shader wird das dagegen alleine durch die Input-/Output-Strukturen und darin angegebenen Semantiken der einzelnen Stage Shaders festgelegt?!

Exakt. Was ich meinte: Wenn man für jeden Pass ein eigenes Input Layout anlegen muss (d.h. die meisten Passes haben unterschiedliche Input Layouts), nimmt einem das Effects-Framework da keine Arbeit ab. Ebenso wohin das am Ende der Pipeline das hingehen soll. Für alles dazwischen in der Pipeline (z.B. einen Geometry-Shader zwischen Vertex- und Pixel-Shader einfügen) ist es dahingegen wunderbar geeignet.

Wie kann man nur ohne JMX, jVisualVM und Co. arbeiten? Danke, dass es dich gibt, Java :)
Das ganze macht mich natürlich erst richtig glücklich nachdem ich herausbekommen habe, wie ich damit per SSH Tunnel entfernte Rechner in der Cloud beobachten und Methoden auslösen kann :D (dank rmi registry wäre da fast ein jammer beitrag draus geworden, jmxmp als protokoll war die rettung...)
Einfach mit "@ManagedOperation" annotieren (und die Klasse als MBean) und schon kann ich die Methode für Debug-Zwecke in der GUI auslösen. Wunderbar.

Ich habe heute implementiert, dass verschiedene Aspekte einer Programmiersprache von unterschiedlichen Compilern verarbeitet werden. Das ist gefühlt der objektorientierteste Text, den ich seit langem geschrieben habe – und das, obwohl keine einzige Klasse drin vorkommt (nur ein Array von Zeigern auf freie Funktionen).

Jeder Uni-Prof würde mich totprügeln und Java-Fanboys würden danach noch meine Leiche schänden. Aber sowas sehe ich mittlerweile mehr als Gütesiegel.

————

Noch was zu Memory-Mapped Files: Ich bin da mittlerweile ebenfalls skeptisch, weil sie Sentineling verbieten. Also, wenn man eine große Menge Text tokenisiert, sucht man ja immer eine gewisse Zeit lang nach dem nächsten Whitespace, der nächsten Ziffer, dem nächsten Zeilenumbruch, dem nächsten * usw. usf. Das Problem daran ist, dass man gleichzeitig immer gegen das Dateiende testen muss (und dass dieser Test ziemlich ineffektiv ist, da er z.B. beim Preprocessing einer C++-Quelldatei nur bei einem von 40 Millionen Versuchen anspringt).

Da ist Streaming im Vorteil, weil die meisten Streams ab Ende einfach 0 zurückgeben. Mit einer – frei manipulierbar! – im Speicher liegenden Datei kann man aber noch einen Schritt weitergehen und das Byte hinter der Datei immer auf das Zeichen setzen, das den aktuellen Algorithmus zum Halt bringt. Sucht man also bspw. nach dem nächsten Whitespace, setzt man vorher das Byte direkt hinter der Datei auf den Wert eines Leerzeichens. Auf diese Art und Weise entfallen alle Längenkontrollen und eine Variable in inneren Schleifen und man holt nochmal locker 40 % raus.

Mit Memory-Mapped I/O geht das natürlich nicht, weil man die Datei nicht verändern darf; und wenn man eh eine eigene Kopie im Speicher hält, tut es ein großer dicker read()-Aufruf auch.

Ich bin aber bei meinen Compilern bisher nie so weit gewesen, dass die Tokenization merklich was ausmachen würde.

Dennoch ist CodingCats Hinweis mit den Zeiger-Intervallen Gold wert: Nicht nur entfallen dadurch fast alle dynamischen Allokationen, sondern man kriegt auch 1,5 GiB Industriedaten mit Lichtgeschwindigkeit auf einem 32-Bit-System interpretiert … während die meisten Implementierungen von Leuten, die vom Managed-Bereich angehaucht wurden und deshalb alles brav in Strings speichern, schon bei 300 MiB mit Speichermangel abstürzen.