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.

My guess is to contact the support, and explain them the situation (with a link to this topic too, to explain the situation) and see that with them directly.

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.

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.

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).

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

KZR

raster

I think he posted it as an attachement (and they are currently broken), I know he posted it somewhere else, but I think the other place is also as an attachement (and so requires an account), I will try to place a message somewhere so he knows the link is not availiable Anymore.

And also because they (scirra) choose to.

I know it is a stupid answer, but it is their choice in the end and I do not know the rest (nor have to) since it is not my business.

I tried it, it works!

The controls are easy to understand, but the game is still tricky (which is fine), however, I had some bugs, like a jump thru moving platform that made me elevate inside it, and if you are in mid air and did not jump yet, you can jump by pressing left and right.

i think you can use this :

width : ViewportLeft()+ ViewportRight()

height : ViewportBottom() + ViewportTop()

More like ViewportRight()-ViewportLeft()

ViewportBottom()-ViewportTop()

(With the layer as a parameter)

gamesura

Everywhere I tested it, apart from one single laptop, the canvas was hardware accelerated, not necessarily WebGL compatible, but still hardware accelerated.

C2 will not update the display if nothing changes (so indeed, your static objects would work fine), also, 60 fps is not C2 standard, the number of fps depends on the refresh rate of the device reported by the browser.

For dynamic, you could do just fine with reauesting external files technically, but this is another matter.

The real issue is simply to keep it light and easy for the user, and doing this with html+CSS is far easier and is designed for it.

"We support Ludei's Webview-based platforms via the Cordova exporter (they are cordova-compatible). "

Pretty sure it meant you could use the cordova exporter with their cloud based compilation for webview and webview+.

netsmartcentral