Mandatory Lock/Unlock

Started by
9 comments, last by CoolMike 23 years, 5 months ago
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?
Advertisement
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( );

~CGameProgrammer( );Developer Image Exchange -- New Features: Upload screenshots of your games (size is unlimited) and upload the game itself (up to 10MB). Free. No registration needed.
Cause Direct X is gay? Sorry guess that doesn''t help you much. I stick to OpenGl.
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
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
Alexander "DmGoober" Jhinalexjh@online.microsoft.com[Warning! This email account is not attended. All comments are the opinions of an individual employee and are not representative of Microsoft Corporation.]
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.


sharewaregames.20m.com

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:
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 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
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:
  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
~CGameProgrammer( );Developer Image Exchange -- New Features: Upload screenshots of your games (size is unlimited) and upload the game itself (up to 10MB). Free. No registration needed.

This topic is closed to new replies.

Advertisement