Welcome, Guest. Please login or register.

Login with username, password and session length

 
Advanced search

1411283 Posts in 69325 Topics- by 58380 Members - Latest Member: bob1029

March 29, 2024, 06:22:01 AM

Need hosting? Check out Digital Ocean
(more details in this thread)
TIGSource ForumsDeveloperTechnical (Moderator: ThemsAllTook)Need help fixing a problem "jumping uphill"
Pages: [1]
Print
Author Topic: Need help fixing a problem "jumping uphill"  (Read 1939 times)
Uhfgood
Level 1
*


225 lbs of awesome!


View Profile WWW
« on: January 09, 2013, 12:32:15 PM »

My name is Keith, and I've probably posted on these forums maybe a few times at most.  I was working on an adventure game, but that got tabled for the time being.

Currently I'm going to make a Sonic The Hedgehog styled platformer called Flash Fox.  The reason I mentioned "going to" is because I'm working on implementing slopes (using LÖVE). It works to a point, let me explain -- 

The collision seems to work great, and you can move at high speed without tunneling through the tiles.

I have acceleration and deceleration working and if you're jumping from a near-to-complete stop it will jump in an arc away from the slope angle, that is, that it uses the normal of the slope in order to jump in the opposite direction.

So the problem is, that I can't jump up when traveling quickly uphill.  This is for at least 3 reasons:
1) Gravity is always pulling it down
2) In order to stay on the slope at all when moving horizontally I have to set the y position (the floor position) based on how far into the tile the sprite is intersecting
3) moving uphill cancels out the jumping velocity somehow.

So here I will show you a video (please click on the image).  Look at the first 4 seconds of the clip as these show me trying to jump while moving up hill.




Here's the actual project with the source code, which since love2d is lua, the source is in lua.

SSE03.zip

Please note, if you unzip this, you need to unzip it into a folder, and if you have love2d, you can simply rename the zip file to .love and run it directly in love2d.

pay attention to player.lua mostly as that has the collision/slope code.  The function DoJump and UpdateHorz/UpdateVert functions are the main functions that move the sprite.

So a quick recap I want to be able to jump up even when moving uphill at a quick pace.

Any help  you could give would be appreciated.
Logged

cplhasse
Level 1
*


View Profile
« Reply #1 on: January 09, 2013, 02:43:55 PM »

Can't look at the code right now sorry (not at home) but is it possible that this is happening:

1. You process input and, detect a jump input and set new player x- and y-velocity
2. Player is still moving with a positive x-velocity which gives a collision with the slope
3. Collision handling for the slope intersection resets the player's speed
Logged
Uhfgood
Level 1
*


225 lbs of awesome!


View Profile WWW
« Reply #2 on: January 09, 2013, 09:23:57 PM »

Can't look at the code right now sorry (not at home) but is it possible that this is happening:

1. You process input and, detect a jump input and set new player x- and y-velocity
2. Player is still moving with a positive x-velocity which gives a collision with the slope
3. Collision handling for the slope intersection resets the player's speed

