spieleprogrammierer.de - Forum und Wiki zur Spieleprogrammierung und Spieleentwicklung

Ich habe vor etwa 1.5 Jahren mit meiner eigenen Engine angefangen und die ist nun auch schon seit langer Zeit fertig. Nur ist die leider sehr schnell an ihre Grenzen gestossen, da ich einfach ohne Plan drauflosgecodet habe. Ausserdem habe ich meine Programmierkünste in der Zeit auch einiges weiterentwickelt und jetzt sieht mein Codingstil in der Engine für mich auch sehr lächerlich aus.

Deshalb möchte ich nun noch mal ganz von vorne anfangen und zuerst ausführlich planen. Allerdings habe ich sowas noch nie gemacht und ich kenne mich auch nicht wirklich mit Design Patterns aus. Ich habe mir aber den Aufbau von ein paar OpenSource-Engines angeschaut...

Ich habe aber mal versucht eine kleine Beschreibung zu machen, wie das nachher ausschauen soll (also vorallem die Klassenhierarchien). Es ist noch nicht vollständig aber so wie ich das sehe ist es leicht erweiterbar.

Zum Design-Dokument (PDF)

Ich wäre nun sehr froh darüber wenn mir ein paar erfahrenere Leute die schon grosse Projekte bewältigt haben ein kleines Feedback geben könnte was ich falsch mache oder ob ich gar alles falsch mache, dann sollte ich mir wohl besser zuerst ein paar Bücher kaufen.

Zitat von »"Osram"«

Der Name "Object" ist schlecht, das könnte z.B. auch die Basisklasse aller anderen Objekte sein. Ich habe schon "renderable" gehört, das ist ein sprechender Name.

Gute Idee, danke!

Zitat von »"Osram"«

"Core" gefällt mir auch nicht wirklich, warum ist ein Vector in "core" und warum nimmst Du nicht den von D3D(X) ?

Wenn ichs mir recht überlege wäre "Math" wohl besser geeignet. Den einzigen Vektor den ich aus DirectX kenne ist D3DVECTOR und das ist eine Struktur (also hat auch keine definierten Operatoren => Zum rechnen unbrauchbar). D3DX will ich nicht verwenden.

Zitat von »"Osram"«

Was macht "Userdefined" was 3DObject nicht macht?

Es stellt Funktionen zum direkten Eingeben der Vertex- und Indexdaten bereit, was ich zum Beispiel in Model eigentlich nicht möchte.

Zitat von »"Osram"«

Lightning soll wohl Lighting heissen.

klar

Zitat von »"Osram"«

Ich persönlich sehe GUI neben Grafik, nicht darunter. Es braucht aber natürlich Grafik.

Eigentlich hast du recht, es verarbeitet ja auch Input (Mausklicks, Texteingabe, ...)

Zitat von »"Osram"«

Image würde ich in Grafik packen und Media wäre dann Sound.

Ich habs eigentlich Media genannt, da ich vielliecht mal Video einbauen will und das könnte man dann auch dort unterbringen, aber Image wäre schon passender in Graphic...

Zitat von »"David_pb"«

Ich würde allerdings den ganzen Matheblock in einen eigenen Namespace (von mir aus auch unter Core) packen.

Wie gesagt werde ich Core wohl ganz in Math umbenennen.

Zitat von »"David_pb"«

Warum du allerdings ein Singleton für dein Logfile Objekt verwenden willst ist mir nicht ganz klar. Es kann durchaus mehrere Logdateien geben, daher macht die verwendung des Singletons hier keinen Sinn.

Ich habe eigentlich nicht vor irgendwann mal mehrere davon zu verwenden, meine Intension ein Singleton daraus zu machen war aber auch das ich dann von überall her einfach auf die Klasse zugreifen kann.

Zitat von »"David_pb"«

Memory als Klasse mit statischen Funktionen? Ich weiß nicht genau was du da reinpacken willst, aber statisch würd ich sowas nicht unbedingt machen. Bzw, sags mir wenn ich dich hier falsch verstehe.

Meine Idee war damit Speicherlecks zu verhindern, indem die Klasse Methoden wie New und Delete bereitstellt, die ich im Release-Modus einfach als Inline-Template durch new und delete ersetze. Im Debug-Mode soll dagegen jede Speicherreservierung registriert und jede Freigabe wieder deregistriert werden. Am Schluss kann man denn genau ausgeben wo es Spiecherlecks gab. Diese Funktionen müssen von überallher aufrufbarsein und da sie auch sehr oft aufgerufen werden müssen, wollte ich es nicht als Singleton implementieren, da ich sonst immer HF::Memory::instance()::New() schreiben muss anstatt HF::Memory::New(). Ich verwende auch nur ungern eine statische Klasse, also wenn jemand eine besser Idee dazu hat: her damit!

Zitat von »"David_pb"«

Ganz nett ist die Dokumentation der NeoEngine2, die du dir evtl mal ansehen solltest:

Danke, mach ich heut Nachmittag dann.

Zitat von »"David_pb"«

Achja, wieso verwendest du nicht STL Kontainer statt eigener Kontainerklassen? Du kannst mir glauben das du dir viel Arbeit und Ärger ersparst wenn du das tust!

Ich habe bis jetzt eigentlich immer meine eigene Listenklasse verwendet da sie einfacher zu handhaben ist und nur das enthält was ich brauche. Im Sinn von sauberem C++-Coding wäre es wohl doch eine gute Idee mehr mit der Standardbibliothek zu arbeiten...

Zitat von »"David_pb"«

Dann stecken deine Kontainer ja auch in Core?

Nein, ich hab die Listenklasse gestrichen und werde std::list verwenden. Dann bleiben nur noch mathematische Dinge und die kann man dann ruhig in den Namespace "Math" packen.

Zitat von »"David_pb"«

Halt ich für weniger geschickt. Hier würde eine Singleton wesentlich mehr Sinn ergeben. Zur not kannst du ja per Makro eine "Umleitung" basteln.

Ich wollte Makros ja nach möglichkeit vermeiden, aber hier scheint es wohl doch die beste Lösung zu sein, danke.

Zitat von »"grek40"«

Ich würde an deiner Stelle garnicht viel ändern sondern nur den Konstruktor public machen (Copy private lassen). Damit behältst du deine überall verfügbare Instanz, andere die die Engine verwenden können aber auch weitere Logs erstellen.

Vielen Dank, klingt nach einer guten Lösung, so werd ichs machen.