The Dink Network

Reply to Re: Dink Smallwood v1.08 - Suggestions

If you don't have an account, just leave the password field blank.
Username:
Password:
Subject:
Antispam: Enter 'banana' (without quotes) below.
Formatting: :) :( ;( :P ;) :D >( : :s :O evil cat blood
Bold font Italic font hyperlink Code tags
Message:
 
 
June 26th 2005, 10:57 PM
king.gif
redink1
Noble Male United States xbox
Strange times for barking mimes 
But that doesn't happen in reality. There's no way that anyone gets 1000 frames per second. The difference is visible over a course of time.

Lets say that we get exactly 60 frames a second, or 17 milliseconds a frame. This will never happen with the Dink engine, but we're pretending.

Say we measure two sprites with frame delays of 18 and 19 with the same sequence.

Draw 0 (0 ms elapsed): S1=1 S2=1
Draw 1 (17 ms elapsed): S1=1 S2=1
Draw 2 (32 ms elapsed): S1=2 S2=2
...
Draw 8 (136 ms elapsed): S1=8, S2=8
Draw 9 (153 ms elapsed): S1=9, S2=9
Draw 10 (170 ms elapsed): S1=10, S2=9

So, for 9 or so frames, the sprites will display the same frame. But every 19 draws (the first increment happens around 19/2), S1 will increment one faster than S2, making it *appear* to update 1 ms faster even though updates only happen every 17 ms.

If you hard-lock it so a frame is only calculated and drawn at least 17 ms, then any frame delays under 17 ms will appear to be 17 ms.

And I just thought of something... Seth may want the hard-lock-at-60 as a quick-fix for Dink's speedy problem... but it should be possible to fix it without that lock.