Spectrum Computing

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.



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.

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

That's going to give me nightmares.

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

I've came up with this:


Which shows this:


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

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

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