Jump Height Unstable

[59 Byte]

In my game, the square shaped player must jump through tight holes in incoming pillars. to ensure that it looks visually correct I have defined the jump height with the following line:

Code: Select all

JUMP_VEL = math.sqrt(GRAVITY*JUMP_HEIGHT/0.5)

My update function looks something like this:

Code: Select all

if player.inair then
	player.yv = poly.yv+GRAVITY*dt
	if player.y+player.yv*dt > GROUND then
		player.inair = false
		player.y = GROUND
		player.yv = 0
	end
end
player.y = player.y+player.yv*dt

This function executes when space is pressed:

Code: Select all

function eventJump()
	if poly.inair then return end
	poly.yv = -JUMP_VEL
	poly.inair = true
end

The problem is that when observing this in action, the player fails to reach the desired height, and not only that, it also jumps a slightly different height each time. I've tried correcting the height once it reaches its peak height, but it looks jerky and ew. I have no clue what's going on, and it's important to me that everything looks smooth and perfect. So if someone could tell me what's up that would be great, thanks in advance.

[MrFariator]

A shot in the dark, but does your delta time vary (wildly) between frames? Since you do not seem to be doing any checks in regards to tunneling (ie. check for collisions between the start and end positions) in the code you provided, or how you're checking horizontal movement for that matter, it could be that depending on your delta time the apex of player's jump can have different results.

Quick method would be to lock your frame rate to a fixed value to provide a stable delta time (perhaps by using tick). There's a thread for fixed time steps that you could check, too. Then there's this one article everyone posts everywhere.

Of course, I'd have to see the rest of the code (particularly the love.run you're using) to know the proper answer.

[59 Byte]

There's no collision detection (except with the ground), or horizontal movement. I'm using the default love.run. I don't know about how varied my dt is.

[MrFariator]

So in that case my assumption is probably/maybe/perhaps correct. What is essentially happening is that multiplication with your dt between frames do not necessarily add up to such values that your player character would perfectly end up at the apex of their jump (ie. when player.yv+GRAVITY*dt equals to 0 while in mid-air after a jump). Maybe consider a scenario where "normally" under ideal circumstances multiplication with your delta time applies 2 units of acceleration to gravity each frame, but just for one frame it actually equals to 4 (delta time is larger than the prior frames). The result would visually look like as though the character didn't reach the jump's apex if that's where that skip occurred.

You'd need some sort of interpolation, tunneling or just fix your time step to make it behave and look consistent. I'm no expert on this subject, so someone else should be able to provide a better answer, but as I said before a quick fix could be the tick library I mentioned in my earlier post. It wouldn't require any other changes than just loading it in love.load/main.lua on your part and observe if your jump behavior is consistent after that.

As a side note, I also realized that you are multiplying with dt twice (when assigning to player.y and applying gravity to player.yv), which could just double up on the variance between updates.

[ivan]

The formula that I use is:

Code: Select all

initJumpVelocity = math.sqrt(2*g*jumpHeight)

Same as yours just without the division.

The problem is that when observing this in action, the player fails to reach the desired height, and not only that, it also jumps a slightly different height each time

dt varies between steps so the apex of a jump could happen "between" frames.
You can look into "fixed" time steps if you want a more consistent-looking jump behavior.

[kikito]

I'm just going to leave this here in case it helps: http://openarena.ws/board/index.php?topic=5100.0

[airstruck]

player.yv = poly.yv+GRAVITY*dt

Is that a typo? Looks like maybe poly.yv was supposed to be player.yv?

[59 Byte]

player.yv = poly.yv+GRAVITY*dt

Is that a typo? Looks like maybe poly.yv was supposed to be player.yv?

Lol, yeah. In the actual program everything that says "player" is actually "poly". I changed the code in the post to be clear on what was the object was, but it looks like I missed a few.

[59 Byte]

I'm just going to leave this here in case it helps: http://openarena.ws/board/index.php?topic=5100.0

Right after implementing this in the game, everything worked perfectly! Thanks everyone!