Archived

This topic is now archived and is closed to further replies.

MtSMox

Frame rate too high???

Recommended Posts

Hi you all, yes it''s another fps message, but this one is (I think) different. I know I can let the fps go and still get good timing, but my problem now is, that the fps is too high. I had two programs that are almost the same. They both used DirectDraw 7 and where just a little gaphics sample. One also used GetDC the other didn''t. I used the PeekMessage() to see if there are any messages for the window and if not did the game stuff (including drawing). So both programs did this, but the weird thing is that one sort of locked the system. Everything got slow (except the fps of the game: about 1500 or so). So I thought it should be doing fine... the messageloop is run 1500 times a second so it should process the messages fine. But it wasn''t. I later found out that if I lowered fps, it worked fine (I think the other prog was already slowed down by the GetDC, etc.). But I don''t want to lower fps, I want it as high as it can get. I hope you understand the problem and can help me, thanks in advance... Mox

Share this post


Link to post
Share on other sites
Hmm. I get a similar problem. The message loop is running, but it doesn''t seem to notice when I press a key - I have to hold it down. I''ve no idea what causes it.

''Nuff said. I''ll enjoy watching you live, demon.

Share this post


Link to post
Share on other sites
Make that 3 of us, i hold down any keys and nothing happens. Eventually i have enough of it and press ESCAPE several times until suddenly all my other keystokes are processed in super-fast time before the exit command is processed and the whole thing shuts down.

Definately something to do with the message processing loop, i just don''t know what it is yet.

zipless

Share this post


Link to post
Share on other sites
Make sure the message que is being checked and handled every frame. There should be something like a

if(PeekMessage)
TranslateMessage
else
RenderLoop

When you exit PostQuitMessage(0) is put at the end of the que and the previous messages are handled before the exit command is hit.

Ben



[Icarus Independent | Jump Down The Rabbithole | Tombstone: Vendetta ]

Share this post


Link to post
Share on other sites
This is my message loop:
  
while (true)
{
if (PeekMessage(&msg, NULL, 0, 0, PM_NOREMOVE))
{
if (GetMessage(&msg, NULL, 0, 0))
{
TranslateMessage(&msg);
DispatchMessage(&msg);
}
else
break;
}
else
DoGame();
}


It seems correct, but the weird thing is it works fine if I do nothing in DoGame. But if I use DirectDraw to erase the backbuffer and flip it (or blt it to the screen), it slows down. And if I put a GetDC call in it, the fps drop and the program (and other windows) respond correctly.
What is going on here? Why wouldn''t this messageloop work if it is traversed really fast?

Mox

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
I''ve had that problem before, you could do a wait for vertical retrace to fix it

Share this post


Link to post
Share on other sites
Yeah, you need to make it while(PeekMessage(...))
Handle all the messages, then render another frame.

I calculate the framerate, and if/when it exceeds 200fps, I call Sleep(1). This gives other running processes and threads a chance to do something.

Share this post


Link to post
Share on other sites
I''ll try to use the while (PeekMessage()).
But shouldn''t windows or whatever, because it''s multithreaded, devide the processor time to all the threads. So why should it matter how intens your program is?

Share this post


Link to post
Share on other sites
I know my program isn''t multi-threaded (I''m thinking of making it though).
My program processes the messages each frame, so that shouldn''t be a problem. But because the framerate is so high, a lot of calculations are done by my program, and I think that''s why the other programs are given less time of the CPU.
I don''t really understand everything to multi-threaded apps and how CPU time is divided, but I think the problem lies there.
Could I/Should I make a different thread for keyboard and mouse input with a higher priority, so it''s fluid and make another thread for drawing with a lower priority (so it can be stopped if it''s time on the CPU is over)?
Or is there another solution for this?

Mox

Share this post


Link to post
Share on other sites
what messages are you processing?
if you are processing Mouse and keyboard messages, you sould be using direct input, and/or instead of wait for messages to be posted, poll the mouse and keyboard states every frame (inside your game loop), you do this with GetCursorPos for The Mouse, and GetKeyboardState for the keyboard with WinApi, then you look up to see if the cursor is where you want it or if the key you are waitting for is pressed, and presto!.

Share this post


Link to post
Share on other sites
I wouldn''t call it overkill.
Having one thread for the message pump and one for the game loop has advantages (cancel buttons that _work, for instance).

A thread dedicated to input seems like overkill. The input thread would need to be high priority, and it would need to keep a queue of the keypresses and when they were pressed. You could get accurate keyboard information even if the framerate plummeted. Seems like alot of work for not alot of gain.

Magmai Kai Holmlor
- Not For Rent

