ZFX + Developia

mnemonix hat geschrieben:Ich wünschte wir hätten sowas wie einen Artikel/Paper-Thread

Du meinst sowas in der Art? ;-)

Hehe, hast wohl nicht zu Ende gelesen :P

@mnemonix: Ja, geht mir ähnlich. Wikis finde ich aber doof für kleine Communities und besonders für Linklisten. Ich stelle mir ja eher eine Art gemeinsam pflegbares Directory vor. Ich hab schon lange vor sowas zu machen, also etwas, dass man in jede Website per IFrame o.Ä. einbinden kann. Oder gibt's schon was cooles in der Richtung?

Doch, doch, aber irgendwie nicht mehr vollständig prozessiert. :>

Wiki find ich auch doof, da findet man erfahrungsgemäß ganz schnell gar nix mehr. Und die Hemmschwelle "da nur mal schnell 'nen Link zu posten" ist mir auch irgendwie zu hoch. Eine gemeinsam pflegbare Liste fände ich super, idealerweise mit Tags pro Eintrag um irgendwann auch mal was wieder zu finden.

So, ein Neuling meldet sich auch mal mit Post Nummer 2:

Ein 26-Stunden-Marathon, ein Port von XNA zu einer eigenen OpenGL3.3-Engine mit OpenTK und zwischendurch mal Pausen. Das Resultat: Light Prepass Renderer


Was hat man dabei so gelernt: XNA hat eine sehr unflexible Rendering-Pipeline. IDisposable will richtig implementiert werden. 500 logische Zeilen Code für eine Engine im groben Stile von XNA sollten reichen. Assimp ist eine tolle Bilbiothek. Ändere NIEMALS die verwendete Mathe-Bibliothek.

Grüße
Felix

Sehr schick! Der Würfel ganz rechts hinten wirkt an den Kanten, als hätte der Beleuchtungsprobleme. Da stehen ein paar helle Pixel heraus. Ist das nur Zufall oder ein bekanntes Problem?

Schrompf hat geschrieben:Da stehen ein paar helle Pixel heraus. Ist das nur Zufall oder ein bekanntes Problem?

Das ist ein bekanntes Problem (und auch der Hauptgrund, warum ich zu OpenGL gewechselt habe. Bei XNA waren das nicht nur ein paar kleine Pixel, sondern die ganze Beleuchtung war off-by-one und hat "geschwommen". Den Effekt hab ich mir nicht erklären können, es sah aus wie eine Art Heat-Haze, wobei die Shader im Endeffekt 1:1 das Gleiche gemacht haben.

XNA ist Direct3D9-Level. Da ist der Screen Space anders definiert als bei OpenGL / DX10+. DX9 definiert (-1, 1) als Mitte des linken oberen Bildpixels, nicht als linke obere Ecke des linken oberen Pixels wie alle anderen. Dieses Offset musst Du in allen Operationen mit Rendertargets einberechnen, sonst bekommst Du potentiell die falschen Texel geliefert, wenn Du aus Texturen sampelst.

Der dort sichtbare Fehler dürfte also sein, dass da ein Pixel die falschen Normale / Weltposition / Lichtindizes benutzt, weil die Werte nicht genau deckungsgleich für die selben Daten entstanden sind.

Ich habe jetzt das ganze nochmal überarbeitet und verwende jetzt texelFetch mit gl_FragCoord anstelle meiner eigenen Positionsberechnung.
Funktioniert super, ich finde im Moment keine Falschpixel mehr, es rauscht auch sehr viel weniger.
Habe auch mal versucht, Gamma Correction einzubauen. Schaut aus, als hätte es funktioniert :)

Ich hoffe das zählt nicht als Doppelpost :P


Nochmal ein Bild

Der Shader ist im Moment aber nur eine Experimental-Implementierung, da meine Engine noch keine Post-Processing-Shader supported (ich kann im Moment nur einen Shader anwenden was irgendwie nich so pralle is)

Layout-Engine für die GUI für die obige Engine:

Font Rendering mit FreeType + GUI-Controls Label und Button:

hübsch :)

GUI ist selber geschrieben?

Ja, gerade dabei, Controls zu implementieren. Buttons und Labels sind dann doch etwas wenig ;)

