Design eurer Engines

[evaluations]

Hallo,
ich glaub zar, das es ein Thread in dieser Art schon mal gab, aber ich hab mit der Suche nichts wirklich informatives gefunden.

Wie baut ihr eure einzelnen Teile der Engine auf ?

Bye

[ethereal]

Meinst du die Verlagerung der funktionen in versch. dateien ?
wenn ja, also ich schraub gerad an'ner dx-engine, so ne art wrapper halt, damit man net immer alles von vorne machen muß.
da gibt's dann immer ne header und sourcedat. und eine header bindet alles ein.
mein traum isses (;-) , die ganzen funktionsdef. in ne dll zu packen, hab mich damit aber noch net befasst und weiß dementsprechend nich, wie man das macht,...naja, vielleicht hilft mir ja jemand
gruß
e-the-real

[Kane]

Normalerweise ist es auch so das du die Daten und ihre Präsentation
immer getrennt verwaltest.

z.B.
Hast du einen Verwalter für alle geladenen Sounds, Streams usw.
benutzt werden diese Resourcen allerdings nicht direkt, sondern
von Soundquellen, die im Level verteilt sind.

Ok, das war jetzt supersimpel. Aber jede Engine die ich bisher gesehen habe
macht das in der Richtung.

[DocJunioR]

Meines erachtens ist das komplexeste erstemal des Datenmodell.
Du musst Dir überlegen, wie Du Objekte und Wände (so es eine Indoor-Engine ist) organisierst; Sowohl im Speicher als auch in der Leveldatei. Ich persönlich bevorzuge hierfür Klassen. Das Binärbaumsystem ist hier ganz Praktisch.
Außerdem ist hier die Steuerschnittstelle für Bewegung und Aktion der Objekte.

Ich sehe für meine Klassen immer eine Lade- und Speicherfunktion vor. So brauch ich keine extra Klasse für nen Leveleditor schreiben.

Wenn Du die Objekte organisiert hast, kannst Du anfangen, sie darzustellen.
(Auch hier benutze ich persönlich eine Klasse. Wer's nicht mag, machts halt anders.)

Diese lässt zuerst die Leveldaten laden und stellt sie anschließend dar.
Außerdem sollte der Sound und die Event-Handler-Funktionen (zumindest zur Spielsteuerung) implementiert sein.

Ich weiß nicht, ob das ein optimales Design ist, aber Tipps nehme ich eh immer gerne an, solange sie sachlich sind

cYa
DjR

[rapso]

es kommt vielleicht ein wenig auf die engine an

ich hab nur ladefunktionen für die meißten speicherintensiven resourcen in der engine (z.B. texturen,meshes) und für verbindungen von denen hab ich einen scenenbaum, der verbraucht kaum speicher und ist auch wieder abspeicherbar.

wenn man resourcen als readonly hat, kann man sein OS dazu veranlassen diese nicht immerwieder auslagern zu müssen, wenn also ram knapp wird und ein ReadOnly segment ausgelagert werden soll, wird das OS diesen bereich einfach verwerfen (ohne ihn vorher auf platte zu schreiben, weil sich ja nichts verändert hat) und sofort nen anderen speicherblock von der plate da einladen. das bringt bei großen scenen 40% performancegewinn (gemessen) in manchen fällen. dazu sollte man sich "mamory mapped files" für sein OS ansehen.

die speicherintensiven resourcen sollte man versuchen in der scene nie zweimal zu haben, also falls zwei verschiedene objekte das selbe mesh benötitgen, dann wird beiden nur der pointer aufs mesh übergeben, man sollte es nicht zweimal laden, weil sonst beim kopieren eines objektes sinnlos speicher verschwendet wird.
kleinere dinge z.B. eine camera, lichtquelle, objekte sollten kopiert werden und in dem zusammenhang ihrer verknüpfung möglichst nah aneinander im speicher liegen. wenn du also weißt, dass du immer erst auf ein objekt zugreifst und dann das objekt auf seine material-class zugreift, sollten beide lieber beieinander liegen, anstatt das material nur einmal im speicher zu haben und dann im speicher rumzuspringen...

das schlimmste was wohl passieren kann ist ein festplatten (oder anderes medium z.B. CD) zugriff und wenn man schon an die organisation seiner engine denkt, sollte man dafür optimierungen finden, weil ein spiel (wenn eine festplatte aus dem standby hochfährt) dann sekundenlang stehen könnte oder bei schlechter optimierung dauernt von der HD nachladen müßte.

also kurz:
-kompakte classes(objekte aus den klassen) so organisieren, dass sie ihrer nutzungsreihenfolge entsprechend nah beieinander sind
-große resourcen "shared" und "readonly" machen (möglichst)

das wäre das, was mir einfällt was wohl für jede engine wichtig ist.

rapso->greets();

[cpt.oneeye]

ethereal schrieb:

mein traum isses (;-) , die ganzen funktionsdef. in ne dll zu packen, hab mich damit aber noch net befasst und weiß dementsprechend nich, wie man das macht,...naja, vielleicht hilft mir ja jemand
gruß
e-the-real

dll-tutorial -> http://www.resourcecode.de/view.php?id=776

[ethereal]

jo, dankeschön...
hilft bestimmt !
gruß
e-the-real