[Projekt] ZFXCE2

[Salacryl]

[quote="kimmi"]Der Einfachheit halber: Bau doch mal auf TCP/IP-Basis einen einfachen und funktionierenden Prototypen. So hochgradig Planungen haben mit meiner nun 10-jährigen Berufserfahrung einen ganz entscheidenen Nachteil: die wirklichen Probleme sieht man erst in der Praxis / Implementierungsphase und nicht davor.
Die Idee mit den Streams finde ich übrigens klasse für den Client.

Also: ich würde ein iteratives Vorgehen bevorzugen: Ziel eine einfach Server-Client-Verbindung bauen, diese dann mit Anzahl der Clients nach oben drehen hoch skalieren. Das Ganze wird dann als Plugin eingebunden ( du definierst dir einfach mit der aktuellen Lib einen eigenen Netzwerk-Task ). Sonst verrennt man sich, was im letzten Ansatz halt auch passiert ist. Vielleicht kann man das Ganze auch als Stand-Alone-Lib betrachten, die einfach eingebunden wird.

Das sind meine Gedanken zu dem Thema.

Gruß Kimmi[/quote

Danke für deine Sichtweise. Das interessante an Erfahrungen ist immer: sie sind subjektiv. Ich konnte in den letzten Monaten viel mit TCP/IP werken. Ich habe eine eigene HTML, FTP und SMTP implementierung probiert. Ich möchte einen Prototypen der mich fordert, darum nehme ich an dem Projekt teil, darum programmiere ich. Außerdem muss ich erst das Threading-Modell durchschauen um zu sehen warum dieses nicht kompiliert und dann kann ich etwas demonstrieren. Ich habe etwas im Auge, dass an der UT3-Engine anlehnt und dieses erweitert. Dies geht nicht mit einem gewissen Maß an Planung, dass hat mir in der Vergangenheit gefehlt und im Studium habe ich gelernt, durch Planung den roten Faden zu halten und Ideen zu konsolidieren. Danach ist die Implementierung lediglich die Übertragung in eine andere Form. Keine Sorge, der "digital Mock-Up" wird überzeugen.

Gruß,
Björn

[kimmi]

Diese subjektive Sichtweise wird allerdings von einem Großteil der mir bekannten Entwickler geteilt, die in großen Projekten mitgearbeitet haben. Und keine Frage, Planung bzw. Verständnis der Probleme ist notwendig. Das ist genau der Weg, der durch das iterative Verfahren ( gern auch agil genannt, ist aber so ein verbranntes Wort )von mir vorgeschlagen wurde. Deswegen dürften auch 2 Planungsphasen etwas knapp bemessen sein :).

Aber nur zu. Was sagst du zu den Vorschlägen, die ich gemacht habe ( Plugin etc. ).

Gruß Kimmi

[Salacryl]

Diese subjektive Sichtweise wird allerdings von einem Großteil der mir bekannten Entwickler geteilt, die in großen Projekten mitgearbeitet haben. Und keine Frage, Planung bzw. Verständnis der Probleme ist notwendig. Das ist genau der Weg, der durch das iterative Verfahren ( gern auch agil genannt, ist aber so ein verbranntes Wort )von mir vorgeschlagen wurde. Deswegen dürften auch 2 Planungsphasen etwas knapp bemessen sein :).

Aber nur zu. Was sagst du zu den Vorschlägen, die ich gemacht habe ( Plugin etc. ).

Gruß Kimmi

Mag sein, dass deine Kollegen deine Erfahrung teilen. Das ändert nichts an der Subjektivität. 2 Planungsphasen reichen, da sich diese beliebig oft wiederholen lassen, dies ist durchaus vorgesehen. Falls der Prototyp den "Proof of Concept" nicht besteht, wird das alte Konzept dementsprechend angepasst und die Implementierung eben so. Mir jedenfalls sind diese Phasen wichtig aus den oben genannten Gründen.
Zu deiner Frage: Ein Plugin? So wie ich das bisher sehe ist die ganze Engine modular aufgebaut und so ausgelegt, dass jedes System im eigenen virtuellem Speicher läuft.
Wenn ich bei der von uns abgesprochenen Arbeitsweise bleibe (Branchen und Patch einreichen), dann kannst du den code in der Engine nutzen wie du möchtest. Lokal bei mir wird dieser integrativ sein.