Ja schon ne komplizierte Sache eine universale GUI zu entwickeln. Ich hatte Anfang des Jahres auch ein bisschen damit zu kämpfen, Layout-Manager hatte ich allerdings nicht implementiert. Meiner gemachten Erfahrung nach, ist es aber wirklich extrem wichtig ein MVC anzuwenden, zumindest den Render-Code wegzuabstrahieren. In der Iteration hatte ich das nicht gemacht und es wurde echt ekelhaft.
Ansonsten hier einmal noch etwas, was ich vor Weihnachten auf die Schnelle implementiert habe. Wellensimulation durch 512x512 IFFT via ComputeShader, Screen-Space-Refractions, sowie Reflections durch eine EnvMap.
https://developer.nvidia.com/sites/defa ... Slides.pdf

Sieht fantastisch aus, das Ganze!

————

Ich versuche gerade aus Jux, Speicherzugriffe zu protokollieren (damit ich sehe, wie sich meine Algorithmen verhalten).

Hier ist das Einfügen einiger tausend zufälliger Werte in eine std::map (die Zeit verläuft von oben nach unten): Hier dasselbe mit sortierten Werten: Wahrscheinlich fehlt darin noch die Hälfte (oder std::sort() kann zaubern), aber es ist ein Anfang.

Sieht interessant aus, aber ich kann mit den Bildern irgendwie wenig anfangen.
Für was steht idie X-Achse und für was Y-Achse? Ein Weißer Punkt ist ein Speicherzugriff, nehme ich an, aber in wie fern spielt die Position in den Bildern eine Rolle?
Wieso "std::sort" bei einer Map? Eine Map ist doch prinzipbedingt immer sowieso schon sortiert, da ergibt "std::sort" doch gar keinen Sinn mehr?

Spiele Programmierer hat geschrieben:Sieht interessant aus, aber ich kann mit den Bildern irgendwie wenig anfangen.
Für was steht idie X-Achse und für was Y-Achse?

Die X-Achse ist der Adressraum (bzw. der Ausschnitt davon, den das Programm benutzt hat; dürfte ein Dutzend KiB sein). Die Y-Achse ist die Zeit (von oben nach unten). Bei dem Bild mit den sortierten Einfügungen kannst du vertikale Strecken sehen: Das sind offenbar die oberen Knotenpunkte des Baums, die bei jedem Suchvorgang berührt werden. Daran, wie die Abstände zwischen den Knoten nach rechts hin enger werden, kannst du erkennen, dass es sich grob um binäre Suche handeln muss.

Spiele Programmierer hat geschrieben:Ein Weißer Punkt ist ein Speicherzugriff, nehme ich an, aber in wie fern spielt die Position in den Bildern eine Rolle?

Du kannst davon ausgehen, dass das sortierte Einfügen recht leistungsstark ist weil jede Zeile nur minimal von der Zeile darüber abweicht – die Speicherzugriffe treffen also wahrscheinlich den Cache. Beim Unsortierten Einfügen unterscheiden sich die Zeilen sehr stark voneinander; das dürfte den Cache sehr strapazieren.

Ein interessantes Detail sind die Zeilen ganz unten, die relativ dunkel sind. Das ist der Destruktor der Map, der die Elemente aufräumt. Am Verlauf nach dem sortierten Einfügen kannst du erkennen, dass die Elemente gemäß ihrer Sortierung von hinten nach vorne aufgeräumt werden. Eine Map, die sortiert befüllt wurde, wird also bestimmt auch bei der Freigabe schneller sein, weil die Elemente dann ähnlich im Speicher liegen wie ihre umgekehrte Zerstörungsreihenfolge.

Wieso "std::sort" bei einer Map? Eine Map ist doch prinzipbedingt immer sowieso schon sortiert, da ergibt "std::sort" doch gar keinen Sinn mehr?

