   Questions about the game/message loop.
  Hi,I'm playing around trying to get a little nicer message loop, but there's a couple of things I'm not understanding.1) When we call Dispatch Message how can we ensure all messages are processed for whatever is listening for them as dispatchMessage only sends one message. I.e:... WndProc...{    callInputHandler(/*WndProcArgsHere*/);    callSystemHandler(/*WndProcArgsHere*/);}For the input handler, we'd want all WM_KEYUP/DOWN and WM_CHAR messages processed and removing from the queue, but how do we do this without removing any messages that the system handler might be interested in? All I can think is that we have two while loops:while(gameShouldRun){while(PeekMessage(&msg,NULL,0,0,PM_REMOVE)){DispatchMessage(&msg);}}Would something like this be appropriate?2) We can solve the jerky animation by using interpolation which is fine, but if we ensure the game logic is updated X times per second by ensuring the time between updates is not more than X/1000, that still doesn't actually ensure that the game logic receives the correct number of updates if a number of frames take an extraordinarily long time to render. We are still assuming that a frame won't take more than y milliseconds to update the game world and render. How do we handle this?Thanks,NB   
Quote:Original post by NewBreedFor the input handler, we'd want all WM_KEYUP/DOWN and WM_CHAR messages processed and removing from the queue, but how do we do this without removing any messages that the system handler might be interested in?Don't use the window message queue as a central window-message clearinghouse. It's far too crappy for that. Read all the messages, dispatch them as necessary.Quote:2) We can solve the jerky animation by using interpolation which is fine, but if we ensure the game logic is updated X times per second by ensuring the time between updates is not more than X/1000, that still doesn't actually ensure that the game logic receives the correct number of updates if a number of frames take an extraordinarily long time to render. We are still assuming that a frame won't take more than y milliseconds to update the game world and render. How do we handle this?Extra logic update steps, under those extraordinary circumstances.   ;  Hi Sneftel,Quote:Original post by SneftelDon't use the window message queue as a central window-message clearinghouse. It's far too crappy for that. Read all the messages, dispatch them as necessary.How do I read all the messages in one go, would the code I suggested be of any use?Quote:Original post by SneftelExtra logic update steps, under those extraordinary circumstances.Sorry, I don't understand?Thanks.   ;Quote:Original post by NewBreedHow do I read all the messages in one go, would the code I suggested be of any use?Your code seems to show both callInputHandler and callSystemHandler being called. Wouldn't you want to only call the one that would actually be interested in the message?Quote:Quote:Extra logic update steps, under those extraordinary circumstances.Sorry, I don't understand?It's pretty simple. Last frame took three seconds to draw, and we want to update logic once per second, so now we call the logic update three times, advancing the logic clock by one second each time.   ;Quote:Original post by SneftelYour code seems to show both callInputHandler and callSystemHandler being called. Wouldn't you want to only call the one that would actually be interested in the message?Ah okay - I see what you mean now. Perhaps I made a bit of a bad example there, as the functions inside then check if the message is interesting for them. Although to get all the messages in one 'frame' so to speak, could the 'while(gameShouldRun)' code section be used, or are there better ways?Quote:It's pretty simple. Last frame took three seconds to draw, and we want to update logic once per second, so now we call the logic update three times, advancing the logic clock by one second each time.That's cleared that up. Thank you. :)When we are polling the input, I'm guessing it should be polled every frame as opposed to every game logic tick, so to prevent the DefWindowProc removing it for when we next want to sample it? But won't this mean we need some queue system to keep a log of the messages that have been captured in between game logic ticks?Thanks again,NB.   ;Quote:Original post by NewBreedAh okay - I see what you mean now. Perhaps I made a bit of a bad example there, as the functions inside then check if the message is interesting for them. Although to get all the messages in one 'frame' so to speak, could the 'while(gameShouldRun)' code section be used, or are there better ways?*shrug* nothing important.Quote:When we are polling the input, I'm guessing it should be polled every frame as opposed to every game logic tick, so to prevent the DefWindowProc removing it for when we next want to sample it?DefWindowProc is a function that you give a message to. It doesn't remove any messages. Messages will stick around until removed from the queue with GetMessage or PeekMessage(REMOVE). If there are circumstances under which you want to handle certain types of messages immediately but leave others for later, you'll need to implement an event queue of some sort to remember them.   ;  Ok, cheers for all the help Sneftel. Much appreciated. :)NewBreed.   