Gruß,
Björn

[kimmi]

Was auch immer du damit sagen willst. Momentan klingt mi das alles zu abstrakt und ich habe aufgrund der fehlenden Möglichkeiten, wie man das Ganze einbinden soll, meine Zweifel, dass es sich gut integrieren lässt. Schnittstellen habe ich nämlich in deinen UML-Diagrammen keine gesehen. Wie soll das Ganze eingebunden werden.

Momentan hat jeder Task eine Queue, die die zugehörigen Jobs enthält. Wo finde ich das in deinem Konzept? Was oll üebrtragen werden. Es existieren zur Zeit Views, die einen möglichen Spieler / Applikations-View beinhalten können. Willst du das da auch mit einbringen? Wenn ja, wie?

Ich warte mal ab, was kommt :).

gruß Kimmi

[Salacryl]

hi,

Was auch immer du damit sagen willst. Momentan klingt mi das alles zu abstrakt und ich habe aufgrund der fehlenden Möglichkeiten, wie man das Ganze einbinden soll, meine Zweifel, dass es sich gut integrieren lässt. Schnittstellen habe ich nämlich in deinen UML-Diagrammen keine gesehen. Wie soll das Ganze eingebunden werden.

Momentan hat jeder Task eine Queue, die die zugehörigen Jobs enthält. Wo finde ich das in deinem Konzept? Was oll üebrtragen werden. Es existieren zur Zeit Views, die einen möglichen Spieler / Applikations-View beinhalten können. Willst du das da auch mit einbringen? Wenn ja, wie?

Ich warte mal ab, was kommt :).

gruß Kimmi

Was ich damit sagen wollte: Ich danke dir, dass du deine Erfahrung mit mir teilst. Ich ziehe jedoch eine zweistufige Planungsphase vor, da ich mich in der Vergangenheit oft verzettelte.
Zu deinen Fragen:
Ok, ja mein Fehler. Phase 1 ist ein völlig abstrakter Entwurf um der internen Struktur einen roten Faden zu verleihen. Also Formulierung von Aufgaben und Hierachien. Schnittstellen und konkrete Integrationen kommen in Phase 2. Phase 2 kann aber erst beginnen, wenn: a) Phase 1 soweit klar ist, b) ich genauere Kenntnisse über die Struktur der Engine habe und c) die benötigten Abhängigkeiten (Threads, Streams, etc.) auch nutzbar sind.

Was, wie und wann übertragen werden soll, definiert das Protokoll. Ich stelle mir eine konkrete Protokoll-Klasse so vor:
- Sie erbt vom Interface NetworkProtocoll
- Sie hat eine Input- und eine Output-Queue. Ob die Input-Queue eine gemeinsame - über alle Tasks - mit Nutzermapping (Wie im Diagramm) oder ob jeder Tasks eine eigene bekommt und man jede Queue einzeln abarbeitet ist eigentlich egal.
- Sie hat Normalisierungsmethoden, welche die Input-Queue und die Output-Queue füttern. z. B. vorbereiten von Steuerzeichen der Eingabegeräte (0x13 -> "ENTER")
- Sie hat Event-Dispatcher ("Was ist wann und wie zu antworten"), die sich aus der Output-Queue bedienen. z. B. Das Protokoll sieht vor alle Steuereingaben per UDP an den Server zu senden. Dann wird per Event jeder Tastendruck normalisiert und an den Server gesendet. Das Event ist "Tastendruck". Ein Event kann auch sein: "Server hat 'NEWPLAYER LOCATION: 3.55674, 0.00000,150.55500' gesendet" sein, dann wird normalisiert und in die Input-Queue geschrieben.
Das ist aber nichts konkretes, sondern bloß eine Idee.