Das war ohne Bezog. Ich habe auch std::vectors mit Zufallszahlen befüllt und dann sortiert. Während man das Befüllen sehr deutlich erkennen kann, fehlt das sort() komplett – ich muss also irgendwo noch einen Fehler drinhaben, dass mir Speicherzugriffe verloren gehen :(

So richtig nützlich wird es erst, wenn man aufregendere Algorithmen wie etwa Renderschleifen analysiert. Dazu bin ich aber leider noch nicht gekommen.

Normalerweise ist doch immer die X-Achse die Zeit?
Wie überwachst du denn aus Speicherzugriffe? Ich wüsste nicht wie das gehen soll? Auf jeden Fall muss es ja ein "LowLevel"-Feature sein und kein Trick in C++ sein, wenn der Cache ein Problem darstellen kann.
Klingt auf recht nützlich, wenn man optimieren will.

Spiele Programmierer hat geschrieben:Normalerweise ist doch immer die X-Achse die Zeit?

Ich hatte aber keine Zeit zum Transponieren ;-) Sonst hätte ich auch viel schönere Farben genommen.

Spiele Programmierer hat geschrieben:Wie überwachst du denn aus Speicherzugriffe? Ich wüsste nicht wie das gehen soll? Auf jeden Fall muss es ja ein "LowLevel"-Feature sein und kein Trick in C++ sein, wenn der Cache ein Problem darstellen kann.

Ich versetze alle Kacheln, die der Heap allokiert, in einen geschützten Zustand, so dass der erste Zugriff eine Ausnahme auslöst. Die fange ich ab, logge die Adresse des Zugriffs, und schalte die CPU in den Einzelschrittmodus. Nachdem die ihren Speicherzugriff durchgeführt hat, bekomme ich wieder eine Ausnahme, in der ich den Schutz der Kachel wiederherstelle damit der nächste Zugriff wieder eine Ausnahme auslöst. Es ist noch etwas komplizierter weil die CPU tatsächlich auf bis zu vier Kacheln gleichzeitig arbeiten kann, aber das wäre das grobe Konzept. Ist übrigens auch episch langsam; 1000 Elemente in die Map dauert gut eine Sekunde.

Klingt auf recht nützlich, wenn man optimieren will.

Ja das erhoffe ich mir davon.

Oh, das ist ja richtig langsam. So langsam, dass es fast an Praxistauglichkeit verliert. Aber kein Wunder, bei dem Weg.
Ich wusste gar nicht, das Windows solche Spielerereien erlaubt.

Eine andere spontane Idee von mir wäre es, automatisch entsprechende Trackinganweisungen in Assembler einzufügen.
Zum Beispiel im LLVM/Clang sollte das möglich sein. Das sollte deutlich schneller sein und hat keine Cacheeinflüsse.
Wobei mich ein wenig wundert, falls man mit dem Cache den Speicherschutz hier für einige Zeit umgehen kann. Kann man den Cache nicht irgendwie flushen? Oder auf ganz viele (sinnlose)Werte zugreifen, nur damit die zuletzt Genutzten aus dem Programm aus dem Cache verdrängt werden. Aber wie langsam es erst dann wird?

In meinem Spiel kann man Items stapeln ("Stacks") und ich habe es mir zum Ziel gemacht, alle Funktionen mit einer einzigen Maustaste (bzw. einem Finger) zugänglich zu machen. Um nun aus einem Stapel von z.B. 100 Mehl genau 45 herauszunehmen, habe ich mir folgendes Interface überlegt: Bei Doppelklick auf das Mehl erscheint ein Bogen, der die Menge von 0% bis 100% darstellt. Je nach Position des Cursors auf dem Bogen wird die dazugehörige Menge ausgewählt:



Rein rechnerisch bedeutet das: Mit einem Radius von 50 Pixeln kann mann mittels des Bogens die Menge in mindestens 235 Schritten adressieren (ist der Cursor weiter weg, vergrössert sich der Radius und die Schrittzahl erhöht sich; vom vollen Kreis fallen dabei jeweils 90° für die Mengenanzeige weg).

Yhoko

Das sieht gut aus! Wenn ein Interface sinnvoll für Touchbedienung geplant ist, ist es *nicht ganz so* übel wie die normale Mobilphone-Bedienung.

Tatsächlich bedient es sich auch am PC sehr bequem, da man nicht auf die Tastatur angewiesen ist (also nicht das Eingabemedium wechseln muss) und doch relativ schnell mit der Maus die gewünschte Menge auswählen kann. Eine Tastatursteuerung wird natürlich auch hier von einigen Spielern gewünscht werden, von daher steht das noch auf meiner Liste, hat aber keine Priorität.

Just for fun: der Gas-Effekt, oder "nanu, riechts hier komisch? Und wer sind die beiden hinter mir? ..."


(animiertes GIF)

