[math vs behavior]Is there something wrong

On the following capx file (it is a capx, you can download it with the top button, google drive just recognize it as a zip file):

https://drive.google.com/file/d/0B-Asjs ... sp=sharing

We have two objects, Blue and green, as well as 2 tiledbackgrounds (one is the ground, the other is ust here as a height reference), If you run the capx, and press the up arrow, both will elevate sort of the same height, and take about 6 seconds to end the jump (3 to go to the top of the red tiledbackground, and 3 others to come back to the ground)

However, Blue has a 200px/s initial speed and 66.6666 gravity, while green has a 33.3333 gravity.

Maths shows us that if the time to go up is T1, and the height of the jump is Y1, we have:

V1 the jump strength (aka initial speed in px/s): V1=2*Y1/T1

G the gravity (in px/s²) : Y1/(T1²)

So for a 300 px height, for 3 seconds to reach those 300px:

V1=200 px/s

G=-100/3 px/s² (about 33.3333)

But the platform behavior with those settings won't produce that result, far from it, the "Gravity" seems actually to be the "Halved gravity" (visible on blue), but for green, which has its position setted manually, no issues, why is that? Is the platform behavior wrong by saying "Gravity in pixel per seconds per seconds"?

Edit:tl;dr, I was actually wrong, I have a corrected formula in a post below to get the jump strength and gravity for a wanted height and elevation duration

Can it be it's because your blue object (the one with the platform behavior) has set it's jump strength to 200?

If you set it to 100 then it looks more realistic...

Can it be it's because your blue object (the one with the platform behavior) has set it's jump strength to 200?

If you set it to 100 then it looks more realistic...

You missed the point, the point here is that the Gravity your are setting with the platform behavior is not in pixels per seconds per seconds, but in half-pixels per seconds per seconds, which would explain why green and blue do not react in the same way with the same gravity, but will with a gravity twice as powerful for the behavior of blue compared to the manually calculated Y of green.

The point is also that gravity being incorrectly assigned as px per seconds per seconds, you cannot do the maths correctly to have the jump height you want, as well as the jump duration (which you can if the number were actually correct, which they are not in that case).

Guess you could try to implement your own version of a platform behavior.

A few tips to get your desired effect:

Don't use delta time. Your jump heights will vary because of frame rate.

Don't use pixels per second. Pixel density varies wildly over many devices.

Might want to stay away from decimals as well.....

newt I am not saying that we need another platform behavior, I am trying to understand why my results differ from the behavior when they both should work accordingly (a pixel being a relative edittime pixel at a scale of 1 (and C2 does use units in the behaviors) and a second being what the international system defines multiplied by the timescale if we wanted to go as far), however in my exemple if you set the behavior gravity to 33.3333, it is not a slight difference, the height of the jump goes over the screen, which is not a little issue.

So did I do a mistake (if so, which one), or was this unit error (gravity being halfpixel per seconds per seconds, while saying it is pixel) already there all this time, and so worth a bug report to be in the known issues?

PS: my manual curve is frame rate independent so the mistake is not this obviously, and also, I did spotted this issue before trying to do it with the green object manually, the number I used are the resukt of an exemple calculation, and it differed, so I redid it, still the same result, and then I made C2 calculate it every tick, turns out I seem to be right, thus this topic to be sure.

I may just post it in a bug report to have a definite awnser.

All Im saying is that pps is at most an approximation, and given the behaviors complexity its unlikely it will be changed.

Your formula is wrong. You have this:

Self.iniy-JumpStrengh_green*(time-Self.time)+Gravity_green*(time-Self.time)^2[/code:19hjq2f2]

You forgot the 0.5*.
[code:19hjq2f2]Self.iniy-JumpStrengh_green*(time-Self.time)+0.5*Gravity_green*(time-Self.time)^2[/code:19hjq2f2]

[code:19hjq2f2]y = y_initial + y_velocity_initial*time + 0.5*acceleration*time^2[/code:19hjq2f2]

After that it will still differ in height with the platform behavior, a little.  Yours will give the same jump height regardless of the framerate, but the platform behavior will vary a little.

This is basically how the platform behavior does the y motion:
every tick:
--- add gravity*dt to vy
--- set y to self.y + vy*dt

In order for it to be truly framerate independent it would need an extra term:
every tick:
--- add gravity*dt to vy
--- set y to self.y + vy*dt + 0.5*gravity*dt^2

It's not as simple a change as that when I looked in the platform behavior's source, but that's the general idea.

Your formula is wrong. You have this:

Self.iniy-JumpStrengh_green*(time-Self.time)+Gravity_green*(time-Self.time)^2[/code:3c9n2ul0]

You forgot the 0.5*.
[code:3c9n2ul0]Self.iniy-JumpStrengh_green*(time-Self.time)+0.5*Gravity_green*(time-Self.time)^2[/code:3c9n2ul0]

[code:3c9n2ul0]y = y_initial + y_velocity_initial*time + 0.5*acceleration*time^2[/code:3c9n2ul0]

After that it will still differ in height with the platform behavior, a little.  Yours will give the same jump height regardless of the framerate, but the platform behavior will vary a little.

This is basically how the platform behavior does the y motion:
every tick:
--- add gravity*dt to vy
--- set y to self.y + vy*dt

In order for it to be truly framerate independent it would need an extra term:
every tick:
--- add gravity*dt to vy
--- set y to self.y + vy*dt + 0.5*gravity*dt^2

It's not as simple a change as that when I looked in the platform behavior's source, but that's the general idea.

alright, I did forgot that integrating t results in 0.5t^2, and the 0.5 is not to be included in the actual acceleration.

I am derp sometimes, I can adjust a little what I have done to calculate the height of the jump.

Ok, so in the end after correcting my equations, if someone has issues with choosing the jump strength and gravity, this can help:

H is the height you want for the jump (in pixels)

T is the time to go from starting height to top height (in seconds)

You can calculate the gravity and jump strength with:

Jump strength = 2H/T

Gravity = 2H/(T^2)

(Btw, Jump strength divided by T = Gravity as you can see)

So for exemple, if you want an height of 100 pixels in 0.5 seconds of elevation time:

Jump Strength = 2*100/0.5 = 400

Gravity = 2*100/(0.5^2) = 800

That should work. Also due to the fact C2 does ticking, expect the top value to not be always reached exactly, however it is still a nice ballpark figure that should carry nicely.

I should be able to follow this - I would think...but maybe not - but I'm going to save it as a reference. Thanks Aphrodite!

Rhindon thanks, I posted it on a new topic :

Will be easier to see I think