I believe this is exactly what is happening.  In fact I set the x velocity depending on what key you press instead of adding to it.  (If I add/subtract the speed to/from the current velocity my deceleration stuff doesn't work.)  However this still doesn't help the y velocity which has to interact with gravity... But thanks for giving a suggestion
Logged

wcyou
Level 0
**


View Profile WWW
« Reply #3 on: January 09, 2013, 10:04:45 PM »

#1 There could be no problem at all
Try to increase your jumping speed and jump height, from the looks of it it seems like you jump slow and low, it could be that it's already jumping but you are moving upward so quickly that you can't notice the difference.


If there really is some problems..

Are you writing on top of another engine and am unsure what is going on underneath?

#2 Easilest Solution
If that is the case, my best suggestion would be to implement a slight hack, manually teleport the player slightly upward so that the speed would not be reseted.

#3 Solution
Manually Override the engine's collision response to fit your need.
Logged
nom
TIGBaby
*


View Profile
« Reply #4 on: January 10, 2013, 02:25:22 AM »

Maybe try disabling gravity for the player the instant they jump, then quickly fade the gravity back in so to speak.
Logged
Gregg Williams
Level 10
*****


Retromite code daemon


View Profile WWW
« Reply #5 on: January 10, 2013, 04:18:51 AM »

How sonic handles this, is it only checks for a ground collision if the velocity is > 0, there fore jumping results in the ground collisions being ignored, but sideways and ceiling collisions still being checked.
Logged

Uhfgood
Level 1
*


225 lbs of awesome!


View Profile WWW
« Reply #6 on: January 10, 2013, 02:44:20 PM »

How sonic handles this, is it only checks for a ground collision if the velocity is > 0, there fore jumping results in the ground collisions being ignored, but sideways and ceiling collisions still being checked.

This is also what I do.  There are several other things working against it.  One is setting the y position with a left/right slope collision, but even with that taken away, there's gravity and gravity pushes it down... so in essence I don't have enough jump force to break away from gravity.  Also the slope normal, if it's a steep slope the y velocity is going to be smaller.  I'm not really sure how Sonic actually handles that though.
Logged

Gregg Williams
Level 10
*****


Retromite code daemon


View Profile WWW
« Reply #7 on: January 10, 2013, 04:11:01 PM »

How sonic handles this, is it only checks for a ground collision if the velocity is > 0, there fore jumping results in the ground collisions being ignored, but sideways and ceiling collisions still being checked.

This is also what I do.  There are several other things working against it.  One is setting the y position with a left/right slope collision, but even with that taken away, there's gravity and gravity pushes it down... so in essence I don't have enough jump force to break away from gravity.  Also the slope normal, if it's a steep slope the y velocity is going to be smaller.  I'm not really sure how Sonic actually handles that though.

http://info.sonicretro.org/Sonic_Physics_Guide

Thats how Sonic handles things =)

Logged

Uhfgood
Level 1
*


225 lbs of awesome!


View Profile WWW
« Reply #8 on: January 10, 2013, 10:05:52 PM »

How sonic handles this, is it only checks for a ground collision if the velocity is > 0, there fore jumping results in the ground collisions being ignored, but sideways and ceiling collisions still being checked.

This is also what I do.  There are several other things working against it.  One is setting the y position with a left/right slope collision, but even with that taken away, there's gravity and gravity pushes it down... so in essence I don't have enough jump force to break away from gravity.  Also the slope normal, if it's a steep slope the y velocity is going to be smaller.  I'm not really sure how Sonic actually handles that though.

http://info.sonicretro.org/Sonic_Physics_Guide

Thats how Sonic handles things =)



::SIGH::

I've read through this several times.  It doesn't really put it in layman's terms and each part is sort of it's own thing, doesn't really tell you how it ties into the whole.

I should have mentioned I've already read it, as I believe I did in the Love2d forums in any case the physics guide isn't of much practical use to me.
Logged

Gregg Williams
Level 10
*****


Retromite code daemon


View Profile WWW
« Reply #9 on: January 10, 2013, 10:36:55 PM »

::SIGH::

I've read through this several times.  It doesn't really put it in layman's terms and each part is sort of it's own thing, doesn't really tell you how it ties into the whole.

I should have mentioned I've already read it, as I believe I did in the Love2d forums in any case the physics guide isn't of much practical use to me.
It seems fairly clear to me, but then I've always done platformers using a similar approach with height maps for slopes and uneven terrain. Although I haven't ever gone to the sonic extremes with slopes, and as such haven't ever needed to mess with angles.

Anyways it seems like your problem is two fold, one being lack of initial jump velocity. For instance sonic sets an initial Y velocity of -6.5, while gravity is only around 0.2 per frame.

The second I would guess is really about the whole "angle" factor, in sonic if your running up a steep hill and jump you'll actually go backwards or at an angle, and this is why each tile has an associated angle to it, and when jumping the horizontal and vertical velocities are computed based upon the angle with trig.
Logged

Aelexe
Level 0
**

Out of Phase


View Profile
« Reply #10 on: January 11, 2013, 12:52:29 AM »

http://info.sonicretro.org/Sonic_Physics_Guide

Thats how Sonic handles things =)

What a glorious read.
Logged
Uhfgood
Level 1
*


225 lbs of awesome!


View Profile WWW
« Reply #11 on: January 11, 2013, 12:31:10 PM »

It seems fairly clear to me, but then I've always done platformers using a similar approach with height maps for slopes and uneven terrain. Although I haven't ever gone to the sonic extremes with slopes, and as such haven't ever needed to mess with angles.

