Sign in to follow this  

Win32 Lockup in simple DirectDraw App

This topic is 4781 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

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

Share this post


Link to post
Share on other sites
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?

Share this post


Link to post
Share on other sites
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?

Share this post


Link to post
Share on other sites
the main loop in fact is usually only this piece of code, thus like yours:
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?

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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 ^_^

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites

This topic is 4781 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this