Win32 program structure
I was just curious about how those of you who program Win32 apps set up your program structure. Since the windows messages seem to force a huge switch statement in the callback procedure, how to you manage it? I have my own ideas, but I''m curious as to how others keep their code from being one massive switch statement.
-Kirk
There aren''t really all that messages you need to handle, so the idea of there being a "huge" switch statement is kind of off base. You don''t need to handle every message. For most apps, you probably won''t need to handle more than a half-dozen.
True, but do you handle them within the switch statement or do you pass them off to other functions? For example, do you have an application object (or "game engine" object) on which you call functions in response to the messages?
-Kirk
[edited by - KirkD on May 30, 2004 11:34:26 AM]
-Kirk
[edited by - KirkD on May 30, 2004 11:34:26 AM]
When making games limit the use of the winproc to catch if the app is losing focus etc.
The game code should not use the windows programming model.
You will want to hide it somewhere and make a call to HandlePlatformDependatStuff() once every iteration of the game loop or something, on windows that function would handle the message pump.
Ofcourse, if you are just beginning, there is nothing wrong with using the winproc and the windowsmodel to make your games.
The game code should not use the windows programming model.
You will want to hide it somewhere and make a call to HandlePlatformDependatStuff() once every iteration of the game loop or something, on windows that function would handle the message pump.
Ofcourse, if you are just beginning, there is nothing wrong with using the winproc and the windowsmodel to make your games.
Peter,
Thanks for the note. As I mentioned in my last post, I was thinking to make a game object with an interface which would get called by the WinProc when the interesting messages came through.
Your post gives me another idea: make the same game object but rather than WinProc forcing things to be handled, it will adjust various settings within the object. Then, once per game loop, the game object will make the necessary adjustments based on those settings.
The old way would have the game object adjusting itself everytime a windows messages came through. The new idea would set a variety of properties and only make the adjustments once per loop. Does that make sense?
-Kirk
Thanks for the note. As I mentioned in my last post, I was thinking to make a game object with an interface which would get called by the WinProc when the interesting messages came through.
Your post gives me another idea: make the same game object but rather than WinProc forcing things to be handled, it will adjust various settings within the object. Then, once per game loop, the game object will make the necessary adjustments based on those settings.
The old way would have the game object adjusting itself everytime a windows messages came through. The new idea would set a variety of properties and only make the adjustments once per loop. Does that make sense?
-Kirk
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement