Framerate cut in half while moving
It''s not just that the framerate lower while moving, which is to be expected to some degree, it''s that it''s cut in half and the cpu utilization drops from 100% to ~60%.
I''d like to post the code that show what''s going on in a render loop, but am afraid it''s just too much.
I''m using MFC but I use direct Input to poll the keyboard state. I was curious if there''s anyone else has ever done this, and if they ran into such a problem.
If I select a different window (other than my game window), and move around it works at full speed (well I lose .9fps instead of 35fps).
Well your last sentence was that when you select a different window it works fine. Maybe you have some windows messages that are going on when while the window is selected. MFC does a lot of wierd crap you don''t know about. Thats all i can help tho.
OOO I got it! Even tho u use DInput to poll the keyboard, Windows still sends your game the WM_KEYDOWN/WM_KEYUP messages since the game window is selected, and the game slows since it has to process the messages. When the game window isn''t selected, it runs fine because now all the WM_KEYDOWN/WM_KEYUP messages are going to a different window, and your game window doesn''t have to process it! And since you are using MFC, which does a whole crapload of things to windows messages (mapping functions to them, etc), it runs ESPECIALLY SLOW. Thats just my best guess. Who knows what else it could be.
I''m not exactly sure, but I''m pretty sure there''s a flag somewhere in DInput that makes it so Windows doesn''t send key messages to the window.. Maybe a cooperation level flag, I don''t remember exactly.
Don''t ask us, ask your code.
You ought to just implement a simple code profiler and time how long each part of your program takes....if your frame rate drops in half (and the cpu usage drops by 40%), it is probaly sitting in one bit of the program for friqing ages and should be very easy to find.
dan
Game production:
Good, quick, cheap: Choose two.
You ought to just implement a simple code profiler and time how long each part of your program takes....if your frame rate drops in half (and the cpu usage drops by 40%), it is probaly sitting in one bit of the program for friqing ages and should be very easy to find.
dan
Game production:
Good, quick, cheap: Choose two.
I overrode the OnChar OnKeyDown etc.. funcions and made them do nothing - is there a method that gets called for OnCharRepeat? 'Cause OnKeyDown only gets called once, as does OnKeyUp, and OnChar...
touche, I'll go time all the parts of the render loop.
Well actually, it shouldn't matter if MFC calls a Sleep(1000), I have the rendering in a seperate thread...
Every Project in Life:
Works, quick, cheap: Choose one.
...
Well it's this code right here, specifically the stFrame->SetWindowText. The code usually take 230us to execute, every now & then it takes 11500us to execute, and it takes that long more frequently when I hold down any key...
Happens on all the SetWindowText's I've timed.
SendMessage(hwndFrame, WM_SETTEXT, 0, LPARAM(stemp)); produces the same results, and PostMessage doesn't work
Edited by - Magmai Kai Holmlor on January 28, 2001 3:18:00 PM
quote:
Don't ask us, ask your code.
touche, I'll go time all the parts of the render loop.
Well actually, it shouldn't matter if MFC calls a Sleep(1000), I have the rendering in a seperate thread...
Every Project in Life:
Works, quick, cheap: Choose one.
...
CStatic* stFrame = geGame->m_stFrameRate;//code... sprintf(stemp,"FrameRate: %.1fHz", frame); if(stFrame) stFrame->SetWindowText(stemp); Well it's this code right here, specifically the stFrame->SetWindowText. The code usually take 230us to execute, every now & then it takes 11500us to execute, and it takes that long more frequently when I hold down any key...
Happens on all the SetWindowText's I've timed.
SendMessage(hwndFrame, WM_SETTEXT, 0, LPARAM(stemp)); produces the same results, and PostMessage doesn't work
Edited by - Magmai Kai Holmlor on January 28, 2001 3:18:00 PM
When you say the CPU usage dropped to 60% what exactly does that mean? The CPU utilization of the entire system, the process, a thread within the process? If it is the entire system then the best a profiler could do would be to tell you that 40% of your time is spent in the system idle loop, but you already know that. Your process became I/O bound and that is why the CPU usage dropped. I would check the synconization between the input thread and the rendering thread very carefully. Chances are that is stopping the renderer when it shouldn''t. A profiler may be able to help, but I would try it on a test application first with two threads sleeping. If you can''t get the profiler to tell you that from a known condition then you are unlikely to get it to tell you that on an unknown condition.
quote:
Well actually, it shouldn''t matter if MFC calls a Sleep(1000), I have the rendering in a seperate thread...
Well actually it does matter if you call your code to display the framerate from the render-code (since you use MFC-SetWindowText())
quote:
Happens on all the SetWindowText''s I''ve timed.
SendMessage(hwndFrame, WM_SETTEXT, 0, LPARAM(stemp)); produces the same results, and PostMessage doesn''t work
So don''t use SetWindowText() or create your own ''mailbox'' (protected variable) to post the framerate to and call SetWindowText() in another thread. Alt. use GetDC()/TextOut() like the rest of us...
.This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
