ZFX + Developia

Hi,

ich wollte etwas Werbung für meine zweiten Versuch einer Engine ( Projektname ZFXCE2 ) machen. Zur Zeit arbeite ich gerade an den ersten Renderbildern, komme dabei wie erwartet nicht so schnell voran wie ich gern würde.

Ich wollte das Ganze mal auf etwas stabilere Füße stellen und aus alten Fehlern lernen. Den aktuellen Status könnt ihr auf der Website http://www.zfxce2.org ansehen. Dazu versuche ich per Twitter aktuelle Entwicklungen etwas zeitgemäßer bekannt zu machen, Account ist http://twitter.com/#!/ZFXCE2. Als Milestone für einen ersten Release ist ein laufender Meshviewer vorgesehen.

Baut man die aktuellen Sourcen, sieht man außer einem schwarzen Bildschirm noch nicht viel. Aber ich habe unter der Haube einiges gerissen. Teile aus der alten Engine sind übernommen worden.

Und wenn ich etwas zu zeigen habe, werde ich das hier weiter dokumentieren.

Also später mehr...

Gruß Kimmi

Was machst Du denn jetzt anders als bei der letzten Version?

Ok, eine kleine Aufstellung:

• Eine andere Architektur. Es gibt einen Infrastruktur-, eine RenderSystem- und einen Applikations-Layer. In der alten Version hatten wir einen Haufen gleichberechtigter Subsysteme, was zu recht komplexen Abhängigkeiten geführt hat.
• Code historisch gewachsen: jede Menge verbauter Stellen im Code machten Änderungen echt mühseelig, da man erst einmal aufräumen musste. Somit kam man kaum voran. Deswegen nehme ich die Filetstücke und packe sie neu zusammen. Mit Kind komme ich nun tatsächlich schneller voran als vorher.
• Aus alten Fehlern lernen: Wir sind in der ersten Fassung in viele viele Fallen gelaufen und die evrsuche ich nun zu vermeiden.
• Multithreading-Ansatz: Da ich auch im Job recht viel mit Multithreading zu tun hatte, wollte ich das auch mal in der ZFXCE ausprobieren, hatte aber keine Lust, alles umzustricken.
• Keine Streitereien mehr: in der alten Engine gab es Teile, die von anderen beigesteuert wurden. Wollte ein anderer Entwickler daran gehen, gab es Stress, weil der Original-Autor das nicht gut fand. Und mir wurde das Schlichten einfach zuviel bzw. andere Entwickler hatten keine Lust mehr nach den Streitereien.
• Klein anfangen: Um auch mal was zeigen zu können, habe ich mir die Ziele klein gesetzt.
• Ich konnte meine alten Sachen einfach nciht mehr sehen: 2003 habe ich Sachen verbrochen, die ich nicht mehr sehen konnte...

Das fällt mir so spontan ein.

Gruß Kimmi

Lust die Layer etwas auszuführen? Würde mich gerade sehr interessieren. Überhaupt wünsche ich Dir viel Erfolg :) Ich werd's verfolgen. Außerdem folge ich dir Mal auf twitter.

Klar, kein Problem. Die Layer sollen erst einmal eine klarere Strukturierung ermöglichen. Application darf auf RenderSystem zugreifen, RenderSystem auf Infrastructure, die andere Richtung, also Infrastructure nach RenderSystem, ist verboten. Somit kann man schon einmal nicht so ohne weiteres der Einfachheit halber im Infrastructure-Bereich etwas aus Application anziehen, zyklische Abhängigkeiten hoffe ich so zu vermeiden. Die hatte ich in der ZFXCE. Die Layer enthalten zur Zeit die folgenden Componenten / Subsysteme
Infrastructure:

• Core: Container, Logging, Basics zum Konfigurieren
• Math : Mathesachen
• Properties : Einfaches Verwalten bel. Eigenschaften
• Debugging : Assertions, Mini-Dumps und dergleichen
• System: Systeminfo aller Art
• IO: Filesysteme, Archive etc.
• Threading : Hier wird ein Taskmanager sowie die Thread-Implementierung mit den OS-spezifischen Sachen behandelt
• Event : Das Event-System

RenderSystem:

