## The perfect fall/jump

The place for codemasters or beginners to talk about programming any language for the Spectrum.
R-Tape
Posts: 2592
Joined: Thu Nov 09, 2017 11:46 am

### The perfect fall/jump

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:

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.
0 x

Ast A. Moore
Dynamite Dan
Posts: 1224
Joined: Mon Nov 13, 2017 3:16 pm

### Re: The perfect fall/jump

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 9:45 pm, edited 1 time in total.
1 x
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.

PROSM
Microbot
Posts: 100
Joined: Fri Nov 17, 2017 7:18 pm
Location: Sunderland, England
Contact:

### Re: The perfect fall/jump

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 ), 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!
2 x
All software to-date

Current Projects:
Currently working on ZX Adventure Designer, which lets one create point-and-click graphic adventures for a 48K Spectrum.

R-Tape
Posts: 2592
Joined: Thu Nov 09, 2017 11:46 am

### Re: The perfect fall/jump

Ast A. Moore wrote:
Sat Jun 08, 2019 8: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 8: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 ), you'll probably want to cap delta-y at a certain value.
Are you taking the piss???!!!! This is exactly why I chose chemistry over physics
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!
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).
0 x

Ast A. Moore
Dynamite Dan
Posts: 1224
Joined: Mon Nov 13, 2017 3:16 pm

### Re: The perfect fall/jump

R-Tape wrote:
Sat Jun 08, 2019 9: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.
0 x
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.

Ast A. Moore
Dynamite Dan
Posts: 1224
Joined: Mon Nov 13, 2017 3:16 pm

### Re: The perfect fall/jump

PROSM wrote:
Sat Jun 08, 2019 8:55 pm
the acceleration due to gravity is 9.8 metres per second
Don’t tell your physics teacher. It’s 9.8 meters per second per second.
2 x
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.

Einar Saukas
Manic Miner
Posts: 949
Joined: Wed Nov 15, 2017 2:48 pm

### Re: The perfect fall/jump

R-Tape wrote:
Sat Jun 08, 2019 8:10 pm
The main reason it doesn't look right, is that the ball suddenly stopped moving forward while falling.
0 x

djnzx48
Manic Miner
Posts: 568
Joined: Wed Dec 06, 2017 2:13 am
Location: New Zealand

### Re: The perfect fall/jump

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.
0 x

PROSM
Microbot
Posts: 100
Joined: Fri Nov 17, 2017 7:18 pm
Location: Sunderland, England
Contact:

### Re: The perfect fall/jump

Ast A. Moore wrote:
Sat Jun 08, 2019 10:21 pm
PROSM wrote:
Sat Jun 08, 2019 8:55 pm
the acceleration due to gravity is 9.8 metres per second
Don’t tell your physics teacher. It’s 9.8 meters per second per second.
Whoops!
Well, I always write it down correctly in symbolic form anyhow.
0 x
All software to-date

Current Projects:
Currently working on ZX Adventure Designer, which lets one create point-and-click graphic adventures for a 48K Spectrum.

Juan F. Ramirez
Rick Dangerous
Posts: 2095
Joined: Tue Nov 14, 2017 6:55 am
Location: Málaga, Spain

### Re: The perfect fall/jump

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...
0 x