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

BlazeX

Alter Hase

  • »BlazeX« ist der Autor dieses Themas

Beiträge: 478

Wohnort: DD

Beruf: Maschinenbau-Student

  • Private Nachricht senden

1

29.10.2008, 10:56

2 Probleme: Fenster und Direct3D, DLLs "vieleicht"

Hi Leute!
Ich habe da wieder mal 2 Probleme.
Beim ersten geht es darum für Direct3D geschickt ein Fenster bereit zu stellen.
Und beim Zweiten: Was ist mit DLLs, bei denen nicht feststeht ob sie wirklich benötigt werden. -> Nur Laden wenn benötigt.

Ich fang mal mit dem Zweiten an:
Ich habe vor eine kleine 3D-Grafik-Engine zu schreiben, die Direct3D 9 und 10 unterstützt. Wenn der Gamer wählt, welche Version er will, sollte die entsprechende DLL geladen werden.
Aber mit "pragma comment(lib, ..." bekomme ich jetzt schon bei Programmstart die Fehlermeldung "DLL XXX nicht gefunden!".
Kann ich DLLs dynamisch laden OHNE vollständig von LoadLibrary abhängig zu sein. Denn D3D und D3DX haben nicht wenig Funktionen.
Gibt es da eine Möglichkeit die DLL erst zu laden, wenn sie benötigt werden?

Und jetzt zu der Sache mit dem Fenster
Wie oben beschrieben, habe ich D3D9 und 10, beide benötigen für ihr Device ein Fenster. Dies sollte der User zur Not auch selbst erstellen können, wenn er z.B. ein Dialogfenster hat, und irgendein Control darin auserkoren hat, zu D3D überzulaufen.
Das ganze sollte auch robust ein, wie plötzliches minimieren, Größenverhältnisse ändern, etc. Also auf WM_??? reagiren.

Da habe ich für mich 2 Möglichkeiten gefunden, zwischen denen ich mich anicht so richtig entscheiden kann.
Wichtig ist, dass für das Spiel an sich einfach einfertiges Fenster da sein muss. Und für einen Editor muss ein Fertiges angegeben werden können.
So wie das die TriBase macht gefällt mir nicht so, das es nicht gerade robust ist.

(1) Ich mache eine "Fenster-Basisklasse", von der dann beide Render abgeleitet werden.
Per virtuelle Funktionen a la "OnExitSizeMove" wird der Renderer dann auf veränderungen aufmerksam gemacht.
Pro
- Alles unter einem Hut
- Es ist komfortabler für den User, wenn er eigene Klassen ableiten kann.
Contra
- Der User hat weniger Freiraum

(2) Window und Renderer sind getrennte Klassen, die über "MessageQueues" miteinander kommunizieren.
Pro
- ist flexibler
- ist MultiThreading sicher, und bietet mehr Performance, da der Window- Thread nur auf GetMessage wartet, und somit nichts verbraucht.
Contra
- Das wird ein ganz schöner Overkill

Was haltet ihr davon?
Wie habt / würdet ihr sowas angehen?

Danke im Voraus!

David_pb

Community-Fossil

Beiträge: 3 886

Beruf: 3D Graphics Programmer

  • Private Nachricht senden

2

29.10.2008, 12:09

Re: 2 Probleme: Fenster und Direct3D, DLLs "vieleicht&a

Zitat von »"BlazeX"«


Aber mit "pragma comment(lib, ..." bekomme ich jetzt schon bei Programmstart die Fehlermeldung "DLL XXX nicht gefunden!".


Dann fehlt vermutlich die Dll im entsprechenden Suchordner...

Zitat von »"BlazeX"«


Kann ich DLLs dynamisch laden OHNE vollständig von LoadLibrary abhängig zu sein.


Nein, dynamisch laden bedeutet LoadLibrary & Co. Außerdem bringt dynamisches laden ein weiteres Problem mit sich. Du kannst keine exportierten Klassen importieren. Der Standard "Workaround" hierfür ist eine Methode, die dir einen Zeiger auf dein Klassenobjekt liefert.

Zitat von »"BlazeX"«


(1) Ich mache eine "Fenster-Basisklasse", von der dann beide Render abgeleitet werden.
Per virtuelle Funktionen a la "OnExitSizeMove" wird der Renderer dann auf veränderungen aufmerksam gemacht.
Pro
- Alles unter einem Hut
- Es ist komfortabler für den User, wenn er eigene Klassen ableiten kann.
Contra
- Der User hat weniger Freiraum


So ähnlich hab ich das in meinem Framework implementiert. Allerdings ist der Renderer kein Spezielles Fenster (Abgeleitet). Der Renderer weiß nur in welches Fenster gerendert werden soll.
@D13_Dreinig

BlazeX

