I''ve done a method similar to those above. What I do is try a move in the players direction of movement. If this fails, I move him back to where he came from. Each frame I try a translation in the direction of gravity, and the players movement (walking left). If that causes a collision, I move him back.

Example:
player is at coords (30, 30)
gravity wants him to move down 3, and he''s pushing left, which means he''ll try to move 2 left.
So, I test a collision at (28, 33). If this fails I move him back.

Now, this in itself doesn''t get you ideal behavior. In the very common case that he''s on the ground, any attempt to move him left will be cancelled out by gravity trying to push him into the ground. (a collision would happen every frame). How I solve this is by breaking up the left/right collision tests with the up/down collision tests.

IE, check all the up/down collisions first, then check the left/right movement. The best way is to interleave between the 2. Check 1 pixel down, then 1 pixel over, then 1 pixel down, etc.. each frame. Also, checking 3 pixels at a time and failing will not allow your player to become flush with the ground or walls. Checking 1 pixel at a time will solve this as well.

It''s simple in concept, but I''m doing a horrible job of explaining it. If you''re interested, and totally lost by my explaination, I''ll give it another go.

I my little rpg I''m currently working on, I did a similiar thing. I know it''s not completely like this, but it''s a top down rpg (like the classic zelda games, I love em btw ), and the player is also able to move in the same 4 directions. The collision detection is also somewhat faster (well should be), but I didn''t notice any difference, even on my 120mhz pentium pc. Anyway, it works like this:

For example, you have tiles that are 16x16 and the player is moving, say 40 pixels per frame (yeah I know it''s an extreme case, but this sometimes occured due to these sort of "drop-outs" of my pc). You could make 50 collision checks, moving the player one pixel per check, but the tiles are 16x16, so once of checked one row of pixels of one tile, you also know that the other 15 rows will not be colliding with the player either. So I coded a loop with only 2 or 3 collision checks in this case (the number depends on where you are inside the tile, on what pixel. 40 / 16 = 2.5, so if the player would be moving right and the rightmost side of him is on the 8th pixel, 3 checks would be needed: if the rightmost side would''ve been on the 7th pixel, only 2 checks would be needed).

However, this can only be used in a tile-based game, with fixed tile sizes, and like I said there is almost no significant speed difference, but I like to optimize these sort of routines (and after I coded it I was really happy it worked!). Anyways, hopefully this is useful to someone else .

Nick

to prove my method of collision handling, i present a little demo which you can get here.

the controls are w/a/s/d to move around and mouse horizontal movement for looking around.

note that it''s a top-down view demo, so there isn''t any gravity. and it''s not a tile based system, thus making it more advanced. yet, it still is a good representation of this method''s capabilites.

---
shurcool
wwdev

shurcool, nobody questioned your collision detection or method being good or not. its just not the best way for a beginner to deal with gravity. unless Amythius can understand the fundamentals of a simple system he cant begin to grasp a concpet one. its like trying to running before learning to walk. sure you can kinda hobble along, but you will fall a lot and have problems. if you know how to walk, you can much easier apply the newer concpets since they build on the old ones.

if you constantly add gravity, you would have to add another force. you left this out of your explaination. basically you were suggesting adding bouncyness (something he could have figured on his own by playing with the speed at collision himslef) and ignored explaining that while on the ground the gravity exerted is cancled by the force of the ground pushing on you and the force you exert on the ground.

plus he is only wanting physics that handling jumping and gravity. not collisions with things. it is assumed he has that working. i kow your proud of your method, but unfortunatly its prbably too advanced for someone still grasping how to handle jumping.

a more complex collision responese systems dont use per piexl checks against the tiles. instead you use line segments which if they intersect will mean a collision occers.

[edited by - a person on July 14, 2002 12:04:29 AM]

quote:

---

Original post by a person
shurcool, nobody questioned your collision detection or method being good or not. its just not the best way for a beginner to deal with gravity. unless Amythius can understand the fundamentals of a simple system he cant begin to grasp a concpet one. its like trying to running before learning to walk. sure you can kinda hobble along, but you will fall a lot and have problems. if you know how to walk, you can much easier apply the newer concpets since they build on the old ones.

---

well, he never said that he was new or that he's looking for a very simple way to do it.

quote:

---

Original post by a person
if you constantly add gravity, you would have to add another force. you left this out of your explaination. basically you were suggesting adding bouncyness (something he could have figured on his own by playing with the speed at collision himslef) and ignored explaining that while on the ground the gravity exerted is cancled by the force of the ground pushing on you and the force you exert on the ground.

---

i think i already covered that in one of my replies. but if your physics updates are done frequent enough, and your BOUNCINESS_TRESHOLD is high enough, the gravity will automaticall be canceled out, without any unnecessary bouncing. if you were not to add gravity when you're on the ground, which works really well in this tile-based game, it wouldn't in a non-tile-based one. both methods work, so use either one.

quote:

---

Original post by a person
plus he is only wanting physics that handling jumping and gravity. not collisions with things. it is assumed he has that working. i kow your proud of your method, but unfortunatly its prbably too advanced for someone still grasping how to handle jumping.

---

once again, i did not know his skill level. :-/

quote:

---

Original post by a person
a more complex collision responese systems dont use per piexl checks against the tiles. instead you use line segments which if they intersect will mean a collision occers.

---

what are you talking about? something nickm said? because my method does not use any pixel checks... :-/

so a lesson for you all (especially Amythius), when you need help on something indicate your skill level, or the complexity of the solution that you're looking for. that way you won't get solution too simple, or too advanced, neither will you waste anybody's time for nothing.

ps. a person, what do you think of my reply to your reply to my server-side pred post?

---
shurcool
wwdev

[edited by - shurcool on July 15, 2002 9:38:25 AM]

[edited by - shurcool on July 15, 2002 7:09:25 PM]

Well, guys I got gravity adding to the negative every game loop. I have my sprite just move up X amount of pixels when the jump button is pressed. I have it done, but.. I just can''t limit the amount of keys he can hit. Any ideas guys?
My pseudo code as is:
mainLoop()
{
...
if(jump_key == hit)
{
Player.yadd(-20); /* SDL uses a mapping system in which the origin is in the top left*/
if(Player.gety()<0) Player.yset(0);
}
Player.yadd(2);
if(Player.gety()<0) Player.yset(0);
..
}


I just need to limit his jump to a realistic one time jump. Any ideas? I know I should repost in a new topic, but why not while you''re all already looking here.

For simplicity, I usually have a boolean for each player that is TRUE if the player is on the ground, and FALSE otherwise. Set it to TRUE when they''re under the effects of gravity, and FALSE when he''s not (when he hits the ground). Then, only if this value is TRUE do you let the player jump. This is assuming you don''t want anything wacky like a double-jump.
For setting the varible, your code becomes

if(Player.gety()<0){    Player.yset(0);    Player.bOnGround = TRUE;}else{    Player.bOnGround = FALSE;} 

Oh man, simple enough. I musta been tired. I have an idea now, once he collides on top of a tile I will allow him to jump again. For any type of jump, as long as he rests on something. Thanks a lot.