The perfect fall/jump

The place for codemasters or beginners to talk about programming any language for the Spectrum.
Post Reply
User avatar
R-Tape
Site Admin
Posts: 6353
Joined: Thu Nov 09, 2017 11:46 am

The perfect fall/jump

Post by R-Tape »

Image

If we assume single pixel movement being possible at 50 fps, is there a perfect fall (and jump) table?

I guess "perfect" could mean that it obeys the laws of physics, or it looks just right. I'm more interesting in the latter, but maybe they are the same? I tried looking at the rate of acceleration due to gravity, but got frightfully confused. In my previous games, I just doubled the distance every 4 mainloops and it looks fine to me, but I'm interested to see if it can be improved on.

For example the AGD fall table goes like this:

Image

1,1,1,2,2,4,6,8,8 (pixels per loop). It's good, but presumably restricts to a max of 8 because that's the block size, and as a result the sprite appears too slow at full velocity.
User avatar
Ast A. Moore
Rick Dangerous
Posts: 2640
Joined: Mon Nov 13, 2017 3:16 pm

Re: The perfect fall/jump

Post by Ast A. Moore »

In Yankee, I use simple math for the bomb’s x and y coordinates. The x being the copter’s inertia and the y, obviously, being the drop acceleration (well, the copter’s inertia is added to the y coordinate of the bomb, too, actually). I don’t know if it looks realistic, but it just feels right at 50 fps for a game. Sometimes, realism doesn’t look real in a video game, strangely enough.

I use a 16-bit multiplier that increments gradually each iteration. It is then added to the vertical coordinate, which is also 16 bits wide, but only the high byte is used for the actual drawing position.

If the mechanics of Yankee look satisfactory to you, I can dig out that portion of the code from the source for you.
Last edited by Ast A. Moore on Sat Jun 08, 2019 10:45 pm, edited 1 time in total.
Every man should plant a tree, build a house, and write a ZX Spectrum game.

Author of A Yankee in Iraq, a 50 fps shoot-’em-up—the first game to utilize the floating bus on the +2A/+3,
and zasm Z80 Assembler syntax highlighter.
User avatar
PROSM
Manic Miner
Posts: 472
Joined: Fri Nov 17, 2017 7:18 pm
Location: Sunderland, England
Contact:

Re: The perfect fall/jump

Post by PROSM »

If we were to use the laws of physics, we would probably eschew a jump table. Instead, we would give the sprite an initial vertical velocity (henceforth known as u). At any instant in time during the jump, the velocity of the sprite can be calculated as

Code: Select all