Eingebunden soll es nach Möglichkeit kaum werden. Ich bin mir nicht sicher was du mit View meinst. Ich versuche die Hirarchie zu verdeutlichen:
Die oberste Schicht ist eine reine Objektverwaltungs- und Objekthaltungsschicht. Das NetworkApplikation-Objekt (NA). Der NA übergibst du lediglich eine Menge an Servern, denn die NA ist dafür da alle Server zu binden, bzw. den Befehl dazu zu übergeben.
Ein Server wiederum verwaltet eine Menge an Task. Er hat Kenntnis über Port, Sitzungsprotokoll (UDP oder TCP), über Verschlüsselung (ja, nein) und über das zu verwendete Datenprotokoll. Kommt eine Verbindung überprüft dieser ob die Verbindung noch zugelassen wird (aktuelle Anzahl Clients + 1 <= Max. Anzahl), wenn ja wird ein neuer Tasks gestartet mit dem Datenprotokoll. Der Server sorgt nur dafür, dass die Richtlinien für neue Verbindungen eingehalten werden und legt neue Tasks an.

Meine Idee ist, dass für die Engine das ganze als gewöhnlicher Stream darstellt. D. h. für die Engine selbst soll keine andere Behandlung notwendig sein als eine Datei, Tastatureingabe, Bildschirmausgabe oder eben Netzwerk. Somit wäre keine tiefergehende Einbindung von Nöten. die Network-DLL soll als einzige Abhängigkeit Core besitzen.

Ich hoffe ich konnte einige Unklarheiten beseitigen.

Gruß,
Björn

[kimmi]

Ok, leider gibt es keine Dll Core mehr ;). Du meinst Infrastructure. Und die Streams kommen sowieso in Infrastructure/IO. Die kannst du nehmen. Dann kannst du das Ganze auch ( also den Stream ) per Uri ( Klasse folgt demnächst ) im IO-Server mounten. Dann funktioniert der IO wirklich wie einem File.

Gruß Kimmi

[kimmi]

Ich habe das grundlegende Design für das Resource laden mal in einem Blogpost dokumentiert. Das Ganze findet ihr auf Englisch hier: http://www.gamedev.net/blog/943/entry-2 ... em-access/ .

Gruß Kimmi

[Sternmull]

Ich glaub das "locale" sollte ein "local" sein :). Aber ich sehe nicht was die URI dort bringen soll. Muss ich jetzt in der URI ein "zip://" angeben um auf Dateien in einem ZIP-Archiv zuzugreifen zu können das ich vorher explizit als ZIP "gemounted" habe? Dann ist die Information in der URI doch bloß redundanter Ballast. Warum nicht ein virtuelles Dateisystem aufsetzen in dem man verschiedene Quellen zusammenführen kann, so wie das unter Unixoiden Systemen läuft? Dann könnte man z.B. ein ZIP-Archiv unter "/textures" einhängen noch eins unter "/models". Beim Zugriff bräuchte ich dann nur noch einen Pfad angeben, ohne wissen zu müssen ob die Ressoruce nun durch ein ZIP-Archiv, ein lokales Dateisystem, oder durch sonstwas bereitgestellt wird. Insgesamt erscheint mir ein Union-Dateisystem erstrebenswert. Dann könnte man mehrere ZIP-Archive (z.B. von verschiedenen Extension-Packs oder was weiß ich) am gleichen Basispfad einhängen und könnte dann einheitlich auf alle ihre Dateien zugreifen. So können z.B. mehrere Archive Texturen in "/textures" bereitstellen.

[kimmi]

