Jump to content
  • Advertisement
Sign in to follow this  
QQemka

D3d / game window dependency

This topic is 840 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Hello, got small design problem question:

Should d3d class be member of window class, or vice versa?

Intuition says that window is just a part of the d3d "Stuff", so it should be its member, but on the other hand, shouldnt window also inform the d3d about some incoming window messages like screen resize, so d3d should be member of window?

Greetz

Share this post


Link to post
Share on other sites
Advertisement

I did a Windows class and a DX Game class that my Game class inherits from. The code is on my website.

 

But now I'm porting it all over to OpenGL and I'm looking at things differently.

 

Still, windows are completely separate from DX or OGL. But you may not want to use Windows in Windows. I'm using GLFW now. GLFW is pretty clearly not Windows or DX. Now I'm doing a OS (operating system) class. And if I had to do it over again, I would probably obfuscate Windows even further away so that the interface would be the same in Windows, Linux, or anywhere else.

Share this post


Link to post
Share on other sites

And if window receives a message in wndproc, are you passing it back to the game class, or 100% of window messages are handled inside window class?

Share this post


Link to post
Share on other sites

No not really, both are part of a bigger picture:

 

I have a GameClass handling the MainLoop of the Game and a bunch of Subsystems: WindowHandling, Input, Rendering(D3D Class is in fact part of the RenderingSystem), Physics aso.

 

All Human input like Keyboard or Mouse is handled by the Input Subsystem, The Window Itself handles only the very basic messages from the DefaultWindowProc

 

The GameClass gets the result from the InputSystem ins is responsible for triggering all the required actions in the other subsystems.

Share this post


Link to post
Share on other sites

Messages like WM_LBUTTONDOWN land inside the winmain procedure, but for example WM_SIZE (when user maximizes window) goes directly to window and not to the main proc of the game class. Thats what im worrying about. Some messages (just like the resize) has to be passed back to the game class which would inform d3d about resolution change. And thats what i was worrying about, that there are messages important for the game but which the windows is directly receiving

So in the end, should d3d be member of window, or window member of d3d, or they both members of some main class and just pass the windows messages back to it?

Edited by QQemka

Share this post


Link to post
Share on other sites

What is the best way depends on your overall architecture and how you are going to handle different things...

 

Minimizing for example is passed from the window back to the gameclass and causes pausing of the whole game loop.

Resizing is only allowed using the game engine, same is valid for destruction

 

I should be also possible to call the message handler from another class from your window and handle in each class only the relavant message for that class...

Edited by mgubisch

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!