delta time issues

0 favourites
  • 12 posts
From the Asset Store
An educational game for Times Table. An easy to use template for developers to build larger games
  • im having difficulty implementing this..

    some questions, will it help frame rate in general ?

    and just say i wrote some thing like "every 3 seconds: create this "

    where would the "dt"go ?

    Is it worth changing all my timing to this ?

  • railslave, dt does not help frame rate, but rather makes movements frame rate independent. Thus if you do sprite move 100*dt, it will move 100 pixels in a second, regardless of frame rate. The system calculates the dt appropriately to make sure you move 100 pixels in a second.

    For create this every three seconds you do not need dt, as you are already frame rate independent and it will create the object every three seconds.

    If you have not already read it, I found this tutorial very helpful.

    scirra.com/tutorials/67/delta-time-and-framerate-independence

    It is most likely good to include dt in your movement and angle calculations. Note that at very low frame rates your movements may become jerky as you move large distances per tick. For very static games, like memory matching it will probably not make a difference.

  • This is just a booby trap for new people.

    Rather than having it so every movement is already on delta time, they make it so you need to add a special little formula to make your game actually work the same on every system. There is NO hint about this little secret unless you sift through the tutorial section and stumble across the delta time tutorial.

    It is "broken by default" in my opinion.

    They should make it cryptic and difficult to make things NOT delta time, not the other way around.

    There a are quite a few little things like this. They make it so new people can see a working game in preview, yet when they export it it will be nearly non-functional on their clients machines.

    In my opinion this is a form of "Bait then switch".

    New user sees that their little project works in preview, so they buy C2.

    Later they find out they were tricked, and their game is not playable on any system except the developers system in preview mode.

    I lost almost a weeks worth of time trying to convert a finished game to use delta time. I ended up just abandoning the project because it would have been less time to just start over from scratch.

    TL;DR

    Do not attempt to make a game with C2 unless you read EVERY tutorial, Every Blog entry, and EVERY forum post. You might miss a cryptic little thing like this and your project may not be recoverable.

    Do not even start a project unless you have tested every function you might need. You need to test in both preview and the exported game.

    "The Obvious way", and "The easy way" are almost always wrong with C2.

  • Rather than having it so every movement is already on delta time, they make it so you need to add a special little formula to make your game actually work the same on every system. There is NO hint about this little secret unless you sift through the tutorial section and stumble across the delta time tutorial.

    Every default behavior uses dt by design.

  • Every default behavior uses dt by design.

    Here you go:

    Tutorialk on delta time.

    Be sure to read it all. especially this part:

    se dt everywhere

    Any time you move an object at a steady speed, you need to use dt in that way to achieve framerate independence. For example, Sprite's Move forward action takes a number of pixels to move the object forward. If you constantly move the object forwards, you could move it forward 60 * dt pixels to move it at 60 pixels per second at its current angle.

    Obviously it is not default. Especially when you are dealing with Physics.Only the Behaviours have Defaults like this.

  • > Every default behavior uses dt by design.

    Here you go:

    Tutorialk on delta time.

    Be sure to read it all. especially this part:

    se dt everywhere

    > Any time you move an object at a steady speed, you need to use dt in that way to achieve framerate independence. For example, Sprite's Move forward action takes a number of pixels to move the object forward. If you constantly move the object forwards, you could move it forward 60 * dt pixels to move it at 60 pixels per second at its current angle.

    >

    Obviously it is not default. Especially when you are dealing with Physics.

    I'm well aware of that document. I said default behavior, move forward is standard sprite action, not a behavior. :)

  • Also from the tutorial:

    Don't forget behaviors already use dt (except with Physics where you must turn it on yourself). If you use behaviors to control all motion in your game, you don't have to worry about dt at all! However, most games have some event-controlled motion, and it's important to remember how to make it framerate independent.

  • I was not talking about Behaviours. A well executed troll, My hats off to you.

  • I was not talking about Behaviours. A well executed troll, My hats off to you.

    Then I misunderstood this part: "Rather than having it so every movement is already on delta time, they make it so you need to add a special little formula to make your game actually work the same on every system. "

    Did not understand the trolling part.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads
  • vee41

    I misunderstood the same part..

    jojoe

    Your rant was probably too unclear for vee41 and me to understand. If reacting with relevant info on the subject is considered trolling nowadays, I guess I'm the biggest troll ever.

  • Not a rant, it is a suggestion in broken, unreadable english.

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