effieciency or advantages over delta time or ticks?

This forum is currently in read-only mode.
From the Asset Store
75 power-up sound effects; bonus and notification sounds, fanfares, harp glissandi, stabs, clock ticks, etc.
  • Hello friends, I am making a platform game with the run mechanics similar to a Castlevania or Kirby game... that is, you are walking, and then you let go of the walk button, and then press it again to run. After initially releasing the walking button, you only have a short time to press it again to start running, otherwise you just keep walking.

    I have successfully done this, and achieved what I want without using the "wait" object, or delta time (the reason being I don't fully understand them). What I did instead was I set a private variable to a number (once the required conditions for running were true) and then subtracted from it every tick until it goes back to zero.

    My question for the community is-- is this a bad way to do this? I think ticks are based on framerate, and so the ability to run within the game might be affected based on the frame-rate itself... if that was the case could I just set the framerate to a constant 60 perhaps? Or should I rework it based off of milliseconds and whatnot...?

    Here is a cap for interested eyes...

    http://dl.dropbox.com/u/19590484/cityscape.cap

  • What I did instead was I set a private variable to a number (once the required conditions for running were true) and then subtracted from it every tick until it goes back to zero.

    This is what I'm doing quite a lot as well. But...

    My question for the community is-- is this a bad way to do this? I think ticks are based on framerate, and so the ability to run within the game might be affected based on the frame-rate itself... if that was the case could I just set the framerate to a constant 60 perhaps? Or should I rework it based off of milliseconds and whatnot...?

    ...yes, you really should use Timedelta here. So instead of simply subtracting a certain value every tick (you don't need to add an always event btw for it to run every tick), you substract value*Timedelta, as described in the wiki. Otherwise the game will definitely run differently depending on refresh rate.

  • I had a feeling I would have to learn how delta time works. Thank you for the wiki link!

  • Not everyone might be running at the same framerate; even if you lock it at 60 FPS, some people with crappy computers may actually get half that amount. In that case their mileage may vary.

    TimeDelta ensures that a moving object makes the same distance within same time on all computers.

  • For more on time delta you might also want to have a look at Verve!, I made it completely time based with comments to every event.

  • Try Construct 3

    Develop games in your browser. Powerful, performant & highly capable.

    Try Now Construct 3 users don't see these ads
  • Just keep in mind that delta time has it's limitations too... if the player's computer suffers a loss of framerate, then your object will be moving more space per tick than normal. If the framerate drops too low, a fast moving object might skip past an object it is supposed to collide with!

    For the most part this isn't a problem unless you're trying to collide very small or skinny objects that are moving fast. Just something to keep in mind when you're doing your collision events.

    I'm not saying it's a trade-off though... you should ALWAYS use delta time for any time-based operations like movement. But if you need pixel-perfect collision with small, fast objects you'll probably have to code some custom collision checking routines.

Jump to:
Active Users
There are 1 visitors browsing this topic (0 users and 1 guests)