Du bist nicht angemeldet.

Stilllegung des Forums
Das Forum wurde am 05.06.2023 nach über 20 Jahren stillgelegt (weitere Informationen und ein kleiner Rückblick).
Registrierungen, Anmeldungen und Postings sind nicht mehr möglich. Öffentliche Inhalte sind weiterhin zugänglich.
Das Team von spieleprogrammierer.de bedankt sich bei der Community für die vielen schönen Jahre.
Wenn du eine deutschsprachige Spieleentwickler-Community suchst, schau doch mal im Discord und auf ZFX vorbei!

Werbeanzeige

marfi

Treue Seele

  • »marfi« ist der Autor dieses Themas

Beiträge: 100

Wohnort: Schwerte

  • Private Nachricht senden

1

23.05.2010, 20:26

Modulare Engine

Hallo liebe Leute,

da meine Game-Engine noch DirectX 9 benutzt und ziemlich konfus ist, überlege ich eine Neue zu programmieren.

Zur Zeit ist meine Engine modular aufgebaut, also zusammengehörige Klassen liegen in einer DLL und können geladen werden.

Die ganzen Funktionen sind gewrappt, damit sich interne Änderungen nicht zwangsläufig auf Apps auswirken die die Engine nutzen.

Nun habe ich ein kleines Gedankenproblem. Wenn ich z.B. eine Vectorklasse in fünf verschiedenen dlls brauche und auch noch in der main, dann füge ich die im Moment in alle dlls ein. Teilweise habe ich mir auch eine static lib programmiert die ich dann nur einbinden muss, damit ich allgemeine Funktionen habe.

Gibt es dafür einen eleganteren Weg?

Von einem großen Projekt mit namespaces halte ich nicht soviel, da man dann immer so lange compilieren muss.

Gruß

Marfi

2

23.05.2010, 20:46

Gibt nicht viele Möglichkeiten

  • in alle Projekte einfügen
  • static lib
  • eigene dll
  • großes Projekt
mehr seh ich da jetzt auch nicht.

unsigned long

Treue Seele

Beiträge: 140

Wohnort: Herzogenrath

Beruf: Fachinformatiker Fachrichtung Anwendungsentwicklung

  • Private Nachricht senden

3

24.05.2010, 08:50

Ich lese wieder das Wort "Engine" und bekomme wieder dieses Zucken hinter'm Auge...

Tipp: Sieh dir mal an wie die Architektur COM funktioniert und überleg mal wie du sie adaptieren kannst, ohne COM direkt zu verwenden. Dann hast du etwas von den Besten.
'Wer der Beste sein will muss nach Perfektion streben und jede Gelegenheit nutzen sich zu verbessern.'
[ bing | not'a'tric | germangamedev | Fragen richtig stellen ]

marfi

Treue Seele

  • »marfi« ist der Autor dieses Themas

Beiträge: 100

Wohnort: Schwerte

  • Private Nachricht senden

4

24.05.2010, 10:29

@unsigned long:

Was gefällt dir an dem Wort "Engine" nicht? Ich denke es ist weit verbreitet und jeder weiß was damit gemeint ist. Wie nennst du deinen Code, der die DXFunktionen verarbeitet und in jedem Spiel wiederverwendet werden kann?

"Core", "Kernel", ....

Deine Idee mit der COM Architektur ist nicht schlecht. Mit meinem jetzigen Modell bin ich davon aber gar nicht so weit weg. Nur mit dem unterschied, dass meine Interfaces automatisch geladen werden.

Welchen Teil der COM Architektur meinst du lößt mein Problem, die benötigten Klassen in jedem Modul zu intergrieren. Der Vorteil wäre, dass die Module nur bei Bedarf geladen werden und nach Gebrauch wieder entladen.

Gruß

Marfi

Beiträge: 774

Beruf: Student

  • Private Nachricht senden

5

24.05.2010, 10:42