Anyways it seems like your problem is two fold, one being lack of initial jump velocity. For instance sonic sets an initial Y velocity of -6.5, while gravity is only around 0.2 per frame.

The second I would guess is really about the whole "angle" factor, in sonic if your running up a steep hill and jump you'll actually go backwards or at an angle, and this is why each tile has an associated angle to it, and when jumping the horizontal and vertical velocities are computed based upon the angle with trig.

I am using height maps for my slope tiles.

gravity needs to make sense to you... in other words I have a gravity value of 1500 before multiplying it by time... setting "0.2" for me would be useless, so to say that sonic moves 0.2 for gravity doesn't really mean much to me.

The way I have the code, I can't do an initial y velocity.  I do some timing with keypress to give you a variable height jump. 

I do actually jump off the normal of the slope (for instance 45 degree slope has a normal of 135 degrees) -- I pre-calced the normals and stored them in the tile data. 

So basically you do go backwards if you're at a near standstill or going down hill.  If sonic is moving uphill it still affects him but he's still able to move forward.

I decided to increase the y jump velocity by a certain amount depending on what slope they're on.  It seems to work alright although I don't know if other people would think it feels right.
Logged

Gregg Williams
Level 10
*****


Retromite code daemon


View Profile WWW
« Reply #12 on: January 11, 2013, 12:49:33 PM »

gravity needs to make sense to you... in other words I have a gravity value of 1500 before multiplying it by time... setting "0.2" for me would be useless, so to say that sonic moves 0.2 for gravity doesn't really mean much to me.
Just my personal opinion, but I would never use time/elapsed time frame rate calculations for a platformer. The timing variations can cause differences in things such as maximum jump height and distance, which can impact platforming capability if you have really pixel perfect jumps and so forth.

Sonic runs in frame time, usually this would be 60 frames per second. So gravity in that case is +0.2 per frame, while velocity starts at -6.5 per frame.

You can also still achieve variable jump height while setting an initial Y velocity during a jump. You simply adjust the current Y velocity if the player lets go of the jump key the next frame for instance.

Anyways it sounds like you have something working. Good luck.
Logged

Uhfgood
Level 1
*


225 lbs of awesome!


View Profile WWW
« Reply #13 on: January 11, 2013, 01:55:23 PM »

I'm using a fixed timestep -- should work the same on most systems -- I am/was using delta time because I was using it already.  The timestep that's passed in is 1/60 -- and it works

Also I am posting a new zip which is closer to get it working
SS03v2.zip

rename from .zip to .love to run it in love.  or just unzip it to an existing folder and run it like you would any other love file.
« Last Edit: January 11, 2013, 02:54:54 PM by Uhfgood » Logged

qMopey
Level 6
*


View Profile WWW
« Reply #14 on: October 31, 2017, 11:14:52 AM »

Can't really tell what the expected behavior is. Do you have a reference video of a Sonic game that achieves what you're attempting? Just watching the video you posted is not nearly enough info for me to help you.

As of now there are a couple possibilities:
  • You implement a jump by setting velocity or applying a force -- this will cause your player to integrate upwards at the same instant as the player's running velocity is integrated. The effect would be for your small jump impulse/force to be completely drowned out by the significantly larger current upward velocity from running, as well as any height adjustments coming from collision detection.
  • You have a bug in your collision detection causing unwanted behavior (highly likely).

Assuming you don't have any unwanted bugs regarding collision resolution behavior, then your problem is probably the first bullet point. I recall Sonic 2 would solve this "problem" by applying a jump along the surface normal. This prevents the dot product of the jump direction and the current velocity (slope) from vanishing.

If you want to keep a constant up normal pointing straight up on the screen no matter what, you will likely have to scale your jump displacement proportional to the dot product of the slope and the up axis. In this case you will get behavior such that if someone jumps upwards at the end of a slope they will have a huge artificial jump height. This will probably be unanticipated as far as level design goes.

Edit: whoops realized this thread is old, and that looks like a spambot necro... Oh well.
« Last Edit: October 31, 2017, 01:02:12 PM by qMopey » Logged
Pages: [1]
Print
Jump to:  

Theme orange-lt created by panic