v = u + at
where v is the velocity at time t, t is the current time in seconds and a is the acceleration (on Earth, the acceleration due to gravity is 9.8 metres per second, but we make it negative of course since we're going down).

Essentially, when the player jumps, you want to set delta-y (the change in y) to a starting value, and every frame, subtract your acceleration from delta-y, then add delta-y to the y coord of the sprite. To simulate terminal velocity (and more importantly, prevent overflow :mrgreen: ), you'll probably want to cap delta-y at a certain value.

For added precision, you may choose to use fixed-point coordinates, by storing them as 16-bit values (the upper 8 bits being the integer part, which you use for plotting on the screen, and the lower 8 bits being the fractional part). This is really only for physics-heavy games however - you're certainly not going to need it for a Manic Miner clone! :D
All software to-date
Working on something, as always.
User avatar
R-Tape
Site Admin
Posts: 6353
Joined: Thu Nov 09, 2017 11:46 am

Re: The perfect fall/jump

Post by R-Tape »

Ast A. Moore wrote: Sat Jun 08, 2019 9:53 pm Sometimes, realism doesn’t look real in a video game, strangely enough.
Indeed! The bomb drop looks okay, though on the slow side for what I had in mind. I'd be interested in seeing a list of 8 bit numbers per frame.
PROSM wrote: Sat Jun 08, 2019 9:55 pm If we were to use the laws of physics, we would probably eschew a jump table. Instead, we would give the sprite an initial vertical velocity (henceforth known as u). At any instant in time during the jump, the velocity of the sprite can be calculated as

Code: Select all

v = u + at
where v is the velocity at time t, t is the current time in seconds and a is the acceleration (on Earth, the acceleration due to gravity is 9.8 metres per second, but we make it negative of course since we're going down).

Essentially, when the player jumps, you want to set delta-y (the change in y) to a starting value, and every frame, subtract your acceleration from delta-y, then add delta-y to the y coord of the sprite. To simulate terminal velocity (and more importantly, prevent overflow :mrgreen: ), you'll probably want to cap delta-y at a certain value.
Are you taking the P?s????!!!! This is exactly why I chose chemistry over physics :mrgreen:
For added precision, you may choose to use fixed-point coordinates, by storing them as 16-bit values (the upper 8 bits being the integer part, which you use for plotting on the screen, and the lower 8 bits being the fractional part). This is really only for physics-heavy games however - you're certainly not going to need it for a Manic Miner clone! :D
Exactly! I'd be very interested in seeing what people think is a perfect list of pixels per frame for a drop from the top to the bottom of the screen (for say a 16x16 pixel sprite).
User avatar
Ast A. Moore
Rick Dangerous
Posts: 2640
Joined: Mon Nov 13, 2017 3:16 pm

Re: The perfect fall/jump

Post by Ast A. Moore »

R-Tape wrote: Sat Jun 08, 2019 10:29 pm I'd be interested in seeing a list of 8 bit numbers per frame.
Ah, so you don’t need the code, just the resulting values, right? Then set a breakpoint at $9941 (that’s in the latest version, 1.2.0). Move the copter all the way to the top, wait a moment for the inertia multiplier to settle, and drop a bomb. The HL register pair will have the y coordinate: H will hold the integer and L the hexadecimal fraction (which you can ignore). Since the game runs at a steady 50 fps, each time the breakpoint activates, you’ll have a new x coord value.

Just in case you don’t want to be bothered with breakpoints in an emulator, below is a list of values passed into H that I got. These are the absolute x coordinates in pixels, the top of the screen being the origin, i.e. 0. (They are offset by the height of the copter + top margin.)

14, 14, 15, 15, 15, 16, 17, 17, 18, 19, 19, 1A, 1B, 1C, 1D, 1E, 1F, 20, 21, 22, 24, 25, 26, 28, 29, 2A, 2C, 2E, 2F, 31, 33, 34, 36, 38, 3A, 3C, 3E, 40, 42, 44, 46, 48, 4B, 4D, 4F, 52, 54, 57, 59, 5C, 5E, 61, 64, 67, 69, 6C, 6F, 72, 75, 78, 7B, 7F, 82, 85, 88, 8C.
Every man should plant a tree, build a house, and write a ZX Spectrum game.

Author of A Yankee in Iraq, a 50 fps shoot-’em-up—the first game to utilize the floating bus on the +2A/+3,
and zasm Z80 Assembler syntax highlighter.
User avatar
Ast A. Moore
Rick Dangerous
Posts: 2640
Joined: Mon Nov 13, 2017 3:16 pm

Re: The perfect fall/jump

Post by Ast A. Moore »

PROSM wrote: Sat Jun 08, 2019 9:55 pm the acceleration due to gravity is 9.8 metres per second
:o Don’t tell your physics teacher. It’s 9.8 meters per second per second. :lol:
Every man should plant a tree, build a house, and write a ZX Spectrum game.

Author of A Yankee in Iraq, a 50 fps shoot-’em-up—the first game to utilize the floating bus on the +2A/+3,
and zasm Z80 Assembler syntax highlighter.
User avatar
Einar Saukas
Bugaboo
Posts: 3070
Joined: Wed Nov 15, 2017 2:48 pm

Re: The perfect fall/jump

Post by Einar Saukas »

R-Tape wrote: Sat Jun 08, 2019 9:10 pm Image
The main reason it doesn't look right, is that the ball suddenly stopped moving forward while falling.
User avatar
djnzx48
Manic Miner
Posts: 729
Joined: Wed Dec 06, 2017 2:13 am
Location: New Zealand

Re: The perfect fall/jump

Post by djnzx48 »

I always found the default AGD jump table to be kind of weird, as the acceleration isn't constant over the jump duration. It makes the jumps look a bit floaty, as the thrust is higher at the start and end, and the sprite hangs in the air at the height of the jump.

You can probably do without a jump table, and just have a variable for y acceleration. Manic Miner seems to use this method: https://skoolkit.ca/disassemblies/manic ... 35515.html

Whenever the player jumps, set the y acceleration to an upwards value, and decrement it whenever the player isn't touching the ground. You can set it to zero when the player lands, and potentially have some upper limit so you don't fall too fast.
User avatar
PROSM
Manic Miner
Posts: 472
Joined: Fri Nov 17, 2017 7:18 pm
Location: Sunderland, England
Contact:

Re: The perfect fall/jump

Post by PROSM »

Ast A. Moore wrote: Sat Jun 08, 2019 11:21 pm
PROSM wrote: Sat Jun 08, 2019 9:55 pm the acceleration due to gravity is 9.8 metres per second
:o Don’t tell your physics teacher. It’s 9.8 meters per second per second. :lol:
Whoops! :oops:
Well, I always write it down correctly in symbolic form anyhow. :mrgreen:
All software to-date
Working on something, as always.
User avatar
Juan F. Ramirez
Bugaboo
Posts: 5102
Joined: Tue Nov 14, 2017 6:55 am
Location: Málaga, Spain

Re: The perfect fall/jump

Post by Juan F. Ramirez »

That fall needs two or three little bounces at the end to be more realistic.

I don't know if this question gets it more complicated... :roll:
Ralf
Rick Dangerous
Posts: 2279
Joined: Mon Nov 13, 2017 11:59 am
Location: Poland

Re: The perfect fall/jump

Post by Ralf »

I'd say most Spectrum games don't use proper laws of physics. To be specific they don't use things described
here https://en.wikipedia.org/wiki/Acceleration

Modern games may be different as they ofen use sophisticated physics engines. It's possible as modern computers
have a lot of CPU power which games from the 80s lacked.

In Spectrum games the speed of falling is generally constant, not v(t)=v0+at like in real world. Check Manic Miner as example.

And actually nobody complains about it. It's a part of gaming convention, just like things that killed enemies
dissappear or hero keeps gun in right hand when walking right but in left hand when walking left ;)

----------------------------
In my games like Janosik or Wunderwaffe (they use the same adjusted engine) I used the following logic:

- player has a status like standing on a ground, jumping or falling

- jump has defined number of steps, each step=one frame of the game

-first you go quickly up by 2 pixels, then slowly up by 1 pixel, then for a moment don't change your height,
then slowly down by 1 pixel, then quickly down by 2 pixels

- when you are going down during jump at any time it can be interrupted if your feet hit some floor

- when jump ends and you are still in the air, player changes status from jumping to falling

- during falling you fall with constant speed of 2 pixels until you hit the ground

So yes. I didn't use accelaration when falling. I believe it would make everything harder to code
and there wouldn't be any noticable improvement in the gameplay.
User avatar
Morkin
Bugaboo
Posts: 3251
Joined: Mon Nov 13, 2017 8:50 am
Location: Bristol, UK

Re: The perfect fall/jump

Post by Morkin »

R-Tape wrote: Sat Jun 08, 2019 9:10 pm Image
I quite like this - if it was a boulder being shoved off a cliff, it's landing roughly where I'd probably expect it to land (if it was a game). As already mentioned it does seem to stop moving right a bit too early though, I'd probably try to get it to land flush on the third tile along the bottom, but maybe that's just my OCD.. ;)