• RenderDevice : Hier werden die Render-APis implementiert, zur Zeit halt nur D3D9
• Render-Interface : RenderSystem-Zugriff
• Interface : Alles, was mit dem Windows-Management zu tun hat
• RenderDriver : Hier wird der Render-Thread per Render-Driver-Pattern implementiert

Application:

• ApplicationServer: Engine initialisieren und konfigurieren wie Tools zum Erstellen eigener Applikationen

Dazu gibt es noch Tools mit dem Mesh-Viewer und Tests mit Unittests und einem Referenz-Renderer.

Das ist so grob der bisherige Stand.

Gruß Kimmi

kimmi hat geschrieben:

• Core: Container, Logging, Basics zum Konfigurieren

::std::vector, std::cerr, INI-Dateien

kimmi hat geschrieben:

• Properties : Einfaches Verwalten bel. Eigenschaften

Ein Blob oder ::std::map tun es doch auch …

kimmi hat geschrieben:

• Debugging : Assertions, Mini-Dumps und dergleichen

<cassert>, Luxus so lange man nur an Entwickler verteilt und dergleichen

kimmi hat geschrieben:

• System: Systeminfo aller Art

Wozu?

kimmi hat geschrieben:

• IO: Filesysteme, Archive etc.

::std::fstream, Luxus, etc.

kimmi hat geschrieben:

• Threading : Hier wird ein Taskmanager sowie die Thread-Implementierung mit den OS-spezifischen Sachen behandelt

Ich behaupte mal ganz kühn, dass die wirklich schweren Sachen wie Grafik-APIs von Haus aus Multi-Threaded sind und man schon massig was auffahren muss, um selbst ohne Multi-Threading eine zeitgemäße CPU ins Schwitzen zu bringen (ich schaffe einen Core i7 gerade mal dadurch, dass ich bis auf Full-HD-Rasterisierung alles in Software und jedes Dreieck in einem einzelnen Draw-Call berechne)

kimmi hat geschrieben:

• RenderDevice : Hier werden die Render-APis implementiert, zur Zeit halt nur D3D9

D3D 9 ist tot für alles, was nicht gestern ausgeliefert wurde und was man dabei demonstrieren / lernen / erreichen kann ist nicht mehr zeitgemäß; D3D 11 funzt auch auf D3D-9-Hardware

kimmi hat geschrieben:

• RenderDriver : Hier wird der Render-Thread per Render-Driver-Pattern implementiert

Kannst du mir das erklären? Wenn ich er fragen muss, was es tut, ist es meist überflüssig.

kimmi hat geschrieben:

• Dazu gibt es noch Tools mit dem Mesh-Viewer und Tests mit Unittests und einem Referenz-Renderer.

Assimp Viewer, WARP

Ganz abgesehen dass es mit jeder Zeile, die du selber schreibst, weniger portabel wird als bis zum Erbrechen unter allen Compilern erprobte Bibliotheken die quasi in Nullzeit zur Verfügung stehen.

Sind jetzt nur meine ersten Gedanken; ich bin derzeitig zu knapp bei Freizeit um wirklich konstruktiv zu verbessern; und wer auf einer eigenen CRT sitzt sollte nicht mit STL-Empfehlungen schmeißen – aber für solche gigantischen Feature-Listen komme ich mir mittlerweile einfach zu alt vor, so lange wir nicht zehn von ZFX’ Stammmitgliedern vollzeit daran arbeiten lassen. Ich persönlich würde ein Jahr brauchen um überhaupt ein Subsystem einer Schicht zu vollenden.

Gruß, Ky

Krishty hat geschrieben:

kimmi hat geschrieben:

• Core: Container, Logging, Basics zum Konfigurieren

STL, std::cerr, INI-Dateien

Ich nehme Lua statt INI-Dateien, STL fällt aus, da ich das Ganze auf Embedded mittels OpenGL-ES 2.0 zum Laufen bringen möchte ( nach D3D9 ), um ein paar Sachen aus zu probieren. Und da wurde aufgrund von Speicher-Fragmentierungs-Problemen dringend von abgeraten, STL zu nehmen. Wir hatten hier vor Ort recht große Probleme. Ansonsten würde ich dir sofort zustimmen.

Krishty hat geschrieben:

kimmi hat geschrieben:

• Properties : Einfaches Verwalten bel. Eigenschaften

Ein Blob oder ::std::map tun es doch auch …