Share this post


Link to post
Share on other sites
I use DirectInput for the mouse input and don''t yet use the keyboard. I changed my messageloop to the following:

  
while (true)
{
while (PeekMessage(&msg, NULL, 0, 0, PM_NOREMOVE))
{
if (GetMessage(&msg, NULL, 0, 0))
{
TranslateMessage(&msg);
DispatchMessage(&msg);
}
else
return msg.wParam;
}

if (isActive)
{
ret = GUILoop();
if (ret)
return error(ret);
}
else
WaitMessage();
}


but the problem''s still there. If I remove the if isActive...WaitMessage(); part it works fine. At least, it reacts fast to messages, like ALT-TAB and ALT-F4. So the problem should lie in the draw routines like i said earlier, but if I slow them down, it works fine.
Could I solve this by making another thread that processes the messages (or for that matter, make another thread that does the gameloop)? Should the gameloop then have a lower priority?

Mox

Share this post


Link to post
Share on other sites
    
while (true)
{
while (PeekMessage(&msg, NULL, 0, 0, PM_NOREMOVE))
{
if (GetMessage(&msg, NULL, 0, 0))
{
TranslateMessage(&msg);
DispatchMessage(&msg);
}
else
return msg.wParam;
}
ret = GUILoop();
if (ret)
return error(ret);


Have you tried that?

What does your GUILoop() do? The problem may be what you're doing inside of it.

Ben

Edited by - KalvinB on November 2, 2001 2:25:16 PM

Share this post


Link to post
Share on other sites
Why would anyone EVER need a program to make 120 000 fps?

the fastest monitors only have a vertical blank 200 times per second.

The only way to become a better person,
Is for a man to realize how great he already is.

~Vendayan

Edited by - Vendayan on November 2, 2001 2:32:50 PM

Share this post


Link to post
Share on other sites
Is everyone here using DirectInput?
If you aren''t then you can simply solve the problem by using direct input, and then checking what key has been released after being pressed.

Share this post


Link to post
Share on other sites
  
while (!done)
{
PeekMessage(&msg, hwnd, NULL, NULL, PM_REMOVE);

if (msg.message == WM_QUIT) // do we receive a WM_QUIT message?

{
done = true; // if so, time to quit the application

}
else
{

Render();

TranslateMessage(&msg); // translate and dispatch to event queue

DispatchMessage(&msg);
}
}


My message loop

Share this post


Link to post
Share on other sites
quote:
Original post by RelisH
Is everyone here using DirectInput?
If you aren''t then you can simply solve the problem by using direct input, and then checking what key has been released after being pressed.


I am using DirectInput, but the problem isn''t solved, because not only the input messages are slow, but all the messages.
I''ll try that other messageloop, but in that messageloop, message are always dispatched even if there are non (&msg == NULL?), isn''t that a problem.

KalvinB, is your server app also drawing or just calculating? If it is also drawing how does your message loop look like? If it''s just calculating, there should be no problem indeed, because mine does that fine, but if I use DirectDraw to draw, it slows down (or like I said, frame rate goes up, but respons goes down). Should I use other blitting methods, I use the standard blitting flags:
surface->BltFast(x, y, dds, &rSrc, DDBLTFAST_WAIT | DDBLTFAST_SRCCOLORKEY);
and frontsurface->Blt(......, DDBLT_WAIT) for flipping in windowed mode or,
frontsurface->Flip(NULL, DDFLIP_WAIT);

I''ll try using NONWAIT flags, but I thought I already tried that. Does anybody has any suggestions?

Mox

Share this post


Link to post
Share on other sites
Is this some kind of test?

What do I have that others haven''t? What did you find? I''ve lost track
But I''ll try to follow the messages if that''s what you mean, see if they''re all processed. Or isn''t that what you mean. Do you mean WaitMessage()? That just waits for a message if the app isn''t active (inactive is minimized or not in front).
Or is there something else?

Mox

Share this post


Link to post
Share on other sites
It''s a test.

You need to learn how to effectively debug (without a debugger program) a program using plain text log files so when more difficult problems come up you can narrow down the cause to just a line or two of code.

You know what it''s supposed to do. Log it to see what it actually does.

Ben

[Icarus Independent | Jump Down The Rabbithole | Tombstone: Vendetta ]

Share this post


Link to post
Share on other sites
Two characters never caused so much trouble...

Magmai Kai Holmlor
- Not For Rent

Man you'd think the program would just go nuts the first time you did anything...

Edited by - Magmai Kai Holmlor on November 3, 2001 12:49:37 AM

Share this post


Link to post
Share on other sites