stupid jumping question

[+atari2600land]

I'm making a platform game and the guy needs to jump. Here's what I have so far:

 

130 if joy0fire then c{1}=1
 if c{1} then timer=timer+1 : y=y-1
 if timer=20 && c{1} then c{1}=0 : c{2}=1 : timer=0
135 if c{2} then y=y+1
 if collision(player0,playfield) then y=y-2 : c{2}=0

 

Now, all I have to do is make the guy go down even if the fire button is pressed. Any suggestions?

[Dragnerok X]

I'm making a platform game and the guy needs to jump. Here's what I have so far:

 

130 if joy0fire then c{1}=1
 if c{1} then timer=timer+1 : y=y-1
 if timer=20 && c{1} then c{1}=0 : c{2}=1 : timer=0
135 if c{2} then y=y+1
 if collision(player0,playfield) then y=y-2 : c{2}=0

 

Now, all I have to do is make the guy go down even if the fire button is pressed. Any suggestions?

 

Probably the easiest way I can think of would be to take a variable, j for example, and turn it on everytime you press the button. While j is on, ignore whatever lines are screwing your code up.

Once you finally reach the end of your routine (i.e. the guy touches the ground) then just set it back to 0 and you'll be good.

 

Example:

j = 0 : rem place this before your "main" loop, when you turn your program on and define all the variables. This keeps it from skiping the variable-check altogether.
130 if j = 0 && joy0fire then c{1}=1 : j = 1
 if c{1} then timer=timer+1 : y=y-1
 if timer=20 && c{1} then c{1}=0 : c{2}=1 : timer=0
135 if c{2} then y=y+1
 if collision(player0,playfield) then y=y-2 : c{2}=0 : j = 0

 

You probably get the idea.

 

P.S. - If the Y variable is being used like I think it is, it would be way more efficient (both ram and rom wise) just to use player0y instead. It should function exactly the same, along with saving you precious variables.

Edited January 21, 2007 by Dragnerok X

[Dragnerok X]

So, did it work?

[SeaGtGruff]

I'm making a platform game and the guy needs to jump. Here's what I have so far:

 

130 if joy0fire then c{1}=1
 if c{1} then timer=timer+1 : y=y-1
 if timer=20 && c{1} then c{1}=0 : c{2}=1 : timer=0
135 if c{2} then y=y+1
 if collision(player0,playfield) then y=y-2 : c{2}=0

 

Now, all I have to do is make the guy go down even if the fire button is pressed. Any suggestions?

As I understand it, you're using two flags for jumping-- c{1} to indicate whether the guy is jumping and is on his way up, and c{2} to indicate whether he's jumping and is on his way down, as follows:

 

If c{1} is 0 and c{2} is 0, it means he isn't jumping right now.

If c{1} is 1 and c{2} is 0, it means he's jumping and is on his way up.

If c{1} is 0 and c{2} is 1, it means he's jumping and is on his way down.

 

If you press the fire button while he isn't jumping, everything's fine, because you set c{1} to 1 to indicate that now he's jumping and is on his way up, you decrement y so he goes up into the air, and you increment the timer which counts how many frames he goes up into the air before he starts to fall back down.

 

If you press the fire button while he's already jumping, and is on his way up, then everything's still fine, because all you do is set c{1} to 1, even though c{1} is already set to 1, so no harm is done.

 

*But*, if you press the fire button while he's already jumping, and is on his way *down*, then you've got a problem, because c{1} is set to 0 and c{2} is set to 1, but now you're setting c{1} to 1 (since the fire button was just pressed), and thus you end up with the following:

 

If c{1} is 1 and c{2} is 1, it means he's jumping and was on his way down, but suddenly decided to use his amazing psychokinetic levitational ability to float for a third of a second (because once the timer counts up to 20, he'll start to fall again). And as long as you keep pressing the fire button, he'll keep floating. The reason he floats, rather than rising even higher, is because c{1} and c{2} are both set to 1, so first you decrement y, and then you increment y, such that y ends up having the same value that it did before.

 

Consequently, you could fix your existing code by modifying the "if" in line 130, as follows:

 