Stimmt, ich wollte damit mal rum probieren. Ich habe dazu schon einige interessante Ansätze gesehen und irgendwo bin ich halt ein Spielkind.

Krishty hat geschrieben:

kimmi hat geschrieben:

• Debugging : Assertions, Mini-Dumps und dergleichen

<cassert>, Luxus so lange man nur an Entwickler verteilt und dergleichen

Ist eine schlechte Angewohnheit von mir, eigene Assert's zu bauen. MIni-Dump's Code habe ich fertig und ist echt praktisch, wenn man die mal hat und mit WinDbg gewohnt ist, zu arbeiten ( was ich bin ).

Krishty hat geschrieben:

kimmi hat geschrieben:

• System: Systeminfo aller Art

Wozu?

Um die Anzahl der Core's raus zu kriegen. Ist bestimmt zu dicke, dass in einem eigenen Namespace zu packen. Aber was solls, gibbet im Dutzend billiger.

Krishty hat geschrieben:

kimmi hat geschrieben:

• IO: Filesysteme, Archive etc.

STL, Luxus, etc.

Unzip-Archiv und File-System-Konzept wird von der alten ZFXCE übernommen, ergo low-hanging Fruit, weil faktisch fertig.

Krishty hat geschrieben:

kimmi hat geschrieben:

• Threading : Hier wird ein Taskmanager sowie die Thread-Implementierung mit den OS-spezifischen Sachen behandelt

Ich behaupte mal ganz kühn, dass die wirklich schweren Sachen wie Grafik-APIs von Haus aus Multi-Threaded sind und man schon massig was auffahren muss, um selbst ohne Multi-Threading eine zeitgemäße CPU ins Schwitzen zu bringen (ich schaffe einen Core i7 gerade mal dadurch, dass ich bis auf Full-HD-Rasterisierung alles in Software und jedes Dreieck in einem einzelnen Draw-Call berechne)

Mag sein, ich wollte mal probieren, wie geschickt ich mich für einen eigenen Render-Thread anstelle: wie gesagt, Spielkind. Und OpenGL wird im Treiber zwar multithreaded vom Treiber implementiert, allerdings gibt es da etwas zu evaluieren für mich.

Krishty hat geschrieben:

kimmi hat geschrieben:

• RenderDevice : Hier werden die Render-APis implementiert, zur Zeit halt nur D3D9

D3D 9 ist tot für alles, was nicht gestern ausgeliefert wurde und was man dabei demonstrieren / lernen / erreichen kann ist nicht mehr zeitgemäß; D3D 11 funzt auch auf D3D-9-Hardware

Muss aber aufgrund einer "Randbedingung" auf einem WinXP-Embedded laufen. Es wird auch erst einmal nur ein Schmalspur-Renderer gebaut, damit ich sehe, ob es etwas bringt. DX11 ist das eigentliche Ziel.

Krishty hat geschrieben:

kimmi hat geschrieben:

• RenderDriver : Hier wird der Render-Thread per Render-Driver-Pattern implementiert

Kannst du mir das erklären? Wenn ich er fragen muss, was es tut, ist es meist überflüssig.

Siehe hierzu Shader X7 Kapitel 8.1 Cross platform rendering thread: design and implementation by Guillaume Blanc. Ist die Evaluierung einer Technik, um zu sehen, ob das was bringt. Anders formuliert: ich brauche etwas ähnliche wahrscheinlich im Job, habe da aber nicht genug Zeit, das zu probieren.

Krishty hat geschrieben:

kimmi hat geschrieben:

• Dazu gibt es noch Tools mit dem Mesh-Viewer und Tests mit Unittests und einem Referenz-Renderer.

Assimp Viewer, WARP

Mesh-Viewer ist ein Test, Assimp der Referenz-Renderer

Krishty hat geschrieben:Ganz abgesehen dass es mit jeder Zeile, die du selber schreibst, weniger portabel wird als bis zum Erbrechen unter allen Compilern erprobte Bibliotheken die quasi in Nullzeit zur Verfügung stehen.

Sind jetzt nur meine ersten Gedanken und ich bin derzeitig zu knapp bei Freizeit um wirklich konstruktiv zu verbessern, aber für solche gigantischen Feature-Listen komme ich mir mittlerweile einfach zu alt vor, so lange wir nicht zehn von ZFX’ Stammmitgliedern vollzeit daran arbeiten lassen.
Gruß, Ky

