Engine -- Was muss und was sollte drinnen sein --

[Tc++H]

Wofür: Egoshooter oder Strategie(was C&C Tiberian Sun ähnliches)

[TGGC]

Japp, ist doch ehh genau das Gleiche.

Bye, TGGC (Demo or Die)

[Tc++H]

Warum das gleiche???

[ChockoCookie]

Tc++H schrieb:

Wofür: Egoshooter oder Strategie(was C&C Tiberian Sun ähnliches)

Ich meinte nicht das Genre. Ich meinte das eher so: "Du merkst eh, wenn du zB dann einen Timer brauchst um zu Wissen, wieviel die Rakete sich von Frame zu Frame bewegt."

@TGGC: LOL Motor mit integriertem Tank. Hoffentlich funzt die Wärmedämmung, sonst war das mal ein Auto.

[_Ocin_]

Hi

Also wie schon einige vor mir erwähnt haben kommt es immer drauf an für was die Engine benutz wird.

Ich schreib mir auch gerade ne Engine und ich schreib dir einfach mal was ich so reingemacht habe oder noch reinmachen werde. Man kann die dann später ja immernoch erweitern.

Den ganzen Mathematikkram:
- Vectorklassen und Funktionen (sowohl 2D als auch 3D)
- Matrixklassen und Funktionen
- Ebenenklassen und Funktionen

Grafikteil:
- Klassen für Vertex- und Indexbuffer
- Texturverwaltungsklassen
- Modellklassen
- Partikelsystem
- irgendwas für 2D-Menüs (GUI)
- Klassen für Effekte

Soundteil:
- Soundeffekte
- Musik
- 3D-Sound (so mit Dopplereffekt und so...)

Inputteil:
- Verwaltung der verschiedenen Eingabegeräte
- Maus und Tastatur (is ja klar)
- evtl. Joystik

Sonstiges:
- Speicherverwaltung
- Logfilesystem

Das waren jetzt so mal ein paar Sachen, die man eigentlich immer mal brauchen kann. Ich werd dann wohl noch einige Formate konvertieren (also mein eigenes Sound und Bildformat schreiben. Dann werde ich dann alle WAV- und BMP-Dateien dahin konvertieren. Für Modelle wärs natürlich auch cool aber ein 3ds-Konverter ist wohl schon einiges an Arbeit )

Hoffe das hat dir irgendwie weitergeholfen

Mfg Nico

[Tc++H]

Vieln Dank, hast mir weitergeholfen.
Schreibst du sie in D3D ???

Ich hab jetzt auch noch ne Klasse ZpColor und ZpMaterial erschaffen

[Manuelh87]

@ TGGC
Vergaser ist aber old_school! Jeder halbwegs sparsame und moderne pkw hat heutzutage eine Einspritzanlage!

Und bei den auf uns zu kommenten Spritpreisen sollte man da schon auch an wirtschaftlichkeit denken...

(Auch mal ne runde klugscheißeren...; nicht böse nehmen!)

@ Tc++H
Ja was für ne Engine machst du denn? 3d? 2d?
Ich hab das gefühl du möchtest ne 3d machen. Stimmt das?
Und noch ne frage: ist es deine erste 3d/2d engine oder das erste große projekt?
Und was möchtest du dann im endeffekt damit machen?

Vielleicht kann ich dir ja helfen (falls dus überhaupt nötig hast??) aber da müsst ich schon genauer bescheid wissen...

Ich schreib grad an meiner ersten richtig großen engine und hab vielleicht auch ein paar sachen die dich interessiern könnten... bisl was hab ich ja auch schon fertig.

cu

[malignate]

Das wird keine Engine, Ocin, sondern ein Wrapper. Da fehlt noch einiges. Mach dir zusätzlich zu den Sachen von Ocin noch ein paar Gedanken über folgende Dinge:
- Editor
- Szenemanegement
- Plugin-System
- Databases/VFS
- Collisionen

Schau am besten mal bei den gängigsten Engines durch. Sehr übersichtlich ist Ogre/Axiom, Qube und Irrlicht, vielleicht noch Nebula.

[Tc++H]

Ja es soll eine 3D Engine werden. Hatte schon einige Projekte angefangen, aber gab die Hälfte wieder auf, da mein Klassenkonzept nicht sonderlich gut war. An C++ Praxiserfahrung hatte es auch gemangelt (Ich muss mein C++ auch noch verbessern bin mittelmäßig eventuell bis Fortgeschritten). Ich würde mich echt total auf Hilfe freuen. Ich programmiere sie nebenbei, hab ja auch noch Schule.

Ich will auf keinen Fall glut oder alut benutzen.

Hab mir schon ein paar Klassen ausgearbeitet:
- ZpVector --> Ferting (mit Templates)
- ZpColot --> Fertig
- ZpMaterial--> Fertig
- ZpTGALoader--> Fertig
- Zp3DSLoader --> gerade im Bau
- ZpHeightMap --> gerade im Bau

Braucht neues Konzept (waren aber schon fertig):
- ZpApplication
- BmpLoader ohne Glut
- ZpLog

Im Konzept
- ZpSound mit OpenAL
- OpenGL Befehle OpenGL in eine Klasse gepackt
- OpenGL generiert eine Schnittstelle
- ZpCamera
- ZpParticle
- ZpPhysic
- ZpEffect

[malignate]

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.

[Tc++H]

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)

[_Ocin_]

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.

[malignate]

@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.

[otze]

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.

[Tc++H]

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???

[malignate]

@otze Kommt halt auf das Vorwissen an. Aber da er anscheinend noch nicht soweit ist ist dein Weg wohl der richtige.

[PuppetMaster2k]

Zu Wrapper siehe: http://de.wikipedia.org/wiki/Hüllenklasse

[otze]

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

[Tc++H]

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.

[otze]

deine engine sollte erstmal garnichts mit der WndProc zu tun haben