Engine -- Was muss und was sollte drinnen sein --
-
Was meinst du mit großen Konzept? Ich bin noch der meinung, dass uch erstmal klein anfangen sollte. Es lohnt sich aber nucht eine Engine für PingPong zu programmieren. (Ich hatte mit der WinAPI mal diverse Spiele programmiert)
-
Ja ich mach die mit DirectX9
@malignate: Klar kommen so Sachen bei mir auch noch rein.
Kollisionserkennung ist sowieso klar. Hab ich bloß vergessen... ^^
So Dinge wie Editoren oder ein Plug-In-System kommen bestimmt auch noch irgendwann, allerdings halte ich das jetzt erstmal für nicht ganz so wichtig wie die anderen Dinge wie Grafik und Input
Ich werde die Engine sowieso nach und nach um einige Module erweitern und wahrscheinlich auch einige Dinge immer mal wieder erneuern.Im Moment schreib ich an einer Art von Verwaltungsklasse.
Ist ne Singletonklasse. Diese Klasse verwaltet dann alles was das jeweilige Programm von der Engine braucht. Über eine Methode mit dem sehr sinnvollen Namen "Init()" wird die Engine dann hochgefahren. Mit verschiedenen Flags in Form eines DWORDs kann man der Engine dann sagen was hochgefahren werden soll.
Irgendwann stehen dann hier mal Grafik, Sound und Input zur Verfügung. Das lässt sich jedoch jederzeit erweitern! So kann ich dann später Plug-Ins und so noch hinzufügen.
-
@Ocin Und wenn dir das ganze dann nicht mehr gefällt fangst du von vorne an. So gings mir am Anfang auch. Mittlerweile mache ich mir halt immer mehr Konzepte. Da machte das reine Coden nicht mehr so viel aus.
-
malignate schrieb:
Mach dir mal über die großen Konzepte Gedanken. Ist doch scheiß egal wie dann die Klassen heißen. Der einzigste Unterschied zwischen DX und deiner Engine ist bisher die HeightMap.
Quatsch. so wie er es macht, ist er aufm richtigen Weg. zuerst wrappt er die funktionalität. danach benutzt er es und merkt: ne, so wirklich gefällt mir das noch nicht, das ist einfach noch zu komplex. dann wird er sich um seine Wrapper weitere Klassen bauen, zb eine Klasse die texturen läd, verwaltet und wenn sie nicht mehr gebraucht werden, automatisch freigibt. Dann wird er merken: ok, ich hab eine Klasse der ich einfach nur nen dateipfad sagen muss, und sie erstellt mir dann ganz toll meine texturen, aber nun möchte ich was aus archiven laden und das kann ich nicht ohne weiteres. Ok, das ist ein designfehler. Das ist doof, aber aus fehlern lernt man. Er schreibt die Klasse so um, dass sie aus einer virtuellen datei (oder aus zb einem std::vector<char>) eine textur erstellt. Super. nun braucht er nurnoch aus dem archiv lesen und die textur vor dem erstellen in den Speicher mappen.
Dasselbe muss er jetzt natürlich auch mit texturen machen, die sich in einer echten datei befinden, aber irgendwo hat man immer ausschuss ;).Nun benutzt er diese 3 Klassen(texture factory +2 mapper klassen), aber jetzt ist er wieder unglücklich: die Funktionalität ist absolut in ordnung aber er vermisst die einfachheit texture.create("textures/Toll.tga"); schreiben zu können.. Er denkt, und kommt auf die idee, dass man mit ein bischen trickserei archivinhalte und echte dateien so darstellen könnte, als ob sie im selben ordner währen. Das virtuelle dateisystem ist gebohren.
Und nu? Er ist schon ganz nah am ziel, texture.create("textures/Toll.tga"); schreiben zu können. Eine Sache fehlt aber noch: ein endgültiger Wrapper um diese beiden Klassen.
Durch ausprobieren und schritt für schritt eine Klasse auf die andere Bauen lernt man viel mehr und muss vorallem nicht andauernd alles neuschreiben(sondenr wie oben im Beispiel nur einen kleinen Teil), wenn etwas nicht so funktioniert, wie mans gerne hätte. Vorallem ist man um einiges motivierter, da man in viel mehr phasen wirklich testen kann, was schon geht. Das Projekt fängt klein an, und wird dann von selbst immer größer, ohne dass man davon erschlagen wird.
-
Was ist der Unterschied zwischen Engine und Wrapper?
Sollte man die Libs schon währen der Entsehungsphase in ne Dll Packen??
Hab mir jetzt noch ein Buch bestellt, ich hoffe, das es mir weiter Hilft,
Titel "OpenGL Game Programming"
Was sollte man überhaupt son in Die Kernelklasse der Engine reinpacken???
-
@otze Kommt halt auf das Vorwissen an. Aber da er anscheinend noch nicht soweit ist ist dein Weg wohl der richtige.
-
Zu Wrapper siehe: http://de.wikipedia.org/wiki/Hüllenklasse
-
malignate schrieb:
@otze Kommt halt auf das Vorwissen an. Aber da er anscheinend noch nicht soweit ist ist dein Weg wohl der richtige.
ich programmiere meine grafikengine genauso ;).
1. ebene: Die großen Interfaces(IDirect3DDevice9 als Beispiel) werden in kleinere aufgeteilt. Wrapper um alle Interfaces, sodass das lästige Zeigergedöns weg ist. Auch wird eine Referenzzählung eingeführt, sodass man nie mehr Release() aufrufen muss.
2. ebene: Um die Interfaces werden erste Klassen gebaut die die Funktionalität vereinfachen(zb Shader oder Material)
3. ebene: Fabriken für die Klassen der 2. ebene
4. ebene: allerei Verwaltungs-Schnickschnack für die Objekte die die Fabriken ausspucken.
to be continued...
btw: Kollisionserkennung muss nicht unbedingt in einer Engine drin sein, kommt immer drauf an was man machen will. Für ein Programm dass Renderbidler ausspuckt braucht man zb keine Kollisionstests
Klar, ich teste nicht andauernd, ob mir gefällt, was ich gemacht hab. aber ich denk immer nur einen Schritt weiter. Es ist unnütz an einen Scenegraph zu denken, wenn man grad eine Factory für IndexBuffer baut
-
Wie gesagt, mir gefällt mein Framework net. Funktioniert gut, einigermaßen gut Strukturiert, aber naja. Werd wahrscheinlich am Wochenende ein neues und dynamischeres schreiben. Ich hab aber Probleme die WndProc einzubinden, da ich keine ahnung von der STL habe. Man kann es ja irgenwie mit Map und Multimap machen.
-
deine engine sollte erstmal garnichts mit der WndProc zu tun haben
-
Warum , ohne solides Framework läuft eh nichts.
-
Tc++H schrieb:
Warum , ohne solides Framework läuft eh nichts.
es ist nicht aufgabe einer graphik lib gleich noch das fenster mit zu erstellen. In einem editor wird man immer ein bestimmtes fenster als ziel haben, und nicht eins das von der lib erstellt wird. ein Fenster mit eigener WndProc bei der du nicht rumpfuschen darfst.
(ausserdem hast du den begriff framework wahrscheinlich net ganz richtig verstanden,imho)
-
otze schrieb:
es ist nicht aufgabe einer graphik lib gleich noch das fenster mit zu erstellen. In einem editor wird man immer ein bestimmtes fenster als ziel haben, und nicht eins das von der lib erstellt wird. ein Fenster mit eigener WndProc bei der du nicht rumpfuschen darfst.
mach ich anderes, ich biete ein sdl fenster an, die nachrichten verabeitete ich. es besteht die möglichkeit ein anderes fenster ala windows oder what ever als rendertarget anzugeben aber dann sollte der user alle nachrichten in den eventhandler selber pumpen oder einfach anderes abfangen wie er möchte.
wie händelst du den die eventhandler geschichte oder hast du keinen (planst keinen). ps: ich rede von einer render lib nicht von einem framework.
-
naja, unter DX muss man ja net soviele nachrichten abfangen. höchstens das minimieren und maximieren...ich plan erstmal nur 2 funktionen die der user dann aufrufen sollte, eine zum freigeben der resourcen beim minimieren, und eine zum reallokieren...
-
Ich weiß schon, das Frame Framework und Grafik-Lib nicht wirklich miteinander zu tun haben. Aber ich brauche ja ein Framework, damit ich mein Grafikzeugs testen und verbessern kann. Die Framework Klasse enthält am Enden von der Grafik-Lib nur eine Instanz.
-
du solltest dir echt die definition des wortes "framework" durchlesen
-
wobei eine graphik-lib nicht alles sein muss, was eine engine ausmacht. meine engines können, angelehnt an wgl, ein fenster aufmachen das am besten zu dem gewünschten parametern passt. eine wirklich gute engine stellt dem enginebenutzer _alles_ zur verfügung was nötig ist, sodass keine anderen libs verwendet werden müssen.
natürlich muss niemand eine perfekte engine haben, aber das ist das, was eigentlich eine der sachen, die eine engine zu mehr macht, als zu nur einer lib.rapso->greets();
-
Ja, hab den Begriff "Framework" wohl falsch verstanden, hab mir aber jetzt ein objektorientiertes brauchbares Fenstersystem aufgebaut. Die Leute aus der API haben mir geholfnen. Ich wollte keine SDL verwenden, wenn man alles selber macht, kann man auch sagen, das man es alleine gemacht hat.
-
Tc++H schrieb:
Ja, hab den Begriff "Framework" wohl falsch verstanden, hab mir aber jetzt ein objektorientiertes brauchbares Fenstersystem aufgebaut. Die Leute aus der API haben mir geholfnen. Ich wollte keine SDL verwenden, wenn man alles selber macht, kann man auch sagen, das man es alleine gemacht hat.
Und man kann sagen, man hat ne menge funktionalität wieder mal dupliziert und noch 'm paar mehr bugs reingemacht.