Momentan arbeite auch nur ich daran, Ziele habe ich bewusst etwas höher gesetzt, aber viele der Konzepte wurden von mir bereits an anderer Stelle fertig gebaut und laufen. Nun will ich das noch mal für mich glatt ziehen. Ich habe den Namen nur aus einem Grund dabei: weil die erste Engine nun mal ZFXCE hieß und ich, falls was bei rum kommt, das hier gern anderen zur Verfügung stellen wollte.
Und da ich hier noch eine Weile darüber berichten werde, kannst du dich gern noch mehr darüber auslassen, ich freu mich ;). Außerdem habe ich bald 3 Monate Elternzeit und suche nach einem interessanten Projekt. Und die oben genannten Dinge sind im wesentlichen fertig und ich debugge grad fleißig. Momentan baut's nur unter Windows.

Gruß Kimmi

kimmi hat geschrieben:Ich nehme Lua statt INI-Dateien, STL fällt aus, da ich das Ganze auf Embedded mittels OpenGL-ES 2.0 zum Laufen bringen möchte ( nach D3D9 ), um ein paar Sachen aus zu probieren. Und da wurde aufgrund von Speicher-Fragmentierungs-Problemen dringend von abgeraten, STL zu nehmen. Wir hatten hier vor Ort recht große Probleme. Ansonsten würde ich dir sofort zustimmen.

STL raus, dafür Lua rein? Nagut; ich hätte zwar gedacht, dass die Tablet-PCs heute alle schon Dual-Core-Viecher mit ordentlicher Speicherverwaltung wären, aber ich bin kein Embedded-Programmierer und halte mich da zurück.

kimmi hat geschrieben:Unzip-Archiv und File-System-Konzept wird von der alten ZFXCE übernommen, ergo low-hanging Fruit, weil faktisch fertig.

Dass man ein System um ein, zwei, fünfzig nicht gerade kritische Komponenten verkompliziert rechtfertigt sich doch nicht dadurch, dass die schon fertig rumliegen.

kimmi hat geschrieben:ich wollte mal probieren, wie geschickt ich mich für einen eigenen Render-Thread anstelle: wie gesagt, Spielkind. Und OpenGL wird im Treiber zwar multithreaded vom Treiber implementiert, allerdings gibt es da etwas zu evaluieren für mich.

Und das musst du unbedingt in einer kompletten Engine auf zwei, drei Plattformen evaluieren? Am Wochenende ein Programm schreiben und es daran testen ohne gleich zehntausend andere Zeilen, die man später noch weiternutzen möchte, möglicherweise zu vergiften geht nicht?

kimmi hat geschrieben:

Krishty hat geschrieben:

kimmi hat geschrieben:

• RenderDriver : Hier wird der Render-Thread per Render-Driver-Pattern implementiert

Kannst du mir das erklären? Wenn ich er fragen muss, was es tut, ist es meist überflüssig.

Siehe hierzu Shader X7 Kapitel 8.1 Cross platform rendering thread: design and implementation by Guillaume Blanc. Ist die Evaluierung einer Technik, um zu sehen, ob das was bringt. Anders formuliert: ich brauche etwas ähnliche wahrscheinlich im Job, habe da aber nicht genug Zeit, das zu probieren.

Mom, kurz blättern … nee, besitze ich nicht. Keine Zeit, es im Job auszuprobieren, aber um privat einen kompletten Cross-Platform-Renderer mit Engine drumherum zu bauen? Komm schon.

kimmi hat geschrieben:Ziele habe ich bewusst etwas höher gesetzt

Weiter oben:

kimmi hat geschrieben:

• Klein anfangen: Um auch mal was zeigen zu können, habe ich mir die Ziele klein gesetzt.

Ob das Ziel – in drei Monaten eine Engine aufzuziehen, die cross-platform von Embedded XP aufwärts mit OpenGL ES, Direct3D 9 und D3D11 (als Endziel) läuft und von Embedded-CPUs bis High-End-Octo-Cores skaliert – nun klein oder höher ist, sei dahingestellt. Mir drängt sich nur das Gefühl auf, dass du absolut keine Grenzen dafür gesetzt hast, was die Engine tun können soll. Und bei Projekten, deren Funktionalität uferlos ist, ist üblicherweise auch der Zeitaufwand uferlos. Feature-Listen lassen mich auch generell kalt; mich interessieren bei sowas nur Tabu-Listen mit Features, die auf keinen Fall reinsollen.

