Conversions between /tick and /second.

I have read your blog.

https://www.scirra.com/blog/203/some-bo ... onstruct-3

Sounds to me that there is now a better conversion between pixels/tick and pixels/second. Why not make that public available?

Can i please have a System expression that makes a accurate conversion from pixels/tick to pixels/second.

And.

Can i please have a System expression that makes a accurate conversion from pixels/second to pixels/tick.

Ty.

You mean an expression like dt? Delta pixel?

I'm not sure what you mean. There is no new conversion between pixels/tick and pixels/second. As ever, the pixels per tick is the speed in pixels per second times delta-time.

Excerpt :

With the new mode, jump heights are calculated with very high precision, even when delta-time has some random variations.

Dt is not reliable, you (seem) to know this.

Dt will always have random variations, that's the entire point. The fix Ashley made is internal to the platform behavior code only, and has nothing to do with Dt or pixels per tick/second in general.

If you say so.

Yet.

The platform behaviour is more accurate, and is made more accurate to be able to predict its movements with a high precision. So far i am very happy with the change.

But, now, if i want to predict platform movement, i need the tools that are as accurate, and that has everything to do with a conversion from pixels/sec to pixels/tick. Because the velocity's are in pixels/second units and a typical 'every tick event' is in pixels/tick units.

You can open/inspect the .c3p that i posted here.

And tell me if we can predict the velocity's with a higher precision now. I feel it is not the case. But hey, i have been wrong before, and will be tomorrow again. And i can keep using the (slower fluctuating) fps.

I would just like a reliable ,fast, under the skin, conversion without the random fluctuations, expressions would be something i can use, and (more important) something i can explain easy.

But if none is up to it. Well, drop it. All fine by me.

So basically expectedpixelspersecond*dt does not equal pixelsexpectedpersecond

Basically i think that Platform is more accurate. Bullet is way more accurate. Thanking the team very much.

But .... Sprite.Platform.VectorX * dt is not. (or Sprite.Bullet.Speed, for that matter)

Adding (Sprite.Platform.VectorX * dt) to itself, (basic stuff) will still accumulate the little errors into big errors.

Adding (Sprite.Platform.VectorX / fps) to itself, seems more reliable.

So, overall, it feels like, under the hood it is possible. For the engine, yes. For the user, no.

I conclude (with my average dumb brain) that the same accuracy must be possible (without breaking current dt) in an expression like :

(System) PixelsPerSecondToPixelsPerPixel(n) .... And the inverse for feeding values to the behaviours. With the same trick as done for the jump height.

(hell of a name, i know,sorry for that)

Is this .c3p file supposed to show that when moving the circle back and forth, the black line doesn't always line up with the ground at the same place as when you started? (when pushing it back and forth against the wall, let's say, it becomes misaligned compared to the starting state.)

If that's what you're trying to show, here's my response:

Sampling delta time in an accumulator fashion like what you're doing in the .c3p will always show imperfect results. Why? Because delta time varies ever so slightly and you're summing a ton of floating point data over time. Floating point data does not represent an exact number (due to a finite number of bits used to store it), and is susceptible to rounding error/cutoff. The problem becomes exacerbated when you start summing up lots and lots of this approximated data, because you're losing some every time.

Sounds familiar. Oh wait. That is what i said.