The perfect fall/jump

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

The perfect fall/jump

Post by R-Tape » Sat Jun 08, 2019 8:10 pm

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

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

Re: The perfect fall/jump

Post by Ast A. Moore » Sat Jun 08, 2019 8:53 pm

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.

User avatar
PROSM
Dizzy
Posts: 99
Joined: Fri Nov 17, 2017 7:18 pm
Location: Sunderland, England
Contact:

Re: The perfect fall/jump

Post by PROSM » 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 :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
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.

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

Re: The perfect fall/jump

Post by R-Tape » Sat Jun 08, 2019 9:29 pm

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 :mrgreen: ), 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 :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).
0 x

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

Re: The perfect fall/jump

Post by Ast A. Moore » Sat Jun 08, 2019 10:20 pm

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.

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

Re: The perfect fall/jump

Post by Ast A. Moore » 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
:o Don’t tell your physics teacher. It’s 9.8 meters per second per second. :lol:
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.

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

Re: The perfect fall/jump

Post by Einar Saukas » Sun Jun 09, 2019 2:38 am

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

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

Re: The perfect fall/jump

Post by djnzx48 » Sun Jun 09, 2019 3:37 am

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

User avatar
PROSM
Dizzy
Posts: 99
Joined: Fri Nov 17, 2017 7:18 pm
Location: Sunderland, England
Contact:

Re: The perfect fall/jump

Post by PROSM » Sun Jun 09, 2019 6:56 am

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
: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:
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.

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

Re: The perfect fall/jump

Post by Juan F. Ramirez » Sun Jun 09, 2019 7:57 am

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

Post Reply