Tween pingpong issue after r350 update

0 favourites
  • 9 posts
From the Asset Store
Calculate parabolic trajectories and tween objects over them.
  • Alright before I updated to version r350 everything was fine but after image do not return to their original scale.

    I have a button size 136x150 and making it scale on button click

    before update it would return to it's original size of 136*150 but not anymore

    1 in 3 tries it will add/or deduct .00000000000003 value either from Height or Width or both of them.

    it is crucial for me as I have a condition before every button click I check for it's Widths which supposed to be 150

    Tagged:

  • Hello. Some integers can't be set to floating point numbers and be represented as integers on computers--I don't know if that is the problem here. In general when I check for equality with a floating point I use a range. If you know a floating point is supposed to be an int you can round before checking too. Of course, I can see how that is a pain here esp if it worked before.

    yours

    winkr7

  • went past this issue by adding waiting for previous action to complete and then set the size of sprite to a default one

  • I think it should be considered as a bug. With behaviors like MoveTo or Tween we expect pixel-perfect precision. A change like this can potentially break some projects. Please report it:

    github.com/Scirra/Construct-bugs/issues

  • IIRC, the tween behavior cannot be exact, because it has to make changes in small steps, in case anything else changes the thing that is being tweened. However changing things in small steps is subject to floating point precision errors. It's just part of how maths works on computers. I don't think it's possible to reliably work around it - the best approach is to avoid making exact comparisons and allow a small tolerance (e.g. is within 0.001 of a number instead of exactly equal).

  • the tween behavior cannot be exact

    Ashley This would be disastrous when tweening values. But thankfully it seems like this floating point issue only happens when tweening object scale. And it was indeed working correctly in r344.

  • There's loads of things that can cause floating point precision errors. Pretty much any fractional math can end up with results that are close to but not exactly correct. It's just something you have to deal with in any kind of tool with any kind of software that uses floating point data types. A famous example is that 0.1 + 0.2 = 0.30000000000000004.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads
  • Yeah, I agree that tweening to (0.1+0.2) can give that result.

    But when I tell Tween that the end value is 0.3, I expect it to finish at exactly 0.3

    The same should apply to any ping-pong tween, it should return to the initial value exactly.

  • That's not the case though - suppose you tween the angle of a child in a hierarchy while the parent also rotates. You'd expect the child to rotate relative to the parent. So it isn't going to end on the tween end value. It's cases like this that mean the Tween behavior can't just say "at the end set the exact finish value" - in fact it used to, but it broke cases like the one I just described, so it can't do that.

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