Drei Monate Urlaub sind da maßlos unterschätzt – ich arbeite ja selber schon seit Jahren an sowas und habe dabei nicht einmal einen Bruchteil der Funktionalität vorgesehen. Klar – wenn du Spielkind bist und das unbedingt testen willst, und dabei auch noch so edel bist den Quelltext und die Erfahrungen hier zu teilen, ist das super. Aber versuch dann nicht den Eindruck zu erwecken, wir würden hier in drei Monaten eine fertige Engine sehen und sorg dafür, dass auch jedem, der sich möglicherweise beteiligen will, klar ist, worauf er sich einlässt: Programmieren um des Programmierens Willen, mit Listen voller „Wie“s, aber keinem einzigen „Warum“, und Feature-Listen die so endlos sind wie der Zeitplan.

kimmi hat geschrieben:STL fällt aus, da ich das Ganze auf Embedded mittels OpenGL-ES 2.0 zum Laufen bringen möchte ( nach D3D9 ), um ein paar Sachen aus zu probieren. Und da wurde aufgrund von Speicher-Fragmentierungs-Problemen dringend von abgeraten, STL zu nehmen.

Wie möchtest du denn die Fragmentierung mit eigenen Container-Klassen minimieren? Bieten dir STL Allokatoren nicht ausreichend Flexibilität? (Mal abgesehen vom etwas unglücklichen / gewöhnungebedürftigen Design.)

Im Moment erkenne ich noch keine wirkliche Zielvorstellung. Du hast dir zwar viel vorgenommen, aber wenn du das ALLEs schaffst, hast du noch immer nicht viel mehr als einen Wrapper auf allerlei APIs. ;-)
(Anmerkung von jemandem, der gerade selbst schon wieder die Dummheit begeht, viel zu viel zu wrappen. :P)

Wegen Minimierung dachte ich an einen Small-Object-Allocator und ggfs. mal einen Stack-Allokator auszuprobieren. Und ich mag den Syntax der STL-Allocatoren nicht, daher die Mühe. Eine eigene std::map baue ich mir definitiv nicht, da bin ich zu faul.

Die Zielvorstellung ist erst einmal der besagte Viewer mit separaten Renderthread, damit ich meinen olles FE-Viewer auf Vordermann bringen kann. Der sieht aus wie Knüppel auf dem Kopf. Und da wollte ich dann mal sehen, was ich in den letzten Jahren so alles dazu gelernt habe. Und danach schaue ich mal, ob man den alten Q3-Map-Loader umstellt auf den aktuellen Kram.

Dazu möchte ich mal evaluieren, wie eine Engine mit mehreren Tasks arbeitet und was für Probleme dabei auftreten. Zur Zeit habe ich das Renderkonzept mit Batching singlethreaded laufen und das ist recht fix.

Konkrete Probleme gehe ich gerade nicht an. Aber das war auch noch nie der Fokus der ZFXCE-Entwicklung, da ging es eher um Rumprobieren mir Dingen wie DX und OpenGL. Das Wissen kam mir bisher im Job zu Gute. Gerade Fragen bezüglich der Architektur finde ich ganz interessant.

Ein Großteil des oben Beschriebenen tut auch schon, mal sehen, wann es was vernünftiges zu gucken gibt. Dauert bestimmt mla wieder länger als gedacht.

Gruß Kimmi

Mal einen kurzen Update, was sich alles seit dem letzten Post von mir in ZFXCE2 getan hat:

