The perfect fall/jump

The place for codemasters or beginners to talk about programming any language for the Spectrum.
Post Reply
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