Yhoko hat geschrieben:Tatsächlich bedient es sich auch am PC sehr bequem, da man nicht auf die Tastatur angewiesen ist (also nicht das Eingabemedium wechseln muss) und doch relativ schnell mit der Maus die gewünschte Menge auswählen kann.

Genau sowas schätze ich auch. Wenn ich auch nur einmal auf die Tastatur schauen oder gar umgreifen muss, vergeht mir schon die Lust …

Spiele Programmierer hat geschrieben:Oh, das ist ja richtig langsam. So langsam, dass es fast an Praxistauglichkeit verliert.

Naja; ich habe auch garkeinen realistisch proportioniertes Diagramm anvisiert – eine Übersicht über das Speichermuster sollte ausreichen um problematische Stellen zu erkennen. Wenn man einen Durchlauf der Physikschleife aufnimmt und dann so ein Wirrwarr sieht wie bei der unsortierten Map-Einfügung, sollten schon die Alarmglocken bimmeln; egal, ob die Zeitintervalle realistisch sind oder nicht.

Spiele Programmierer hat geschrieben:Eine andere spontane Idee von mir wäre es, automatisch entsprechende Trackinganweisungen in Assembler einzufügen.
Zum Beispiel im LLVM/Clang sollte das möglich sein. Das sollte deutlich schneller sein und hat keine Cacheeinflüsse.

Ja; absolut. Leider ist nicht alles LLVM-basiert; die Produkte bei mir auf der Arbeit z.B. überhaupt nicht.

Spiele Programmierer hat geschrieben:Wobei mich ein wenig wundert, falls man mit dem Cache den Speicherschutz hier für einige Zeit umgehen kann.

Wie meinen? Geht nicht jeder Speicherzugriff durch den TLB; egal ob im Cache oder nicht?

Wie meinen? Geht nicht jeder Speicherzugriff durch den TLB; egal ob im Cache oder nicht?

Du hast doch geschrieben, dass nicht alle Speicherzugriffe erfasst werden können, weil viele Werte noch im Cache sind.
Das heißt doch, dass Werte aus dem Cache nicht mehr den Speicherschutz/das Paging passieren.
Das bedeutet doch wiederum, dass auch wenn einer Anwendung das Recht entzogen wurde, eine entsprechende Stelle lesen, kann sie noch auf unbestimmte Zeit über den Cache weiterhin darauf zugreifen.
Der TLB spielt dabei keine Rolle. Bei Änderungen an den Pages müsste Windows diese doch aus dem TLB rausschmeißen. (zb. mit "invlpg")

Spiele Programmierer hat geschrieben:

Wie meinen? Geht nicht jeder Speicherzugriff durch den TLB; egal ob im Cache oder nicht?

Du hast doch geschrieben, dass nicht alle Speicherzugriffe erfasst werden können, weil viele Werte noch im Cache sind.

Dann haben wir uns wohl missverstanden. Falls du dich auf das hier bezogen hast:

Krishty hat geschrieben:Du kannst davon ausgehen, dass das sortierte Einfügen recht leistungsstark ist weil jede Zeile nur minimal von der Zeile darüber abweicht – die Speicherzugriffe treffen also wahrscheinlich den Cache.

Dann meinte ich damit: Die Zugriffe werden sehr wohl in meinem Diagramm registriert, dadurch ergeben sich ja die vertikalen Linien. Weil jede Zeile auf etwa die gleichen Stellen zugreift wie die darüber, ist der Algorithmus sehr Cache-effizient – denn er referenziert ja immer nur Daten, die kurz zuvor bereits referenziert wurden.

Meintest du das?

Ich verstehe nicht ganz, was du meinst.
Vorher hast du geschrieben, es werden nicht alle registriert, weil sie durch den Cache gehen und jetzt schreibst du, dass sehr wohl alle registriert werden sollen?

Ich hatte Cache nur einmal erwähnt, und zwar so wie im vorigen Beitrag erklärt. Auf welche Aussage von mir beziehst du dich?

Kann es sein, dass ich mich verlesen habe?
Du hast ja geschrieben, dass die Hälfte der Speicherzugriffe vermutlich noch fehlen und ich habe das gestern dann irgendwie so verstanden, dass der Cache schuld ist? Ich habe mich schon gewundert. Scheinbar also doch nicht?