Weil ichs an sich in letzter Zeit wieder öfter seh.. ich möchte dezent drauf hinweisen, das Engine != Spiel.
Klar man braucht ein Framework, das ist gut und richtig. Aber man sollte nicht ständig nur an einer Engine feilen, sondern an einem Spiel im Ganzen. Als sinnvoll erachte ich den Ansatz, ein minmales Framework von Projekt zu Projekt tragen und aus jedem Spiel wieder was zu übernehmen, was man leicht allgemein machen kann. Wenn man einfach so eine "Engine" bastelt, fehlt diesem Konstrukt viel zu oft der Praxisbezug. Außerdem ist es imho zu begrüßen wenn man "möglichst wenig Engine" hat. Das macht einen einfach viel flexibler, natürlich ja nach Anwendungsgebiet.
Ein sehr schöner, treffender Artikel wie ich finde hierzu: Write Games, Not Engines

Ist jetzt nicht speziell auf dich bezogen marfi, aber ich denke das sollte man grundsätzlich im Hinterkopf behalten.
Wenn man sich ewig lang drauf versteift ein suuuper Framework haben zu wollen, verliert man das ursprüngliche Ziel viel zu schnell aus dem Blick.

Kann mir vorstellen, dass unsigned longs Zucken hinter'm Auge mit dieser Angelegenheit zusammenhängt, hab ich Recht? ^^

unsigned long

Treue Seele

Beiträge: 140

Wohnort: Herzogenrath

Beruf: Fachinformatiker Fachrichtung Anwendungsentwicklung

  • Private Nachricht senden

6

24.05.2010, 11:18

Wümpftlbrümpftl
Ganz genau.

Engine ist ein Wort womit kein Schwein genau weiß was gemeint ist! Jeder Scheiß wird doch heutzutage als "Engine" bezeichnet. Selbst ein piss Wrapper für die WinAPI. Mal im ernst: Welcher Schwachmat nennt sein WinAPI-Wrapper eine Engine aber die MFC ein Framework? Dieses Wort sagt gar nichts aus und ich finde es persönlich zum Kotzen, dass jeder Idiot alles erstmal als Engine bezeichnen muss. Ich habe selbst hier des öfteren gelesen, das Leute die Schnittstellen aus dem DirectX SDK eine Engine nannten. Huhu? Eine API als Engine zu bezeichnen ist wie eine Audienz beim Papst als Hardcore Porno zu bezeichnen!!

Das Wort sollte man auf den Index in jedem Board stellen.

marfi
Framework nenne ich mein Basiskonstrukt, da es eine Zusammenstellung von Wrappern und Kapselungen ist, das zusammen agiert.

Du sollst ja COM nicht direkt implementieren, das würde es nicht bringen, da es sonst mit dem COM-Server des Betriebssystems agiert. Du brauchst etwas losgelöstes.

Aber: Du könntest alles von einem Basisinterface ableiten (IUnknown) und deine jeweiligen Implementierungen in einzelnen DLLs/SOs auslagern. Siehe wie DirectX selbst. Dazu hättest du den Vorteil der Versionierung deiner einzelnen Module wie z. B. Grafik.
'Wer der Beste sein will muss nach Perfektion streben und jede Gelegenheit nutzen sich zu verbessern.'
[ bing | not'a'tric | germangamedev | Fragen richtig stellen ]

marfi

Treue Seele

  • »marfi« ist der Autor dieses Themas

Beiträge: 100

Wohnort: Schwerte

  • Private Nachricht senden

7

24.05.2010, 14:13

@unsigned long:

Aus dem Winkel betrachtet hast du natürlich Recht mit deinem Augenzucken. Aber ich nenne mein Konstrukt trotzdem so :D

Meine "Engine" ist aber eigentlich aus einem Spiel heraus entstanden. Und hat relativ viel Praxisbezug und leider auch eine Größe, die mich manchmal verzweifeln läßt. Leider ist das Spiel nicht fertig geworden (wie so oft). http://developia.de/developia/viewarticle.php?cid=32647

So, genug davon.