Stimmt, local ist der richtige Name. Werde das bei Gelegenheit mal in Ordnung bringen.
Das Ganze ist als Virtuelles Filesystem gedacht. Ich möchte in der Lage sein, sowohl auf das lokale FS als auch auf Inhalte von Zip-Archiven zuzugreifen. Deswegen auch URI's, weil man dann angeben kann, womit die Resource gelesen ( welche Filesystem-Implementierung genommen ) werden soll. Ob man für einzelne Resourcenzugriffe immer eine URI angeben muss, ist in der Tat eine gute Frage. Genauso gut kann ich mir deinen Ansatz mit dem Textur-Mountingpoint als weitere Vereinfachung vorstellen. Die Resourcen sind eh in Gruppen unterteilt. Da könnte man solch eine vereinfachte Suche recht leicht mit einbringen. Die Suche über alle gemountete Filesysteme ist eh noch Todo auf meiner Liste. Danke für die Denkanstöße :).
Das Angeben der benötigten Filesystemes per URI als internes Hilfsmittel macht mir aber an anderen Stellen das Leben leichter, will man Pfade zum Suchpfad hinzufügen.

Wenn ich wieder zu Hause bin, werde ich das Mounten per URI zu den Gruppen zugeordeten Suchpfaden aml ausprobieren und dann kurz durchgeben, was sich als nützlich erwiesen hat. Schließlich will ich mir das Leben einfach und nicht unnötig kompliziert machen :).

Gruß Kimmi

[Sternmull]

Naja, für das einbinden einer Ressource in das virtuelle Dateisystem ist die URI schon sinnvoll, z.B. um eben anzugen das man den Inhalt eines ZIP-Archivs einbinden möchte, und nicht das Archiv selbst als Datei. Nur für die Pfade in dem Dateisystem sollte ein Präfix wie "file:" oder "zip:" entfallen. Ich stell mir das so vor:

Code: Alles auswählen

VirtualFileSystem fs;
fs.Add("zip://C:/stableGameData.zip", "/"); // Archiv mit Daten die von der aktuellen stabilen Version des Projektes verwendet werden. Inhalt wird in die Wurzel des Dateisystems eingebunden.
fs.Add("file://D:/stuffIAmWorkingOn/textures", "/textures"); // Texturen die grad in arbeit sind unter /textures einbinden. Die sind nicht in einem ZIP-Archiv, wandern aber in eins wenn sie fertig sind. Deshalb sollte der Code identisch bleiben können, egal von wo die Texturen nun grad geladen wurden.
...
LoadTexture("/textures/consoleFont"); // könnte aus dem ZIP kommen
LoadTexture("/textures/superGrass"); // kommt aus dem Argeitsverzeichnis eines Grafikers, später will er aber ein ZIP draus machen

[kimmi]

So ähnlich dachte ich mir das. Allerdings würde ich aus dem LoadTexture ein findResource machen. Die Zuordnung erfolgt dann über die vorher definierte Resourcengruppe. Ich bin gerade nicht im Lande, ist stell die Lösung hier mal vor.

Gruß Kimmi

[kimmi]

Hallo,

mal ein kurzes Update von meinen Aktivitäten in den letzten Wochen und Monaten in der ZFXCE2. Ich bin nicht zu besonders viel gekommen, aber das ist ja fast schon normal :). Dafür nimmt in Assimp der M3-Loader Formen an und meine Tochter hat mittlerweille Zähne und kann schon fast laufen:

