What's your WinMain look like?
Author
I'm just starting out in game programming, and I'm thinking about how I want to architect my game. I would like the majority of the generic game stuff to be reusable. I am not concerned right now with OS or graphics API independence, but I may be in the future.
I was thinking about how the WinMain routine would call the game routines, and thought maybe you all would have some suggestions. My idea is similar to this (pseudocode):
WinMain()
{
Game g = new Game;
g.InitalizeGraphics();
g.CreateWindow();
TerrainManager t = new TerrainManager;
t.LoadLevel(0);
ModelManager m = new ModelManager;
UnitManager u = new UnitManager(m);
u.LoadUnits(0);
...
while(!done)
{
ProcessWindowsMessages();
UpdateGameData();
RenderScene();
}
DestroyAll();
}
What do you think? What kind of generic layout do you guys use?
Quote:Original post by Dave Hunt
I agree. The responsiblity of WinMain is to be an entry point for the linker. It should delegate all other responsibilities to other functions.
Quote:Original post by Dave HuntWinMain(){ Game *g = new Game(); g->Run(); delete g;}
Mines the same,
Here's the main from my current project (SDL)
int main( int argc, char** argv ){ try { Ultra1::App app; app.Run( ); } catch( Sim::Exception exc ) { exc.WriteError( ); } catch( ... ) { Sim::Exception exc( "Unknown", "A built in exception occured" ); exc.WriteError( ); } return 0;}Quote:Original post by ToohrVykQuote:Original post by Dave Hunt
I agree. The responsiblity of WinMain is to be an entry point for the linker. It should delegate all other responsibilities to other functions.
Why?
Quote:Original post by simon10kQuote:Original post by ToohrVykQuote:Original post by Dave Hunt
I agree. The responsiblity of WinMain is to be an entry point for the linker. It should delegate all other responsibilities to other functions.
Why?
1. WinMain is merely an entry point for an application.
2. More importantly, no function should do more than one thing.
Quote:Original post by Dave
1. WinMain is merely an entry point for an application.
2. More importantly, no function should do more than one thing.
Could you refer me to some documentation that states this?
Quote:Original post by simon10k
Could you refer me to some documentation that states this?
Common sense. Separation of responsibilities increases modularity, and modularity decreases the amount of work necessary when you have to change something. And decreasing the amount of work necessary to achieve something is inherently a Good ThingTM.
Typically, when a function F does A and B, you are bound to end up with a situation where you need a function G that does A but not B (solved by responsibility separation).
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