Deine Idee finde ich gar nicht schlecht. Bisher habe ich für jede DLL ein eigenes Interface. Ich muss also Grafik, Sound, Netzwerk, AI und Physik extra laden und das vorhandene Interface nutzen. Ich werde mir die Sache mal durch den Kopf gehen lassen. Grundsätzlich ist es aber bei mir schon so, dass ich jetzt z.B. Gfx.dll neu implementieren kann (z.B. DX10) und in meinem Game die gleichen Funktionsaufrufe nutze. Meine Interfaces bestehen alle Klassen mit virtuellen Funktionen. Diese sind in einer Lib zusammengefasst. Mit CreateDevice() und GetDevice() kann ich dann auf die implementierten Funktionen zugreifen. Ähnlich dem QueryInterface() und AddRef(). Mit dem GrafikDevice kann ich dann verschiedene "Manager" aufrufen, wie z.B. Sprite, Texture, Cam, ... Das führt aber manchmal zu sehr langen Verschachtelungen und Funktionssprüngen. Hier ist mal ein Beispiel vom TextureManager innerhalb des GFX Device. Die Implementierung ist von diesem Interface abgeleitet und befindet sich in der DLL.

C-/C++-Quelltext

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
class IM3DTextureManager 
{public: 
IM3DTextureManager(void){}; 
virtual ~IM3DTextureManager(void){}; 
// Add Texture to Array returns -1 if fail 
virtual int Add(char* Filename,M3DCOLOR* ColorKey = NULL, float fAlpha =1.0f, void* pTexture =NULL, bool bAlpha=TRUE,char* AlphaTexname = NULL,float fWidth=0, float fHeight=0,bool bOrigSize =true)=0; 

// Remove from Array 
virtual void Remove(int TextureID)=0; 
virtual void RemoveAll()=0; 
// Get the Grafik-extentions 
virtual POINT GetTextureExt(int TextureID)=0; 
// Create Texture and return a ID to it returns -1 if fail 
virtual int CreateTexture(DWORD *Content,int SizeX,int SizeY)=0; 
// Create Texture with Palette and return a ID to it returns -1 if fail 
virtual int CreateTexture8Bit(DWORD *Content,int SizeX,int SizeY)=0; 
// change the content of a Texture 
virtual HRESULT ChangeContentOfTexture(DWORD *Content,int TextureID)=0; 
// Get content of Texture as DWORD array and returns the size of array. 
// ContentOut must be allocated !!! 
virtual POINT GetContentOfTexture(DWORD *ContentOut,int TextureID)=0; 
// Change one Color of Texture 
virtual void ChangeColor(int TextureID,M3DCOLOR SrcColor,M3DCOLOR DestColor)=0; 
  
}; 

Der Aufruf dann im gfx Device 

class IM3DGFXDevice 
{public: 
IM3DGFXDevice(void) {}; 
virtual ~IM3DGFXDevice(void) {}; 
... 
virtual IM3DTextureManager* CallTextureManager(void)=0;... 
}; 

typedef class IM3DGFXDevice *LPM3DGFXDEVICE;

xardias

Community-Fossil

Beiträge: 2 731

Wohnort: Santa Clara, CA

Beruf: Software Engineer

  • Private Nachricht senden

8

24.05.2010, 20:55

Huhu? Eine API als Engine zu bezeichnen ist wie eine Audienz beim Papst als Hardcore Porno zu bezeichnen!!
Naja... wenn du als junger Knabe die Audienz hast... ich wäre bei dem Vergleich vorsichtig. :lol:


(PS: Entschuldigt das Off Topic)

drakon

Supermoderator

Beiträge: 6 513

Wohnort: Schweiz

Beruf: Entrepreneur

  • Private Nachricht senden

9

24.05.2010, 21:02

Huhu? Eine API als Engine zu bezeichnen ist wie eine Audienz beim Papst als Hardcore Porno zu bezeichnen!!
Naja... wenn du als junger Knabe die Audienz hast... ich wäre bei dem Vergleich vorsichtig. :lol:


(PS: Entschuldigt das Off Topic)

Genau das gleiche ging mir auch durch den Kopf, als ich seinen Beitrag gelesen habe.. :D

Werbeanzeige