On the other hand it'd probably seem more odd if it was a sprite falling that way. Unless it's a game in which you control a boulder... :lol:

Two questions:

- what's with the gubbins in the top border? Something about interrupts I guess
- what's that tile doing in the middle of the screen?
My Speccy site: thirdharmoniser.com
User avatar
Ast A. Moore
Rick Dangerous
Posts: 2640
Joined: Mon Nov 13, 2017 3:16 pm

Re: The perfect fall/jump

Post by Ast A. Moore »

Morkin wrote: Sun Jun 09, 2019 1:29 pm - what's with the gubbins in the top border?
It’s a pretty standard way to visually estimate the time a routine takes to execute in relation to the duration of a frame. You set the border to a particular color, then change it at the beginning of the piece of code you wish to time, then change the color back at the end of that piece of code.
Every man should plant a tree, build a house, and write a ZX Spectrum game.

Author of A Yankee in Iraq, a 50 fps shoot-’em-up—the first game to utilize the floating bus on the +2A/+3,
and zasm Z80 Assembler syntax highlighter.
User avatar
Ersh
Manic Miner
Posts: 480
Joined: Mon Nov 13, 2017 1:06 pm

Re: The perfect fall/jump

Post by Ersh »

PROSM wrote: Sat Jun 08, 2019 9:55 pm If we were to use the laws of physics, we would probably eschew a jump table. Instead, we would give the sprite an initial vertical velocity (henceforth known as u). At any instant in time during the jump, the velocity of the sprite can be calculated as

