time delta and loops

This forum is currently in read-only mode.
From the Asset Store
For Adventure, Action, Heroes, Sci-fi and Action-RPG games.
  • i read the article on time delta and came to the conclusion that using time delta is quite essential to keep games from doing the unexpected but at the same time, my first steps in using TGF taught me to use loops for pixel perfect collision detection so i went and did a little test to see if i could incorporate both but it appears that moving an object using time delta by itself and moving an object using time delta accompanied with a loop do not produce the same result!

    take a look at the attached .cap file to see the results

    note: there are things there that have been left unfinished because i just got lazy and went ahead and did the bare minimum required for what i wanted to see

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads
  • You can solve problem with the looped/timescaled object by running the loop for the same value as the speed variable. Then instead of adding 1 to the objects position every loop, just have it add the time delta.

  • the whole point of using loops and moving the object 1 pixel at a time is to ensure pixel perfect collision detection at every pixel but according to deadeye, it's just not possible to mix the two and achieve what i set out to do

  • It is perfectly possible to do what you want to do - your .cap just has a rounding error. The 'start loop' action takes an integer for the number of times to run the loop, and your loop advances the box 1 pixel every loop.

    If the purple box is moving 1.4 pixels a tick, your loop will round that down to running only once (you can't have 0.4 of a loop!). So one box is moving at 1.4 pixels/sec, and the other at 1 pixel/sec. Obviously these speeds are different.

    You can do per-pixel collision tests with loops and timedelta'd movements, you just need to be careful not to cause rounding errors. The simplest way would be to calculate the final position - as a float, using .X + speed * timedelta - loop every pixel one at a time towards that position - and when the loop is done, set the position to the final, floating point saved coordinate.

  • I didn't say it wasn't possible, I said you don't need timedelta inside of a loop because the loop would complete before the final position of the sprite is updated. Or something. I don't remember now.

    I think what I meant was you should move your objects with timedelta, but if you're doing something like a loop that pushes things out of solids you don't need timedelta.

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