Alter Hase

  • »BlazeX« ist der Autor dieses Themas

Beiträge: 478

Wohnort: DD

Beruf: Maschinenbau-Student

  • Private Nachricht senden

3

29.10.2008, 17:47

Re: 2 Probleme: Fenster und Direct3D, DLLs "vieleicht&a

Erstmal danke für die Antwort!

Zitat von »"David_pb"«

Allerdings ist der Renderer kein Spezielles Fenster (Abgeleitet). Der Renderer weiß nur in welches Fenster gerendert werden soll.


Weniger als Fenster, mehr als Fenster-Manager.
Die Aufgaben wären theoretisch:
- Reaktion auf Windows-Messages wie WM_EXITSIZEMOVE, WM_MOVE, etc. durch virtuelle Funktionen wie OnMinimize, OnHide, OnNewSize, aso sein.
- Bei Bedarf ein Otto-Normal-Fenster erstellen, wenn der User kein Eigenes hat.

Die Ableitung ist auch nur interessant, wegen den 2 Renderern (D3D9 und D3D10). Die sollten ja halbwegs gleich zu handhaben sein.

-> Oder wie sollte ich die Fenstergeschichte sonst am geschicktesten verpacken. Der Renderer ist ja eigentlich doch nur fürs "Rendern" da. Und nicht unbedingt für das Output-Fenster.

Zitat von »"David_pb"«

Dann fehlt vermutlich die Dll im entsprechenden Suchordner...


Nuja, wenn der Games aber kein DirectX 10 installiert hat, sondern nur 9.0c, dann sollten die DX10-DLLs natürlich nicht vorhanden sein.
Oder etwa doch? Werden die durch DSetup auch installiert obwohl der PC das nicht schafft?

David_pb

Community-Fossil

Beiträge: 3 886

Beruf: 3D Graphics Programmer

  • Private Nachricht senden

4

29.10.2008, 18:49

Re: 2 Probleme: Fenster und Direct3D, DLLs "vieleicht&a

Zitat von »"BlazeX"«


Weniger als Fenster, mehr als Fenster-Manager.
Die Aufgaben wären theoretisch:
- Reaktion auf Windows-Messages wie WM_EXITSIZEMOVE, WM_MOVE, etc. durch virtuelle Funktionen wie OnMinimize, OnHide, OnNewSize, aso sein.
- Bei Bedarf ein Otto-Normal-Fenster erstellen, wenn der User kein Eigenes hat.


Genau, also keine der Aufgaben die ein Renderer zu erledigen hat.

Zitat von »"BlazeX"«


Die Ableitung ist auch nur interessant, wegen den 2 Renderern (D3D9 und D3D10). Die sollten ja halbwegs gleich zu handhaben sein.


Versteh nicht warum. Der Rendercode kann doch so ziemlich komplett von deinem Fenstermanager abgekoppelt sein. Das einzige was du benötigst ist der Renderkontext.

Ich habs, im Groben, so:

C-/C++-Quelltext

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
class WindowApplication : public Application, public IRenderTarget
{
   // Methoden etcpp ...


   //! Event Handling 

   virtual void OnActivate() = 0;
   virtual void OnClosing( bool& doClose ) = 0;
   virtual void OnClosed() = 0;
   virtual void OnDeactivate() = 0;
   virtual void OnIdle() = 0;
   virtual void OnMaximized() = 0;
   virtual void OnMinimized() = 0;
   virtual void OnMouseDown( const MouseEventArgs_t& args ) = 0;
   virtual void OnMouseUp( const MouseEventArgs_t& args ) = 0;
   virtual void OnMouseMove( const MouseEventArgs_t& args ) = 0;
   virtual void OnKeyDown( const KeyEventArgs_t& args ) = 0;
   virtual void OnKeyUp( const KeyEventArgs_t& args ) = 0;
   virtual void OnSize( uint32 width, uint32 height ) = 0;

   // ...

};


C-/C++-Quelltext

1
2
3
4
5
6
7
class WglRenderDevice : public OpenGLRenderDevice
{
public:
    WglRenderDevice( HWND hWnd, rsDepthFormat depth, rsStencilFormat stencil, rsMultisamplingType multisamples, uint32 width, uint32 height );

    // weitere funktionalität ...

};


Application hat einen Zeiger auf das Renderdevice und übergibt diesem die entsprechenden Informationen beim Initialisieren.

Zitat von »"BlazeX"«


Nuja, wenn der Games aber kein DirectX 10 installiert hat, sondern nur 9.0c, dann sollten die DX10-DLLs natürlich nicht vorhanden sein.
Oder etwa doch? Werden die durch DSetup auch installiert obwohl der PC das nicht schafft?


Ach das meinst du. Ja, das könnt evtl problematisch werden! :)
@D13_Dreinig

Werbeanzeige