• Advertisement

Archived

This topic is now archived and is closed to further replies.

Engine Framework

This topic is 5060 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

I am attempting to build a version of a basic engine. I am following the new LaMothe book and using direct draw 7. Unfortunately his code is all in C and he does not use classes etc. Hence I am trying to work his methods into my own framework. So far I have a simple windows app based on the SDK framework. I have a base class called Framework which holds the hWnd etc. I also have a derived class which is for the actual application, WinMain() is also in here. What I am trying to do is keep as much of tbe graphics code seperate as possible. So I think I have two options to choose from:- 1. Make a third file named Gamelib or something which will contain the DDraw code and a function for initialising DDraw. Then have this class inherit from the base class because DDraw initialisation requires some of the window initialisation code specifically the hWnd. 2. Intergrate the DDraw initialisation code into the base class with the windows code. Then create a seperate derived class from this for all the various engine functions I will develop. I have searched, read and looked at various engine design articles and code but still have this doubt about the best way of going about this project. Any help, advise would be appreciated.

Share this post


Link to post
Share on other sites
Advertisement
Why not keep your DDraw rendering in a DLL and have the Framework class call a static method in the DLL that creates the window for it with specific settings, etc...

That way, if you later want to switch to OGL rendering, you just create another DLL. If that method exists in the Init class in the DLL it could look like this:


Framework::CreateWindow()
{
// code here...


// Call internal method

Init::CreateWindow(hwnd, other variables needed here);

// continue win32 code here...

}


That way you get a implementation-independent window creation. Thus if you want a WinGDI rendering system, you just provide the WinGDI dll and have that implement the Init::CreateWindow in its own way.

Do you understand what I mean?

Share this post


Link to post
Share on other sites
I sort of understand I think I read something along thse lines on my travels, something about independant API. In terms of a graphics engine I suppose it is a fantastic thing to have.

With the LaMothe code he has a function which takes a width, height, windowed/screen and an hWnd handle as arguments. Then the function creates a DDraw initialised window. Ideally I would want such a function in a seperate class in a seperate file. However with the hWnd member being in the base class unless I have the graphics class inherit from the base class like the application class does then there is no other way of passing that hWnd handle variable to the CreateWindow() function in the Graphics class.

I am not up on DLL''s at all in all honestly and I am concerned perhaps it is a bit overkill for my issue. Or is this the most common way engines are built these days?

I am personally thinking I might create a new Graphics .cpp and .h file with a new class. Then have this class inherit from the base class. This way I can keep the graphics functions such as the DDraw initialisation seperate from the main application file and all the windows stuff. But I can still have access to that darn hWnd member needed by the CreateWindow() function to create a DDraw initialised window.

Does this seem a good solution?

Share this post


Link to post
Share on other sites
You could have the Graphics class take an HWND as an initialization parameter, and so avoid having to inherit from the base game class. Anyway, read up a bit about OOP and why it''s bad to have everything inherit from a god class, and just to inherit an HWND, no less.

And no, of course you don''t have to go with DLLs this early. You can ease into them later, when you understand a bit more.

Share this post


Link to post
Share on other sites

  • Advertisement