Win32 Lockup in simple DirectDraw App
Author
I have built a simple Direct Draw application and I am trying to get it to perform some basic animation on 16-bit bitmaps. The DirectX specific code works fine, but I am having a problem when I get into the main loop in my win32 layer of the application
Based on what I have observed using a debugging tool, the main loop executes three times and then completely skips over the message processing section. The program itself works, but it minimizes itself after the third iteration.
Basically, PeekMessage() is returning false after three iterations, I am confounded madly and would greatly appreciate assistance.
Code snipit for reference:
while(true)
{
//This statement evaluates to false after 3 iterations
// ?!?Confusing!
if (PeekMessage(&msg,NULL,0,0,PM_REMOVE))
{
// test if this is a quit
if (msg.message == WM_QUIT)
break;
// translate any accelerator keys
TranslateMessage(&msg);
// send message
DispatchMessage(&msg);
} // end if
if KEY_DOWN(VK_ESCAPE)
{
PostQuitMessage(WM_QUIT);
}
Game(); //Never gets processed due to PeekMessage
//not continuing after 3 iterations.
} // end while
it is correct that PeekMessage returns false. this means just that there are no more messages in the queue waiting.
what is KEY_DOWN for a macro? i would never test for key presses in the main loop as DispatchMessage translates them passing it over to your WindowProc function.
EDIT: what 'exactly' does not work? is Game() called during those 3 times the loop runs?
what is KEY_DOWN for a macro? i would never test for key presses in the main loop as DispatchMessage translates them passing it over to your WindowProc function.
EDIT: what 'exactly' does not work? is Game() called during those 3 times the loop runs?
Author
This is just a test container for the application which is a smaller part of a greater whole. I didn't want to mess with Direct Input for now, so I read the keyboard asynchronously for a quick setup. Anyway, do you have any clue as to why there is no message. Could it be that the message to draw the window isn't being posted for some reason? Further more, is there a better way to set up the main loop in the client window?
the main loop in fact is usually only this piece of code, thus like yours:
important here is just that doFrame is called once all messages are done. you can use doFrame all the time but usually it's better to get all messages at once. otherwise you would read one keypress, draw, read another keypress, draw, ... it's not that well.
now what exactly you mean with 'message to draw the window'? i assume you work in a double buffered fullscreen mode right?
while(true){ if( PeekMessage(&msg,NULL,0,0,PM_REMOVE) ){ if(msg.message == WM_QUIT) break; TranslateMessage(&msg); DispatchMessage(&msg); }else{ doFrame(); }}important here is just that doFrame is called once all messages are done. you can use doFrame all the time but usually it's better to get all messages at once. otherwise you would read one keypress, draw, read another keypress, draw, ... it's not that well.
now what exactly you mean with 'message to draw the window'? i assume you work in a double buffered fullscreen mode right?
Author
Perhaps that is the problem then. So the main game processing method is called in an else portion to ensure its execution. Thanks.
Author
Oh yeah, I do work in a double buffered full screen mode. I'm a nube, so I wasn't sure if a deliberate posting of some sort of Win32 "Draw" message had to be posted or not. I.E. in the callback function which processes the messages. But I think that adding the else section to the main loop will do the trick. Thank you very much for your help.
there are two ways to do a game: event driven, polling driven (those are my names for the children).
event driven is what you talked about. you make a window, you wait for a keypress to arrive, you then do something with it and then request for a redraw of the window. this only draws the window when you need it and only processes input if arriving.
polling is what most games are in. you execute a doFrame() function over and over again which checks for keys pressed, draws the next frame into the backbuffer and then flips it to the frontbuffer (hence double buffer).
the version i gave you is a mix as you do call doFrame() over and over again updating your screen but you don't poll for keypresses (unless you use DirectInput, then you do pull them in doFrame). and should a message arrive you process them all first and then go on polling. i hope i didn't confuse ya now ^_^
event driven is what you talked about. you make a window, you wait for a keypress to arrive, you then do something with it and then request for a redraw of the window. this only draws the window when you need it and only processes input if arriving.
polling is what most games are in. you execute a doFrame() function over and over again which checks for keys pressed, draws the next frame into the backbuffer and then flips it to the frontbuffer (hence double buffer).
the version i gave you is a mix as you do call doFrame() over and over again updating your screen but you don't poll for keypresses (unless you use DirectInput, then you do pull them in doFrame). and should a message arrive you process them all first and then go on polling. i hope i didn't confuse ya now ^_^
Author
No confusion here :) I have heard of the methods being referred to as event driven and realtime. Same thing I guess. The app that I made checks for the keypress in the game() function, so it is realtime. I know that reading the keyboard asynchronously is damned slow, and I would never use this heretical abomination in a final implementation!P Thanks for looking out for me though, and again, thank you for all of your help.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