• Man kann nun komplette Filesysteme selber mounten.
• Einführung eines einfachen Scene-Graphen, um Transformationen und Hierarchien abbilden zu können.
• Resource-System funktioniert soweit und wird bereits für Texturen und Skripte benutzt.
• Klassen können nun auch in Lua-Skripten aufgerufen werden, der Export selbiger ist mit kaum bis wenig Schreibarbeit soweit abgeschlossen.
• Modelle können komplett mit Texturen asynchron geladen werden.
• Umstellung der bisherigen Tasks auf Worker- und System-Tasks. Systemtasks stellen dabei ständig laufende Threads dar wie zum Beispiel ein Render-Thread. Aufgaben wie das Laden bzw. Aufarbeiten fallen Worker-Tasks zu, die per Asyc-Queue auf Arbeit warten. Da hackt es aber noch am Konzept, ich habe das einfach noch nicht glatt ziehen können.
• Includes sind in einem komplett separaten Verzeichnis, was das Deployen bzw. verwenden des ganzen Krams einfacher macht.
• Gleiches gilt für die Libraries.
• Aus Stabilitäts- und Bequemlichkeits-Gründen teste ich viel in kleineren Unit-Tests und Demo-Anwendungen. Ich bin mittlerweilse bei zirka 150 Unittests. merke: Nebenläufigkeiten in Unittests sind echt eklig.
• Ja, es gibt aktuelle Screens. Allerdings vergesse ich immer, die anzulegen. Ich gelobe Besserung.
• Ich probiere all die ganzen Sachen in einem Projekt aus.

Insgesamtes Fazit bisher: Viel über typische Multithreading-Muster gelernt, zum 10. Mal Modell Assimp-Modelle gerendert und auch ich versuche mich mal an einem kleine Spiel. Ob man das Ganze mal produktiv nutzen möchte, kann ich nicht sagen, Spaß bringt es allemal.

Gruß Kimmi

[Jonathan]

Ist zwar jetzt Offtopic, aber...

Dafür nimmt in Assimp der M3-Loader Formen an und meine Tochter hat mittlerweille Zähne und kann schon fast laufen:

Du hast ein kleines Kind UND Zeit Hobbymäßig was zu programmieren? Hast du keinen Job oder so?
Also ich hab damit selber keine Erfahrung, aber man hört so, das Kinder echt viel Arbeit sind :D

[kimmi]

Mit Kind verzichtet man ja sowieso stetig auf das Schlafen, also :) ...

Eine Job habe ich natürlich und mit Kind und Freundin muß man das Ganze mit Hobby etwas anders organisieren. Prinzipiell aber geht das.

Gruß Kimmi

[kimmi]

Und ich kann vermelden: das ist mein 1000. Post :) !!! Den wollte ich doch in meinem am längsten verfolgtem Projekt gepostet haben!

gruß Kimmi

[kimmi]

Hallo zusammen,

nach einiger Zeit mal ein kurzes Lebenszeichen von der ZFXCE2. Ich probiere immer noch fleißig mit Multithreaded-Rendering herum. Mittlerweise läuft das auch ganz ordentlich. Der folgende Ansatz hat sich bisher in meinem Kopf und im Code durchgesetzt:

• Es gibt einen separaten Render-Thread, der alles API-spezifische macht.
• Dieser Renderthread bekommt eine einfache Liste mit Zeichenkommandos, sogenannten RenderCommands, die in einem RenderCache abgelegt werden.
• Diese Liste wird bei Änderungen aktualisiert, und zwar vom RenderFrontend.
• Ich habe für die RenderCommands ein Double-Buffering vorgesehen, welches Aktualisierungen immer in dem RenderCache vornimmt, der gerade nicht gezeichnet wird.
• Zur Zeit benutze ich als Synchronisationspunkt genau ein OnRenderFrame-Signal, hier werden die Caches umgeschaltet.
• Das Frontend besteht aus einem Scene-Graphen, der die Modelle, Animationen und anderen Dinge, die dargestellt werden, verwaltet.
• Hier werden auch Aktualierungen in den Transformationen vorgenommen.
• Beim Update der Nodes wird das Changeset für die Rendercommands zusammen gestellt und diese in den RenerCache eingearbeitet.

Das funktioniert soweit aus ganz gut. Man kann geladene Modelle frei mit der Maus drehen. Auch lassen sich Renderstrategien recht schnell im RenderCache einarbeiten. Somit ist das Anbieten von so etwas wie verschiendene Render-Pfade mit keinem so tiefen Eingriff in das Rendern verbunden, wie es bisher bei all meinen vorherigen Versuchen der Fall gewesen ist.