Code: Select all

v = u + at
where v is the velocity at time t, t is the current time in seconds and a is the acceleration (on Earth, the acceleration due to gravity is 9.8 metres per second, but we make it negative of course since we're going down).

Essentially, when the player jumps, you want to set delta-y (the change in y) to a starting value, and every frame, subtract your acceleration from delta-y, then add delta-y to the y coord of the sprite. To simulate terminal velocity (and more importantly, prevent overflow :mrgreen: ), you'll probably want to cap delta-y at a certain value.

For added precision, you may choose to use fixed-point coordinates, by storing them as 16-bit values (the upper 8 bits being the integer part, which you use for plotting on the screen, and the lower 8 bits being the fractional part). This is really only for physics-heavy games however - you're certainly not going to need it for a Manic Miner clone! :D
That's the way I've always done it. It's pretty fast unless, of course, you have a lot of objects. It's easy to add some bounce on impact as well.
User avatar
djnzx48
Manic Miner
Posts: 729
Joined: Wed Dec 06, 2017 2:13 am
Location: New Zealand

Re: The perfect fall/jump

Post by djnzx48 »

IMO it's the landing part that doesn't look quite right - the ball just seems to gently come to a halt when it reaches the ground. It would look better if it continued to accelerate.

Bouncing probably isn't too complicated to do. Just flip the sign of the acceleration vector and reduce it by some factor, say a half, when you hit a floor or ceiling.

I would argue that proper physics is important in a platform game. I was never a fan of the characteristic triangular jump in games like Dynamite Dan, and I much preferred Manic Miner's curved jumps. It doesn't matter so much in arcade adventures, as the focus there isn't on precise movements and timing. But when a game involves a lot of platforms and dodging around, a nice jump curve can definitely improve the feel of the gameplay.
redballoon
Manic Miner
Posts: 390
Joined: Sun Nov 12, 2017 3:54 pm

Re: The perfect fall/jump

Post by redballoon »

User avatar
R-Tape
Site Admin
Posts: 6353
Joined: Thu Nov 09, 2017 11:46 am

Re: The perfect fall/jump

Post by R-Tape »

Einar Saukas wrote: Sun Jun 09, 2019 3:38 am The main reason it doesn't look right, is that the ball suddenly stopped moving forward while falling.
My picture is misleading—it allows horizontal movement during fall and I just stopped pressing the key.
Ralf wrote: Sun Jun 09, 2019 11:42 am In my games like Janosik or Wunderwaffe (they use the same adjusted engine) I used the following logic:
-first you go quickly up by 2 pixels, then slowly up by 1 pixel, then for a moment don't change your height,
then slowly down by 1 pixel, then quickly down by 2 pixels
- during falling you fall with constant speed of 2 pixels until you hit the ground
So yes. I didn't use accelaration when falling. I believe it would make everything harder to code
and there wouldn't be any noticable improvement in the gameplay.
I hope you don't my saying, but the jump/fall physics in your games is characteristically strange! I like it, and it's part of their personality, but Janosik and Wunderwaffe do feel like you're jumping in microgravity. IMO it's not hard to program, and it's worth experimenting with more acceleration: 1,2,4, 8 pixels.
Morkin wrote: Sun Jun 09, 2019 1:29 pm Two questions:

- what's with the gubbins in the top border? Something about interrupts I guess
- what's that tile doing in the middle of the screen?
-Yep, as Ast says, it's a timing thing*: set the border colour to red* before a routine, then another colour after it. The bigger the red band the longer it takes (bear in mind that top to bottom is 1 frame - 1/50th of a second). You see in this case the red band gets wider as the fall distance is greater. That's because a fall of 1 pixel needs checking once, and 8 needs checking 8 times (though I don't need to do it that way—needs improving).
-The middle tile is for collision checking. I'm pretty rusty, and am going back to basics! The trouble is, it's taken me hours to code what takes a seasoned AGD user 15 minutes! I plan to persevere though; I'm a big fan of AGD, but it's time I tried something that allows me to go down any path I want.

*doesn't have to be red of course, you can also use magenta
**and speaking of Gubbins, where is [mention]MatGubbins[/mention] these days?

djnzx48 wrote: Sun Jun 09, 2019 2:48 pm IMO it's the landing part that doesn't look quite right - the ball just seems to gently come to a halt when it reaches the ground. It would look better if it continued to accelerate.

Bouncing probably isn't too complicated to do. Just flip the sign of the acceleration vector and reduce it by some factor, say a half, when you hit a floor or ceiling.
Agreed. I think in El Stompo and Sunbucket the fall goes to a full 16 pixels at its maximum. Bouncing would be easy enough, but not appropriate for this (it's just a placeholder sprite).
I would argue that proper physics is important in a platform game. I was never a fan of the characteristic triangular jump in games like Dynamite Dan, and I much preferred Manic Miner's curved jumps. It doesn't matter so much in arcade adventures, as the focus there isn't on precise movements and timing. But when a game involves a lot of platforms and dodging around, a nice jump curve can definitely improve the feel of the gameplay.
I'm glad to see a large diversity of approaches, so I'm glad that not every Speccy game has the same 'perfect' jump. As a fan of naffness, I quite like the triangle jump. I never really thought about it, but now you mention, I'm surprised to see that Dynamite Dan has one. It's an incredibly accomplished game, and includes trampoline bounces and allsorts, but to have the same jump as Farenheit3000??!!

redballoon wrote: Sun Jun 09, 2019 3:53 pm ...vid link.
Nice. I guess the exaggeration and base over apex jumps demonstrate that one should forget theory and go with whatever looks good!
User avatar
Ast A. Moore
Rick Dangerous
Posts: 2640
Joined: Mon Nov 13, 2017 3:16 pm

Re: The perfect fall/jump

Post by Ast A. Moore »

R-Tape wrote: Sun Jun 09, 2019 8:36 pm *doesn't have to be red of course, you can also use magenta
Oh, I don’t know, Dave. I think magenta skews the timing a little bit. Better stick with red.
Every man should plant a tree, build a house, and write a ZX Spectrum game.

Author of A Yankee in Iraq, a 50 fps shoot-’em-up—the first game to utilize the floating bus on the +2A/+3,
and zasm Z80 Assembler syntax highlighter.
User avatar
R-Tape
Site Admin
Posts: 6353
Joined: Thu Nov 09, 2017 11:46 am

Re: The perfect fall/jump

Post by R-Tape »

Ast A. Moore wrote: Sun Jun 09, 2019 9:06 pm Oh, I don’t know, Dave. I think magenta skews the timing a little bit. Better stick with red.
Bloody hell you're right! I'm no hardware expert, but I guess the CPULA takes longer to find ink 3 than 2 when it sprays the border.

Image

And the less said about cyan the better :shock:

Image
User avatar
Ast A. Moore
Rick Dangerous
Posts: 2640
Joined: Mon Nov 13, 2017 3:16 pm

Re: The perfect fall/jump

Post by Ast A. Moore »

R-Tape wrote: Sun Jun 09, 2019 9:25 pm And the less said about cyan the better :shock:
Oh, cyan is just plain evil. Evil, I say!
Every man should plant a tree, build a house, and write a ZX Spectrum game.

Author of A Yankee in Iraq, a 50 fps shoot-’em-up—the first game to utilize the floating bus on the +2A/+3,
and zasm Z80 Assembler syntax highlighter.
redballoon
Manic Miner
Posts: 390
Joined: Sun Nov 12, 2017 3:54 pm

Re: The perfect fall/jump

Post by redballoon »

R-Tape wrote: Sun Jun 09, 2019 8:36 pm Nice. I guess the exaggeration and base over apex jumps demonstrate that one should forget theory and go with whatever looks good!
Bingo! And I recommend this book, which is what I use. I've got it sitting out next to me for reference when I need it while doing Melkhior's Mansion animation.

Image

Course, you may only have 4 frames...or 2 or 8, but if you're going to be doing any motion graphics, then, really, it certainly doesn't hurt knowing this. There is a PDF of the above book available if you do a Google search for it.
User avatar
Morkin
Bugaboo
Posts: 3251
Joined: Mon Nov 13, 2017 8:50 am
Location: Bristol, UK

Re: The perfect fall/jump

Post by Morkin »

R-Tape wrote: Sun Jun 09, 2019 9:25 pm And the less said about cyan the better :shock:

Image
That's going to give me nightmares.
My Speccy site: thirdharmoniser.com
hikoki
Manic Miner
Posts: 576
Joined: Thu Nov 16, 2017 10:54 am

Re: The perfect fall/jump

Post by hikoki »

mcleod_ideafix wrote: After refreshing my physics here:
http://www.sc.ehu.es/sbweb/fisica/dinam ... tucion.htm

I've came up with this:
Image

Which shows this:
Image

In the listing:

Code: Select all

hmax : initial height of the particle. Set to 175 (maximum height in pixels)
vxo : X component of velocity vector. The more you put here, the farther
the particle will get to the right.
vyo : Y component of velocity vector. Initially set to 0.
e : coefficient of restitution after a colission with the ground.
g : 9.8 m/s^2
x,y : particle position in each time slice.
t : time. It's reset to 0 after each colission, as the colission marks
the beginning of a new parabolic trajectory.
Post at WoS: https://www.worldofspectrum.org/forums/ ... ent_639936
User avatar
djnzx48
Manic Miner
Posts: 729
Joined: Wed Dec 06, 2017 2:13 am
Location: New Zealand

Re: The perfect fall/jump

Post by djnzx48 »

That listing looks a bit overly complicated to me. How about this:

Code: Select all

 1 LET g=-0.025: REM gravity
 2 LET b=-0.8: REM bounce factor
 5 LET vx=0.5: LET vy=0: REM velocity
10 LET x=0: LET y=175: REM displacement
20 PLOT x,y
30 LET vy=vy+g
40 LET x=x+vx: LET y=y+vy
50 IF y<0 THEN LET y=0: LET vy=vy*b
60 IF x<=255 THEN GO TO 20
User avatar
RMartins
Manic Miner
Posts: 776
Joined: Thu Nov 16, 2017 3:26 pm

Re: The perfect fall/jump

Post by RMartins »

R-Tape wrote: Sun Jun 09, 2019 8:36 pm
Einar Saukas wrote: Sun Jun 09, 2019 3:38 am The main reason it doesn't look right, is that the ball suddenly stopped moving forward while falling.
My picture is misleading—it allows horizontal movement during fall and I just stopped pressing the key.
To feel smooth, user input needs to control acceleration, not velocity or position (X in this case).

If each time you stop pressing the key, you stop any movement in X axis, it will not feel smooth.

NOTE: You also need some kind of attrition force, to make the object stop, after you stop accelerating.
I use a percentage of the - velocity or a fixed amount with opposite sign to velocity (abs equal or lower to actual velocity) so that when it reaches near zero, it will become zero).

In Steel Ball I implemented a 24 bit fixed value for X and 16 bit fixed value for Y, so that movement was smooth.
http://zx-dev-2015.proboards.com/thread/18/steel-ball

NOTE: Due to gameplay requirements, the ball needs to keep bouncing a minimum amount, so that the ball can move around in the scenery.
In this case, I hack the Y velocity abs value, if it's too low, after a collision with a flat/horizontal service.

You can try it online: http://torinak.com/qaop#48#l=https://sp ... mAFp9a.tap
Post Reply