Yet another timing thread

Discussion in 'Game Development (Technical)' started by Mike Boeh, May 19, 2006.

Thread Status:
Not open for further replies.
  1. Jamie W

    Original Member Indie Author

    Joined:
    Apr 16, 2006
    Messages:
    1,211
    Likes Received:
    0
    Thanks Cas.

    The simplicity of #1, very much appeals to me. I'm just concerned, thinking it must be too good to be true, and what's the catch, or drawbacks with it etc?

    If you're requesting the monitor to go to 60hz, and it doens't, but you're still updating your game physics at 60hz, doesn't that make the action 'choppy'? Has that been an issue for you?
     
  2. Fabio

    Original Member

    Joined:
    Sep 30, 2005
    Messages:
    499
    Likes Received:
    0
    I don't understand the link between "delta time" and "nonsense", but I'm guilty of not wanting inefficient code that even chops..
     
  3. princec

    Indie Author

    Joined:
    Jul 27, 2004
    Messages:
    4,873
    Likes Received:
    0
    The catch is you are restricted to designing your game around a 60Hz tick rate with not much scope to change that afterwards should the need arise. I like restrictions like this though, as they help me focus.

    The other catch is that for true 3D games it's not a good method. The brain processes depth information in a completely different way to panning motions. For a 2D game, ie. one where the fundamental gameplay is in two dimensions not necessarily the renderering - the brain much, much, much prefers that the action slow down and every frame is rendered one at a time rather than suddenly warping. For 3D the exact opposite is true, by and large. As you're doing 2D though it's a good choice, IMHO.

    To see what a 60Hz game looks and plays like when the monitor's at 85Hz, try one of mine in windowed mode.

    Cas :)
     
  4. luggage

    Moderator Original Member Indie Author

    Joined:
    Jul 27, 2004
    Messages:
    2,132
    Likes Received:
    0
    Rainer: Your techincal problems have been addressed by others - I didn't feel the need to go over that ground again.
     
  5. Jamie W

    Original Member Indie Author

    Joined:
    Apr 16, 2006
    Messages:
    1,211
    Likes Received:
    0
    Hi Fabio,

    Me too! I'm guilty of not wanting inefficient code that even chops; yet I have no problem understanding the link between "delta time" and "nonsense".

    :p

    Seriously though, for a 3D game, it's all well and fine. For a 2d smooth arcade style game, I personally wouldn't use it. For one, I just don't like the idea of factoring in a 'delta time' in to all game object movements. It's adding more complication to my code, and I feel the time and energy spend doing so, would be better used elsewhere. That's just my personal preference and feeling though, no doubt others will have a different view (and you're all wrong ... haha).
     
  6. Anthony Flack

    Indie Author

    Joined:
    Jul 27, 2004
    Messages:
    2,176
    Likes Received:
    0
    The idea of turning every integer ticker and counter into a floating-point hairball is enough to put me off delta time. I use a lot of simple integer counting variables.
     
  7. Jamie W

    Original Member Indie Author

    Joined:
    Apr 16, 2006
    Messages:
    1,211
    Likes Received:
    0
    You don't have any problem with your game running faster than you intend, on some systems?

    What percentage of your users, do you think play your games faster than the intended 60hz? What's your feeling on this?

    I've played your titan attacks and robotron games, both work fine (very smooth) in fullscreen and in windowed mode, my LCD is set at 60hz anyway, and I can't set my LCD to anything but 60hz. Is that standard with LCD displays? Are they all 60hz?
     
  8. Mike Boeh

    Administrator Original Member

    Joined:
    Jul 26, 2004
    Messages:
    949
    Likes Received:
    0
    A lot of the time, a simple 60hz timer would work... But there are a couple problems....
    • It won't be smooth in windowed mode (the other three methods will)
    • When changing the sync of the monitor, the screen sometimes won't be centered. I used to get a lot of tech support emails about this one.
    • This may not be a problem, but how often do you actually get the hz you request?
    #2 usually produces smooth results, and is very nice for doing simple, accurate collisions. But it's also the least efficient. The thought of having to account for time in my logic loop really puts me off to #3...

    I guess there is still no single method that's best. I was thinking of writing a demo that does all 4....
     
  9. luggage

    Moderator Original Member Indie Author

    Joined:
    Jul 27, 2004
    Messages:
    2,132
    Likes Received:
    0
    Timers have to be floats, I usually do the following...
    Code:
    timer = 2.0f;   // delta is in seconds so this will be a 2 second timer.
    then in the update...
    Code:
    timer -= delta;
    
    if (timer <= 0.0f)
    {
         // timer is up.
    }
     
  10. Speckled Jim

    Original Member

    Joined:
    Aug 29, 2005
    Messages:
    93
    Likes Received:
    0
    It's no more complicated though, just a different way of thinking about it. If you are using integer counters now to track time based on a certain discrete timestep, then that is arguably more complicated then just being able to check for reaching a specific time directly, ie 4.5 is 4.5 seconds, instead of a count of 270 using a 60hz timer.
     
  11. princec

    Indie Author

    Joined:
    Jul 27, 2004
    Messages:
    4,873
    Likes Received:
    0
    Hm, maybe because you started a few years before me... but I've never ever had anyone drop me a line because their monitor's displayed the picture in the wrong place. I know they do it because I've seen it myself but still for some reason no-one's seen fit to email me.

    I've no idea how often I get the frequency I request but I suspect it's close to 100% of the time.

    Also, my games run perfectly smooth in windowed mode (and always at 60Hz) using a high-res timer to cap it within 1ms accuracy. Or at least so smoothly you can't tell, and that's the desired effect!

    Cas :)
     
  12. oNyx

    Original Member

    Joined:
    Jul 26, 2004
    Messages:
    1,212
    Likes Received:
    0
    It isnt really a matter of 2d vs 3d imo. Its how much of the screen changes, how fast and the strength of contrast.

    First person shooters for example are pretty much the worst case scenario. The whole screen changes all the time and you can even see tiny differences between 2 different jump height rounding methods at 85fps@85hz. (That really surprised me actually.)

    And on the other side of the spectrum are colorful 2d games w/o scrolling.

    But I agree that this simple method seems to be just fine for 2d games... even with rather fast 2d scrollers you dont see much of a difference (because its still relatively slow even if it feels sorta fast).

    The loop is backed up by a frame cap method, which tries to limit the minimum time per frame to 16 msec (- last frame catch up), which in turn means that the maximum framerate is 62.5fps (if vsync is disabled).

    The only issue you have are slowdowns on systems, which dont meet the minimum system requirements (just keep em low) or those other weird cases with 50hz or 55hz tfts (they are pretty rare) or well... that thing I mentioned before (ati + tv-out enabled + pal + vsync = 50fps max).
     
  13. Jamie W

    Original Member Indie Author

    Joined:
    Apr 16, 2006
    Messages:
    1,211
    Likes Received:
    0
    OK, we're still talking about #1 here oNyx? (and I agree it's probably more suited to 2D arcade games).

    The issues I can see with it, are:

    1. If you code your game to assume a 60hz update, and a user has say a 75hz display, the game will speed up.

    2. If you cap your game to avoid this speeding up, the movement of your game objects (and scrolling) will appear 'choppy'.

    The above (2) assumes fullscreen mode using vsync, it sounds like Cas doesn't have too many problems with his game using #1, in windowed mode.

    Capping comes in to play on (the very few) systems that fail to go in to 60hz on request, is that correct?
     
  14. Rainer Deyke

    Indie Author

    Joined:
    Jul 28, 2004
    Messages:
    380
    Likes Received:
    0
    If you use method #3 (i.e. delta-time), you will experience slight variantions in the game simulation each time you run the game. This is unavoidable. If you find this acceptable, go for it. If you choose method #4 (or #2 or #1) instead, you gain the following benefits:
    • You can record the input and play back the game simulation exactly, which is very valuable for debugging and can also be used for other uses (i.e. attract mode, instant replay).
    • If you have a networked mode, you can make sure that variations in the game simulation between different computers on the network are kept at an absolute minimum.
    • You get to factor out the timing code from the game simulation. Once the timing code works, you never have to touch it again and you will never experience another timing bug.
    • You don't have to worry about the magnitude of the variation between slow computers and fast computers, because there isn't any. You don't have to worry about setting the upper and lower limit of the time delta, because there isn't any. You don't need to worry about the effects of erratic time deltas on the numerical stability of your simulation. Everything just works.
    • You get the personal satisfaction of knowing that your game isn't just sufficiently but absolutely independent of computer speed.
     
  15. oNyx

    Original Member

    Joined:
    Jul 26, 2004
    Messages:
    1,212
    Likes Received:
    0
    >OK, we're still talking about #1 here oNyx?

    Yes.

    >1. If you code your game to assume a 60hz update, and a user has say a
    >75hz display, the game will speed up.

    You need to back it up with a framecap. There is no guarantee that you can pick a 60hz mode and there is also no guarantee that you can enable vsync (a driver-sided "always off" overrules everything).

    >2. If you cap your game to avoid this speeding up, the movement of your
    >game objects (and scrolling) will appear 'choppy'.

    Yes. But it wont be that visible. (It is pretty visible with a white rect on black background tho.)

    >Capping comes in to play on (the very few) systems that fail to go in to
    >60hz on request, is that correct?

    Yes. And if you cannot enable vsync (or more generally if its set to "always off").
     
  16. TheMysteriousStranger

    Original Member

    Joined:
    Jan 17, 2006
    Messages:
    222
    Likes Received:
    0
    That's the whole point of delta. Computers do not run perfectly at the same speed all the time - other tasks like to try and steal your game's cpu time. Delta timing is designed to incorporate those slight variations into the game updates, removing any problems with the game update not running at the required speed.

    Care to explain to Id then that their Q3 engine (which uses delta timing) isn't recording the input for demo playback? I have recorded demos myself in Q3 engine games and it seemed flawless to me.

    If synchronisation is that important to your game (a factor that is less important since broadband became the norm for online gaming), then you can seperate game logic and network timings, and simply send timescale data along with the update data from the server, making it possible to sync the client to the server.

    It's still possible to make timing based bugs in non-delta systems. It's all about testing/bug fixing until your game no longer has those bugs.

    You seem to have missed the entire point of delta timing systems - with delta, the time difference can be small or it can be huge - the game will still work EXACTLY the same. If it doesn't work properly, it's the dev's fault for making a lazy implementation of delta, it's not a flaw in delta timing systems. A good delta implementation is able to work with erratic timing - it's expected.

    This doesn't even make sense. Delta timing is completely independant of the system speed - the whole point of basing movement/updates in delta timings is to seperate the game updates from the speed of the system.
     
  17. luggage

    Moderator Original Member Indie Author

    Joined:
    Jul 27, 2004
    Messages:
    2,132
    Likes Received:
    0
    What if the bottleneck on a slow machine is the CPU? And your logic won't run at 250-1000 fps? What do you do then? Drop your logic and then go back through your entire game adjusting your timing values?

    You get several nice "pros" when you use a delta system...
    * It's an absolute piece of cake to move to other timing systems.
    * You can do super smooth slow motion and bullet time effects.
    * You can speed your game up for testing or put "hyperspace" effects in for free.
    * You can still record games for debugging. Just dump out the delta at the same time. Easy.
    * You get a pause mode for free.
    * You get the "personal satisfaction" of knowing your code isn't inefficient.
    * You get the "personal satsifaction" of knowing you're not causing laptop batteries the world over to run out long before it should.
    * Working out how long a wait is is easier.
    * You can stick to Standard Units. 1.0f = 1 meter. 1.0f = 1 second. I want to move at 10 metres per second? x += 10.0f * delta;
    * You get to be able to draw more things as you're not wasting CPU time.
    * You don't have to worry about slow CPU's causing your game to bottleneck.

    I can't be bothered to do any more but it's easy to find pro's if you look hard enough for any of the methods. The whole point of this discussion is that there are several methods all will work and all have their pro's and con's. You keep saying delta is flawed but that "flaw" can be fixed with...
    Code:
    if (delta > 0.5f)
    {
         delta = 0.5f;
    }
    before you call any of your updates. Job done. Never have to worry about it again. And the day a render takes no clock cycles is the day I'll worry about my delta being zero.

    Slight variations in the game simulation do not matter. In fact, the player will probably get slight variations in what they see no matter which method you use.
     
    #77 luggage, May 21, 2006
    Last edited: May 21, 2006
  18. PeterM

    Original Member

    Joined:
    Aug 5, 2004
    Messages:
    343
    Likes Received:
    0
    To (hopefully) clarify the issue for FPS engines:

    Engines like Quake 3 often use a fixed server logic update rate, but that rate is admin-tweakable. So the movement uses delta-time, since it doesn't know ahead of time what the update rate will be. On the server it will be fixed, on the client it will be variable.
     
    #78 PeterM, May 21, 2006
    Last edited: May 21, 2006
  19. Mike Boeh

    Administrator Original Member

    Joined:
    Jul 26, 2004
    Messages:
    949
    Likes Received:
    0
    I just tried Titan Attacks windowed... It's not silk smooth because I run at 100hz desktop... But most gamers would probably never notice the difference anyway, so there's really nothing wrong with using that method.... (EDIT: oh and it did take my monitor to 60 hz fullscreen)

    I got collisions going perfectly with #4, so I am sticking with it for now... No latency that I can perceive, and I am a really big stickler for that kind of thing :)

    But in reading all the opinions here, it seems like there are really valid pros and cons to each way....
     
    #79 Mike Boeh, May 21, 2006
    Last edited: May 21, 2006
  20. vjvj

    Indie Author

    Joined:
    Sep 25, 2004
    Messages:
    1,732
    Likes Received:
    0
    Good points. The reason I'm asking is because the technique in question (linked by PeterM earlier: http://www.gaffer.org/articles/Timestep.html) actually appears to be a hybrid of #3 and #4. It accepts delta time as input but processes the simulation at fixed timesteps and tweens with the previous frame. So in theory you get fixed timesteps with better CPU load balancing. I'm just wondering if I'm missing something obvious :D
     
Thread Status:
Not open for further replies.

Share This Page

  • About Indie Gamer

    When the original Dexterity Forums closed in 2004, Indie Gamer was born and a diverse community has grown out of a passion for creating great games. Here you will find over 10 years of in-depth discussion on game design, the business of game development, and marketing/sales. Indie Gamer also provides a friendly place to meet up with other Developers, Artists, Composers and Writers.
  • Buy us a beer!

    Indie Gamer is delicately held together by a single poor bastard who thankfully gets help from various community volunteers. If you frequent this site or have found value in something you've learned here, help keep the site running by donating a few dollars (for beer of course)!

    Sure, I'll Buy You a Beer