Mandatory Lock/Unlock
I am having a problem with my directx wrapper/program. Directdraw, directSound and directInput all initialize fine and the game goes into a simple loop. But if I do not lock and unlock the backbuffer each loop, the game input is delayed by about 1 second for some reason. The mouse is extremely sluggish and key presses do not register immediately. When I lock and unlock the backbuffer, the game performs smoothly without any problems, besides the fact that the frames per second drop from around 440 to 300! I cannot figure out why it is mandatory that I lock and unlock the back buffer so much. Any ideas?
I don''t know, but who cares? When you write an actual game, one Lock/Unlock won''t make a noticeable difference. Also, keep in mind that calling BltFast or Blt also locks/unlocks the surface, along with doing actual blitting.
I call Lock/Unlock at the beginning of each frame, and it does not affect performance since I already have many sprites and things on the screen.
~CGameProgrammer( );
I call Lock/Unlock at the beginning of each frame, and it does not affect performance since I already have many sprites and things on the screen.
~CGameProgrammer( );
I seem to have just solved my problem, sort of. When I blit my mouse cursor bitmap 1000 times (ie slowing the frame rate down to about 80), and I do not lock or unlock the backbuffer, the input is not delayed at all and the mouse and keyboard respond perfectly. So is the problem perhaps with the graphics updating too fast for the input? I doubt this would be the problem, but what do you guys think?
/me stepping on soapbox
This is my pet peeve -- I know this is a programming forum, not a a political forum and that the anonymous poster prolly meant no harm, but think about what calling something that you consider bad as "gay" means. . . gay = homosexual = bad.
gay = homosexual != bad.
Think about it. We don''t say, "Cause Direct X is Nigger." or "Cause Direct X is Spick." "Cause Direct X is JudenRa." "Cause Direct X is Coolie." "Cause Direct X is Irish."
It''s just not accepted or acceptable.
I know using "gay" as a derogatory term is almost colloquial usage (especially on-line), but think about it and be considerate. . .
Thanks. /me stepping off soapbox.
DmGoober
quote:Original post by Anonymous Poster
Cause Direct X is gay? Sorry guess that doesn''t help you much. I stick to OpenGl.
This is my pet peeve -- I know this is a programming forum, not a a political forum and that the anonymous poster prolly meant no harm, but think about what calling something that you consider bad as "gay" means. . . gay = homosexual = bad.
gay = homosexual != bad.
Think about it. We don''t say, "Cause Direct X is Nigger." or "Cause Direct X is Spick." "Cause Direct X is JudenRa." "Cause Direct X is Coolie." "Cause Direct X is Irish."
It''s just not accepted or acceptable.
I know using "gay" as a derogatory term is almost colloquial usage (especially on-line), but think about it and be considerate. . .
Thanks. /me stepping off soapbox.
DmGoober
I suppose that the AP uses OpenGL for input, sound, networking, music synthesis and networking. Really.
Are you sure that you are not changing something else when you use your program other than locking/unlocking the backbuffer?
Please state the nature of the debugging emergency.
Are you sure that you are not changing something else when you use your program other than locking/unlocking the backbuffer?
Please state the nature of the debugging emergency.
Hey, not to go off on a tangent here (since I agree with you on the gay thing, people who say that sound 12) but what in the hell do these two mean:
Never heard of them, and can''t even pronounce the first.
--
HitScan
quote:
"Cause Direct X is JudenRa." "Cause Direct X is Coolie."
Never heard of them, and can''t even pronounce the first.
--
HitScan
Going back to the original (mature) point of this thread...
I''ve noticed that input doesn''t register properly in my game engine if I don''t put in a Sleep(1) in the main loop...it''s a small 1ms wait time, but the response improvement is great.
Maybe this is the same thing?
MatrixCubed
http://www.MatrixCubed.org
I''ve noticed that input doesn''t register properly in my game engine if I don''t put in a Sleep(1) in the main loop...it''s a small 1ms wait time, but the response improvement is great.
Maybe this is the same thing?
MatrixCubed
http://www.MatrixCubed.org
I guess this is the point, where that discussion "Should we allow Anonymous Posters?" comes up.
Really, Anon ... if you don''t have anything useful to say, then just shut up!
- MK42
Really, Anon ... if you don''t have anything useful to say, then just shut up!
- MK42
Actually, you're right -- it's the high framerate that causes the problem. I just remembered that when my 3D engine ran in hardware mode, displaying only a few polygons, input was delayed and worked strangely. In software mode, with framerate much lower, it worked fine.
It isn't really framerate per se, but how many times per second you're checking input. Keep in mind that you don't need to check input more than 20 times per second, and probably not even that often. As long as you have time-based animation and movement, as opposed to frame-based, you'll be fine checking input only occasionally. So you can do something like:
That will probably fix the problem.
Edited by - CGameProgrammer on November 29, 2000 1:05:32 PM
It isn't really framerate per se, but how many times per second you're checking input. Keep in mind that you don't need to check input more than 20 times per second, and probably not even that often. As long as you have time-based animation and movement, as opposed to frame-based, you'll be fine checking input only occasionally. So you can do something like:
void MainLoop ( ){ CurrFrameTime = 0.001 * float( timeGetTime() ); if( CurrFrameTime - LastFrameTime >= 0.05 ) { LastFrameTime = CurrFrameTime; GetUserInput( ); } RenderScene( );}
That will probably fix the problem.
Edited by - CGameProgrammer on November 29, 2000 1:05:32 PM
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement