Jump to content
  • Advertisement

Archived

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

CoolMike

Mandatory Lock/Unlock

This topic is 6507 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

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?

Share this post


Link to post
Share on other sites
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( );

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
Cause Direct X is gay? Sorry guess that doesn''t help you much. I stick to OpenGl.

Share this post


Link to post
Share on other sites
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?

Share this post


Link to post
Share on other sites
/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

Share this post


Link to post
Share on other sites
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

Share this post


Link to post
Share on other sites
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

Share this post


Link to post
Share on other sites
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

Share this post


Link to post
Share on other sites
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

Share this post


Link to post
Share on other sites

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!