Conversions between /tick and /second.

Post » Mon Apr 03, 2017 2:39 pm

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.
B
33
S
18
G
27
Posts: 2,436
Reputation: 20,336

Post » Mon Apr 03, 2017 2:55 pm

You mean an expression like dt? Delta pixel?
Image ImageImage
B
168
S
50
G
163
Posts: 8,221
Reputation: 105,061

Post » Mon Apr 03, 2017 3:05 pm

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.
Scirra Founder
B
387
S
230
G
87
Posts: 24,248
Reputation: 192,228

Post » Mon Apr 03, 2017 4:14 pm

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.
B
33
S
18
G
27
Posts: 2,436
Reputation: 20,336

Post » Mon Apr 03, 2017 5:10 pm

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.
B
44
S
9
G
9
Posts: 1,222
Reputation: 8,245

Post » Mon Apr 03, 2017 5:59 pm

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.
viewtopic.php?f=191&t=189953&p=1113394#p1113394

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.
B
33
S
18
G
27
Posts: 2,436
Reputation: 20,336

Post » Mon Apr 03, 2017 6:05 pm

So basically expectedpixelspersecond*dt does not equal pixelsexpectedpersecond
Image ImageImage
B
168
S
50
G
163
Posts: 8,221
Reputation: 105,061

Post » Mon Apr 03, 2017 6:40 pm

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)
B
33
S
18
G
27
Posts: 2,436
Reputation: 20,336

Post » Mon Apr 03, 2017 11:32 pm

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.
B
44
S
9
G
9
Posts: 1,222
Reputation: 8,245

Post » Tue Apr 04, 2017 12:18 pm

Sounds familiar. Oh wait. That is what i said.
B
33
S
18
G
27
Posts: 2,436
Reputation: 20,336


Return to General Discussion

Who is online

Users browsing this forum: No registered users and 2 guests