I''m using the state model as well and I pretty much treat each state as if it were its own little program. Each state has its own OnRender, OnKeyDown, OnUpdate, OnMouseDownL, etc.. methods.

As far as which state to pass events for input you prolly wanna pass the event to all the states on the stack. Of course it really depends on the behavior youre trying to achieve.

In my project, I dont use a stack as the game can only be in one state at a time. I''m either at the login screen, the server select screen, the character selection screen, or im playing the game.

There''s a few other states like if the player is zoning from one area to another or loading the game but thats the basic setup.

The only real problem with the whole state pattern method, at least the way i''ve implemented it is that its really hard to have persistent objects from one state to the next if those objects are created within the state. Whenever a state change happens i call a DeInitialize method that destorys everything the state created and whenever the state is reentered the objects are recreated. Not a big deal since theres not that many objects for each state save maybe the playgame state but thats usually gonna be reloaded every time anyway.


-=[ Megahertz ]=-

Yes, each state should have its own version of handleInput, onRender, etc.... whatever... -- this should be done thru polymorphism, i.e. write an abstract base class that specifies the methods that all states should implement and inherit from it for each state. Then all you need is a base class pointer that you can use to point to whatever the active state is and call each of those methods in your game loop with it.

peace and (trance) out

Mage

A) I''m using a stack for my states. 99% of the times i''m having only one state on the stack. The 1% is having a in-game submenu state on top of the game state.

Every state has it''s on Init,Exit,Display and Update functions.

In the beginning i had my state machine change states as soon as i requested it to. On rare occasions i would run into troubles since the old state was still finishing but already gone. Then i decided to push the stack change onto a message queue and process that queue only after all the frames are updated. It''s simply safer that way. The same with the game shutdown.

As Megahertz said, kind of a problem arises with persistent objects. Since those are usually important game data objects i tend to have a game data singleton which more or less just stores the persistent stuff plus some widely used routines which work on the game data.

B) I''m using the WinProc for handling the messages WM_ACTIVATE plus some others (sizing,moving,prevent the screensaver from popping up).

I''d favor the second approach, the shutdown is not really a kind of state. Once i told my app to shutdown i set a flag and the next time my state manager hits its processing method it''ll pop states off the stack and then initiate the real shutdown.