🔒 Locked

threads and flipping

Started by EODCyismARDEM Jun 2, 2002 at 12:09 PM 3 replies 350+ views

Original Post

Jun 2, 2002 at 12:09 PM

i''ve had this idea in my head for about 2 days and i just wanted to know whether it would work or not i''m new to threads and all but i think i have a generall idea about what they are lets say your monitor refreshes at 60hz, that means in ddraw the most fps you can get is 60fps unless you don''t wait for vertical retrace. That means you can at most show a frame every 16ms. lets say all your calculations take about 16 ms to do this means that at best you''ll show the frame in 16ms (60fps) and at worst 32 ms (30fps) like this: fliping 5ms (this will take 0 to 16 ms to do depending on where fliping 5ms the vertical trace is when you start) fliping 5ms <- keeps on doing this for a total of 32ms calc''ing 5ms calc''ing 5ms calc''ing 5ms draw to back buffer if you had 2 threads, one for flipping only, and one for calculations only, then why can''t you do this. fliping 5ms calcing (for next frame) fliping 5ms calcing fliping 5ms calcing draw to backbuffer (in calcing thread) so that this way you get closer to an average of 60 fps. i''m sure this doesn''t work, or people would do it. can somebody tell whats wrong with this or what?

EODCyismARDEM

Jun 2, 2002 at 12:28 PM

even though the processor only does one command at a time, wouldn''t the flip commands be mixed with the calculating commands. like this

flipping command
calc command
flipping command
calc command

rather than this
flipping command
flipping command
calc command
calc command

like if i''m running an exe i made and its currently running the function DoSomething(), and i also have 4 programs running in the background, it won''t put all those 4 programs on hold until DoSomething ends... will it?

jjmontes

Jun 2, 2002 at 2:02 PM

I think that really, you loose some time when waiting for Vertical Retrace. Only in the case that you use a syncronous Flip, because it can be done in asyncronous mode.

So if you have another thread calculating the next frame it would really help because in fact your first thread is only waiting. BUT remember that when you''re calculating the NEXT frame you cannot blit to the backbuffer (it isn''t flipped yet).

I think the best solution for this, avoiding threads if you want is to use triple buffering (2 background surfaces), with this you can always flip in the moment, because you still have another backbuffer which you can write in.

There are other issues here: you can use GetFlipStatus to know where the vertical retrace is, or use asynchronous flip and calculate AI, game logic, etc... and when the flip was really done beggin blitting.

I don''t recomend using a thread to do what you say, you can end up writing to surfaces which aren''t flipped yet, or trying to blit when the blitter is occupied or waiting.

Hope this helps.

Real programers are not afraid from maths! (from an Asfixia Member I think)
JJpRiVaTe Private Zone

EODCyismARDEM

Jun 2, 2002 at 2:28 PM

yeh sorry that was just a typo, i meant another surface which you can blit to the backbuffer once it has finished flipping. But you know what when i think about it this sounds like basically what triple buffering does. thanks for the help!

Topic Locked

This topic has been locked by a moderator. New replies are not allowed.