Archived

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

parklife

message pump & the game loop

Recommended Posts

parklife    132
I''ve been reading the article "Getting rid of the message pump". The article recommends creating a seperate thread that you run the actual game in whilst the main program only takes care of the message loop. In this way you can program in a more DOS kind of way, and the pro''s are obvious, you can drop all those state-checking variables. If you are interested, go read the article. Now, I''m wondering if anyone has made a complete game using state checking in every function and I''m also curious on what other approaches there are to this problem. thanks in advance, john

Share this post


Link to post
Share on other sites
Omaha    100
In much contradiction to my stance on the overuse of classes, in my latest project (and seeing how well its working out, in my future ones as well) I'm using a CGameState class with five function pointers, Enter, Exit, Update, Draw, and ProcessInput.

I have one global CGameState pointer in the main game source file that has Update, Draw and Input functions that are called once per frame. After doing what it has to do (i.e. the Input function polls the DirectInput devices that are active) it passes control to GameState->Whatever (CurrentGameState->ProcessInput() or GameState->DrawFrame() or whatever.)

This way, I can avoid having to write tons of state-checking code in my rendering/input/update processes. It also makes it very easy to add future states, and to keep track of the current state.

Then, I just create a source file for each game state to keep them clean, and write functions that will be pointed to by the respective pointers and create a CGameState object (whose constructor sets all the pointers at once) extern it where its needed in the program (For example, when one state switches to another) and call SetGameState. The program takes care of the rest.

Also, a global function SetGameState automatically calls the Exit function of the current state and the Enter method of the next, which contain required clean exit (releasing dynamic memory allocated during that state, flushing textures and all) and entrance (allocating dynamic memory needed for a state, initializing resources) code for the state.

[edited by - Omaha on June 8, 2002 8:06:47 PM]

Share this post


Link to post
Share on other sites
Beer Hunter    712
I''m using a fairly simple solution.

handle_messages() empties the message queue, deals with the game being minimised, and throws an exception in response to WM_QUIT.

Share this post


Link to post
Share on other sites
Guest Anonymous Poster   
Guest Anonymous Poster
quote:
Original post by parklife
I''ve been reading the article <a href="http://www.gamedev.net/reference/articles/article1249.asp">"Getting rid of the message pump"</a>. The article recommends creating a seperate thread that you run the actual game in whilst the main program only takes care of the message loop. In this way you can program in a more DOS kind of way, and the pro''s are obvious, you can drop all those state-checking variables. If you are interested, go read the article.

Now, I''m wondering if anyone has made a complete game using state checking in every function and I''m also curious on what other approaches there are to this problem.

thanks in advance,
john


And what is this DOS of which you speak?
For those unable to understand sarcasm, it might be useful to someone used to programming games for dos, but they have no doubt adapated by now and all the new ones are used to it by now. For instance, what advantages? Take avoiding state-checking variables, it makes the program similar to a finite state machine which is very common anyway. More importantly, how do I avoid these state variables, it will vary wildly between games but the computer still needs some way to tell what is supposed to be rendered.

Share this post


Link to post
Share on other sites