• Brot-und-Butter-D3D9-Renderer tut, allerdings wird bisher nur Geometrie gezeichnet, Texturen habe ich noch nicht drinne, da ich erst einmal etwas zum Zeichnen haben wollte und das Importieren von Modellen angegangen bin. Momantan sieht man ein nicht ganz so spektakuläres Dreieck, deswegen zeige ich euch erst ein paar Bilder, wenn man unsere schon oft gezeigte Spinne sieht.
• Das asynchrone Resource-Loading funktioniert zumindest für Assimp-Modelle ganz hervorragend. Das Ganze wird zur Zeit in einem separaten Thread gehandhabt, der von dem Resource-Task gespawt wird. Momentan geht das Laden von Resourcen allerdings wirklich nur in einem separaten Thread. Die Tasks spawnen immer einen Thread, was ich gern optional machen möchte. Die Tasks sind zur Zeit auch noch nicht großartig gescheduled. Ich habe diesbezüglich im Job aufgrund einiger Einschränkungen der dort verwendeten Hardware dafür sorgen müssen, dass Prozesse / Threads eine bestimmt CPU-Auslastung nicht überschreiten. Das ist hier noch nicht drinne, möchte ich aber gern angehen.
• Ich habe jede Menge Fehler aus dem Infrastructure-Bereich gefixed. In der Anwendung geht das halt doch immer noch am besten. Sofern möglich, wurden dann auch immer kleinere Unittests zum reproduzieren von mir gebaut und das klappt ganz gut :).
• Ich hab eine kleine Test-Anwendung gebaut, mit der ich die Container mal etwas stressen wollte. Zur zeit finde ich aber immer noch mehr echte Fehler als Bottlenecks :)...
• Der Render-Task läuft und wird gerade von mir mit Leben befüllt, Assimp sei dank.
• Ein Kumpel wollte das Ganze unter Linux probieren, deswegen habe ich angefangen, OpenGL3.x hochzufahren. Momentan läuft der aber nicht, weil ich die Motivation verloren habe und beim Modell-Laden weiter gemacht hahe.
• Debugging-Sachen wie Memory-Leak-Loggen usw. laufen sporadisch, alles noch weit davon entfernt, perfekt zu sein.

Source ist unter SF zu finden.

Gruß Kimmi

Hi,

ich hatte gesehen, dass es ein ZFXCE V2 Projekt gibt und dachte mir ich versuche einen Beitrag zu leisten. Ich wollte erst einmal autonom arbeiten, da dass Projekt ja - im Neubau - noch recht jung ist und habe mir überlegt ich schreibe die Klassen für eine solide Netzwerkumgebung. Ziel der Netzwerkomponente sollen sein:

- Robustheit durch Intelligente Fehlertoleranz (auf UDP Ebene wahrscheinlich einfacher) und extrapolationen.
- vorbereitete Protokolle für verschiedene Szenarien.

Ich wollte dieses Mal auch nicht anfangen und gleich implementierungen, sondern 2 Planungsphasen definieren und als Deitei im Projekt selbst dokumentieren. Die Phase 1 (bei mir der Grobentwurf als Mindmap) würde ich gern mit euch diskutieren um Ideen zu bekommen.
In der Hoffnung gut dokumentiert zu haben, möchte ich euch meinen ersten Entwurf unkommentiert zeigen und bitte um Meinungen.

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

So, auch ich habe etwas auf die Beine stellen können:

• Asynchron geladenes Modell mittels Assimp geht
• Modell wird vom Render-Task korrekt dargestellt. Dabei wird das Modell gemäß des Vertex-Layouts in einen Batch gepackt und der dann gerendert. Also nichts wirklich kompliziertes, allerdings dauert das halt immer etwas, bis man die entsprechende Infrastruktur hat. Und eine Tochter, die gerade laufen lernt, ist auch nicht gerade der Konzentration dienlich :).

Das Konzept der Tasks hat bisher recht gut funktioniert und ich machen mich nun an die Interaktionen ( in diesem Fall ein einfacher Trackball ) und an das Darstellen von Materialien. Die Spinne ist deswegen noch weiß. Das Laden funktioniert ürbigens mit allen von Assimp unterstützten Formaten, die ich bisher probiert habe ( X, 3Ds und Obj habe ich getestet ).

Gruß Kimmi

Im wahrsten Sinne des Wortes auf die Beine gestellt. Pass auf, dass du den Moment nicht verpasst, in dem deine Tochter zum ersten Mal auf eigenen Beinen steht. ;-)

[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

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

kimmi hat geschrieben: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

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

hi,

kimmi hat geschrieben: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

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

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

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.

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

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:

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

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

Ist zwar jetzt Offtopic, aber...

kimmi hat geschrieben: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

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

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

gruß Kimmi