Dark Bit Factory & Gravity
GENERAL => Projects => Topic started by: Shockwave on February 06, 2011
-
I don't know whether I have set this framework up wrongly..
On my own computer there are no problems at all, it runs very smooth.
I tried it on a friends computer though and whenever I moved the mouse the whole thing judders horribly.
When the mouse is left in one place it's totally smooth..
As it doesn't happen on my computer it's a bit of a tricky one to fix.
Can anyone see anything wrong with the code? It uses RBZ's fixed framework.
-
I am on GNU/Linux so I didn't test the program.
But I am supposing that it is because of the message loop, stopping a bit the program.
The problem is certainly that for each pixel, the message loop receives one message. So if you are moving, let's say, 1000 pixels, you have 1000 messages to process (Wow ... a lot).
-
LittleWhite: In windows you dont get a message per pixel moved unless that framework works differently.
But I do wonder about the message loop also
if (PeekMessage (@wMsg,NULL,0,0,PM_REMOVE) <> 0) then
DispatchMessage(@wMsg)
else
OLD=TIMER
glDraw()
SwapBuffers (hdcWin)
DV=TIMER-OLD
end if
Since DV looks like it should be "deltatime" but as written it shouldn't be that. Since it doesn't include the time used by any message processing. Moving the DV calculation above the OLD=TIMER might work better. Could be worth a try.
BTW. The program works without problem here
-
Hmm, ok it could well be deltatime, it won't harm to move the command around :)
Cheers guys!
-
Hi Shock, try this and see if it minimize this problem:
while(wMsg.message <> WM_QUIT)
if (PeekMessage (@wMsg,NULL,0,0,PM_REMOVE) <> 0) then
DispatchMessage(@wMsg)
DV=TIMER-OLD 'fixed: update timer when window process a message
else
OLD=TIMER
glDraw()
SwapBuffers (hdcWin)
DV=TIMER-OLD
end if
wend
-
Thanks RBZ :)
I'll try this when I next have access to my friends computer. In the meantime K+ for all of you.
Thanks for helping an old man :)
-
My guese was that you failed to return a value of zero in response to WM_MOUSEMOVE messages, but after looking through the disassembly I see that you forward all messages to DefWindowProc, my basic is getting rusty.
-
In typical fashion of me Rain Storm it's been so long since I wrote anything resembling a demo that I have no fucking clue about what handles the windows messages.. It's RBZ's framework anyway :)
I'll be happy if the fix has stopped the glitch and then perhaps I can move on to doing something else ..