Engine -- Was muss und was sollte drinnen sein --
-
@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.