Offene Punkte gibt es noch einige:

• Animationen: Noch nicht da
• Beleuchtung: Noch nicht da
• Schatten: noch nicht da
• Beliebiges sinnvolles Feature einfügen.
• Dynamische Bufferzugriffe: sind gerade noch sehr teuer, da zwar Double-Buffering für die Commands benutzt wird, allerdings die Resourcen nur einmal da sind.

Was habe ich in den letzten Monaten gelernt:

• Das größte Problem mit Kind ist die Zeit, ich kann an keinen Problem wirklich mehr als 1 Stunde drann bleiben ( das meist nach 23:00 Uhr ).
• Assimp 3.0 Release bremst andere Entwicklungen :) ( Jammern auf hohem Niveau, ich weiß )
• Separater Render-Thread bringt Vorteilel, wenn man CPU-intensive Dinge im Mainthread macht und das Rendern nicht.
• Tasks / Threading ist ein sehr spannendes Thema. Dinge wie ThreadSafe-EventQueues oder Double-Buffering für Commands bringen viel Verständnis für die auftretenden Probleme.
• Das Minimieren von Locks durch Mutexes ist esistenziell für die Performance.
• Haltet so viele Daten wie möglich Thread-lokal.
• Alles dauert viel viel länger, als man denkt.
• Ich bin zu faul, eine vernünftige Demo auf die Beine zu stellen :).

To be continued...

Den aktuellen Stand kann man sich wie immer bei Sourceforge ansehen. Ich überlege, mal ein erstes Source-Only Package freizugeben. Vielleicht kriegt man ja etwas Feedback.
Kimmi

[kimmi]

Mal ein kurzes Update:

Mittlerweile liegen die Sourcen auf Github herum und zwar hier: https://github.com/kimkulling/zfxce2 .

Was hat sich in den letzten Monaten getan:

• Ich baue gerade ein kleines Projekt mit dem bestehenden Sourcen, ist aber noch nichts wirklich Zeigbares dabei. Immerhin kann man schon Modelle mit wenig Code laden. Hier habe ich viel in Richtung Benutzbarkeit der ZFXCE2 gedreht, um mir das Leben einfacher zu machen.
• Ich habe die Performance des dynamsichen Array's etwas getuned.
• Der Renderthread benutzt nun Transformation-Groups, die untereinander eine Hierarchie bilden können. Somit liegen die Transformationen in einem Transform-Controller, der diese als Array einmal durch-aktualisieren kann. Das heißt, weniger Cache-Misses.
• Das Laden von Resourcen baut sich nun selbstständig einen Dependency-Baum auf. Erst wenn alle Daten geladen sind, ist das Modell fertig. Dummerweise ist hier auch noch ein Bug: wenn eine Resource nicht geladen werden konnte, hängt das Ganze. Dazu mach ich den Update, ob das Modell fertig geladen ist, per Polling. Und das ist noch nicht so, wie ich das gerne hätte.
• Der Modell-Loader rotiert und skaliert freuding vor sich hin.
• Ich habe angefangen, einen DX11-Renderer zu bauen. Zur Zeit basiert das Ganze noch auf einem kruden D3D9-Renderer, der auch nur in einem Renderthread laufenb kann. Dinge wie Deferred-Contex sind damit nicht möglich und ich habe auch keine Ahnung davon. Außerdem ist das ein ganz guter Test, wie gut man Interafecs geschnitten hat. Ich kann berichten: es erfordert an manchen Stellen Nachbesserung.
• Da ich zeitweise recht viel unter Linux arbeiten musste, habe ich etwas in OpenGL machen wollen,was aber zur Zeit auf Hold steht.

Kurzfristige ToDo's:

• Render-Command-Queue double-buffer-fähig machen.
• Bug Resource-Dependency finden und fixen.
• CMake Files aufräumen.