130 if joy0fire && !c{2} then c{1}=1 : rem * added "&& !c{2}"

However, that still doesn't fix all of your problems. For example, if he's on a platform and steps off into thin air (without jumping), he'll just float in the air, because c{1} and c{2} will both be 0. So you could fix that by adding another line before line 130, as follows:

 

129 if !collision(player0,playfield) && !c{1} then c{2}=1

This will cause him to fall if he isn't standing on a platform-- but only if he isn't in the process of jumping up into the air.

 

However, this new line doesn't sit well with the last line of code you posted (i.e., the unnumbered line after line 135), because the two of them together-- along with line 135-- cause the man to shake or vibrate up and down very rapidly, and also prevent him from being able to jump anymore. So you could fix that by taking "y=y-2" out of that last line, as follows:

 

 if collision(player0,playfield) then c{2}=0

So the final code looks like this:

 

129 if !collision(player0,playfield) && !c{1} then c{2}=1
130 if joy0fire && !c{2} then c{1}=1
 if c{1} then timer=timer+1 : y=y-1
 if timer=20 && c{1} then c{1}=0 : c{2}=1 : timer=0
135 if c{2} then y=y+1
 if collision(player0,playfield) then c{2}=0

That actually works pretty good, but the jumping motion doesn't look very natural. In actual jumping motion, the man would rise up into the air rather rapidly at first, and then immediately start to slow down. And after he slowed to a stop, he would start to fall slowly, but would immediately start to speed up. The best way to do something like that is with a 4.4 fixed-point "momentum" variable, or whatever you want to call it. And you would use an 8.8 fixed-point variable for the y position. I'm attaching two programs-- the first one (jump.bas) uses your original method, with the changes I've suggested above; and the second one (jumping.bas) uses 4.4 and 8.8 fixed-point variables. I tried to add a few additional checks: If the man hits a platform while he's jumping upward, then he hurts himself (the sprite changes, and it's supposed to look like he just bashed his head), which stops him from rising any higher, and he starts to fall (but if he's still touching the playfield after he starts to fall, then he'll cling to it). And if he falls from too great a height (as indicated by hitting the ground with a negative momentum exceeding -4.0), then he crashes into the ground (the sprite changes to an upside-down version of him hitting his head). It's far from perfect, but it may give you ideas, and hopefully other people will contribute comments. Note that this topic was dicussed before when you were thinking about a "Mr. Flanksteak" game (if I remember correctly), so you might want to read through those old posts.

 

Michael

jump.bas

jump.bas.bin

jumping.bas

jumping.bas.bin

[+atari2600land]

I'm back. Read my blog for a brief explanation of where I've been.

[+atari2600land]

New direction: instead of a guy, it's a frog. This all came about due to a bug, but it works if it's a frog, because I made it that once you land on the ground, you're stuck. I did this on accident and then thought about those levels in Donkey Kong Country 2 where you're in the beehive and get stuck in honey. Then I thought "frogs can hop!" And that's when the big lightbulb came on. It'll be like Pitfall, or Super Maria Sisters. This'll be my next game once GoSub is complete.

[jrok]

That actually works pretty good, but the jumping motion doesn't look very natural. In actual jumping motion, the man would rise up into the air rather rapidly at first, and then immediately start to slow down. And after he slowed to a stop, he would start to fall slowly, but would immediately start to speed up. The best way to do something like that is with a 4.4 fixed-point "momentum" variable, or whatever you want to call it. And you would use an 8.8 fixed-point variable for the y position. I'm attaching two programs-- the first one (jump.bas) uses your original method, with the changes I've suggested above; and the second one (jumping.bas) uses 4.4 and 8.8 fixed-point variables. I tried to add a few additional checks: If the man hits a platform while he's jumping upward, then he hurts himself (the sprite changes, and it's supposed to look like he just bashed his head), which stops him from rising any higher, and he starts to fall (but if he's still touching the playfield after he starts to fall, then he'll cling to it). And if he falls from too great a height (as indicated by hitting the ground with a negative momentum exceeding -4.0), then he crashes into the ground (the sprite changes to an upside-down version of him hitting his head). It's far from perfect, but it may give you ideas, and hopefully other people will contribute comments. Note that this topic was dicussed before when you were thinking about a "Mr. Flanksteak" game (if I remember correctly), so you might want to read through those old posts.

 

Michael

 

Thanks for the great fixed-point physics example, Michael.

 

My problem is, I need to register my sprite's collision against whole integer values that I'm pulling out of a data array. So far I feel like I've been banging my head against a wall trying to figure it out. I attached an example of a modified script that tests whether the player's y intersects with one of three shapeflags using your momentum method. Jumping around this playfield gives various results. Sometimes, everything's fine, while other times the sprite falls straight through the floor.

 

I assume this is becuase if the jumper's downward accelaration ever exceeds "1" it will likely skip the y value of the ground. Or is it becuase of the way fixed-point numbers compare to whole numbers? I've tried a number of remedies, but so far no dice. I hope this post makes some sort of sense, and that you can help out.

 

Cheers,

Jarod.

jumping_var.bas

jumping_var.bas.bin

[SeaGtGruff]

Thanks for the great fixed-point physics example, Michael.

Thanks for the thanks, especially since physics was never my strong point!

 

My problem is, I need to register my sprite's collision against whole integer values that I'm pulling out of a data array. So far I feel like I've been banging my head against a wall trying to figure it out. I attached an example of a modified script that tests whether the player's y intersects with one of three shapeflags using your momentum method. Jumping around this playfield gives various results. Sometimes, everything's fine, while other times the sprite falls straight through the floor.

 

I assume this is becuase if the jumper's downward accelaration ever exceeds "1" it will likely skip the y value of the ground. Or is it becuase of the way fixed-point numbers compare to whole numbers? I've tried a number of remedies, but so far no dice. I hope this post makes some sort of sense, and that you can help out.

 

Cheers,

Jarod.

Maybe you should put a cap on the acceleration? That way the man will never fall too fast. Here's an example-- a=240 was the "fastest" value that didn't result in the man falling through the playfield.

 

Michael

jumping_var_1.bas

jumping_var_1.bas.bin

[jrok]

Maybe you should put a cap on the acceleration? That way the man will never fall too fast. Here's an example-- a=240 was the "fastest" value that didn't result in the man falling through the playfield.

 

Michael

 

if a > 64 then if a < 240 then a = 240

 

Genius! You solved it with a single line!

 

You know, I was trying to do the something similar (cap the downward accelaration ), but I was trying to do it with an && operation, which thanks to your fix I now realize I've been grossly overusing. I also think I'm not quite "getting" negative numbers. In the above line, would 240 mean -24?

 

Anyway thanks again. This really helped a lot.

Edited September 30, 2008 by jrok

[SeaGtGruff]

I also think I'm not quite "getting" negative numbers. In the above line, would 240 mean -24?

Most all variables in bB are 1-byte unsigned integers, so they have values from 0 to 255. However, you can consider the value to be negative if bit 7 is set to 1-- i.e., if the number is 128 to 255. In that case, the negative value is 256 minus the absolute value of the number, so -1 would be 256 - 1 = 255. In other words, x = x + 255 would give you the same result as x = x - 1. For a 4.4 fixed-point number, the upper 4 bits (hi nybble) are the integer portion, and the lower 4 bits (lo nybble) are the fractional portion, so that kind of complicates things a bit when dealing with negatives. I'm on my lunch hour right now and must head back to the office, so I can't explain further at the moment, but I'll post more tonight.

 

Michael

[jrok]

I noticed there seems to be some sort of problem with using fixed point math and batari bankswitching. When you include either bankswitch.inc (or the supercharger version), DASM fails on the following for fixed-point subtractions:

 

Sub44from88			  0000 ????		 (R )
bs_mask				  0000 ????		 (R )

 

...and the following for fixed-point additions:

 

Add44fto88			  0000 ????		 (R )
bs_mask				  0000 ????		 (R )

 

Does anyone know what these errors mean, and if there is any way around them?

 

Thanks,

Jarod.

jumping_bs.bas