Gruß Kimmi

[kimmi]

Hallo zusammen,

mal wieder ein kurzes Update leider ohne neuen Screenshots ( ich muss mal eine Demo-Szene bauen, damit das Ganze nicht so langweilig ist ) :

• DIe Dependencies beim Modell laden als Baum zusammengefasst und diesen aufgelöst. Ein Job hat dabei einen Dependency-Counter, der alle Tasks zählt, auf die er aufgrund nicht aufgelöster Dependencies noch wartet. Erst wenn diese == 0 sind, wird auch er als fertig signalisiert.
• Ein wenig mit D3D11 herumgespielt und die komplett shader-basierende Architektur "wahrgenommen".
• Umstellung der Transformationen auf Shader-Parameter, um endlich ein besseres Konzept im Renderer implementiert zu haben. Damit habe ich gerade richtig viel Arbeit.
• Shader unter D3D9 funktionieren, allerdings die ganze Transformationslogik noch nicht vollständig.

Wer Interesse hat, was ich da so treibe: https://github.com/kimkulling/zfxce2 .

Gruß Kimmi

[kimmi]

Kleines Update meiner Experimente bezüglich Multi-Threading-Rendering:

• Der bisherigen Direc3D9-Renderer hat aufgrund seines verwachsenen Interfaces mir mehr Ärger als Nutzen gebracht und wurde deswegen gelöscht
• Der neue Renderer baut auf OpenGL4.3 und wird auf dem Render-Thread als Backend genutzt.
• Alle, die rendern wollenl, können das über eine Fassade names RenderBackendServer tun. Die Daten werden von dort auf den RenderThread gesended und auch nur dort mit dem BAckend gerendert. Somit Sieht man als Anwender nicht, welche Technologie dahinter steckt.
• Geometrie, Material-Beschreibungsn und Parameter werden via Event an den RenderThread gesendet. Somit ist die Renderei per Protokoll implementiert. Als Anwender kriegt man von diesen Dingen nichts mit.
• Das Ganze läuft dank SDL2 momentan unter Windows und Linux.
• Alle platform-spezifischen System-Calls und Interfaces sind in einer eigenen Komponente gekapselt. Diese wird je nach Platform beim Start einer Anwendung hochgefahren. Darin enthalten sind Threading-API ( wenn C++11 gerade nicht da ist ), Windows-Handling, OS-spezifische Event-Handler, RenderContext und High-Resolution-Timer ( UNter VS2013 ist der C++11 timer nämlich nur bedingt high-resolution ). Man muß dann für eine neue Plattform auch nur eine Komponente portieren, der Rest ist portabel.
• Weil eine lauffähige Linux-version für mich selbst ein Milestone war, habe ich das Ganze nun mal als Release v0.1.0 betaggt.

Unter https://github.com/kimkulling/zfxce2/releases kann man sich das Ganze gerne mal anschauen.

Das Projekt RenderTest implementiert 2 Beispiel-Szenen:

• Reine Geometrie ( ein farbiges Dreieck )
• Ein rotierender Rechteck mit Textur

Gruß Kimmi

[Schrompf]

Cool, es geht vorwärts. Ich bau auch grad "UnitTests" für meinen Renderer - Szene rendern, Screenshot machen, gegen Referenzbild vergleichen.

[kimmi]

Vorwärts ist anbetracht der Tatsache, wie lange ich da schon rumpuzzel, vieleicht etwas übertrieben. Aber ja: ich mache mal Fortschritte. Nun sogar auf Linux :). Und das Testen gegen Refenzbilder war auch eine Idee. Aber Obacht: gegen Jitter sollte man die Anzahl von Mismachtes gegen einen grenzwert testen. Wir machen hier so etwas in der Art und da hat man wirklich viele false-positives, wenn der treiber mal neue Laune vom Hersteller verpasst bekommt.

Gruß Kimmi