Gravity

[RHillFake]

I have a gravity(ish) command in my game, but it is way to fast. Any body have any idea how to make it slower without affecting the regular movement?

 rem Gravity
 if !joy0up  && !collision(player0,playfield) then player0y = player0y + 1  : m = 3

 rem Regular movement controls
 if joy0up && !collision(player0,playfield) then player0y = player0y - 1 : m = 1   
 if joy0left  && !collision(player0,playfield) then player0x = player0x - 1 :  m = 2 
 if joy0down  && !collision(player0,playfield) then player0y = player0y + 1  : m = 3
 if joy0right  && !collision(player0,playfield) then player0x = player0x + 1 :  m = 4

[+Cafeman]

Increment a new variable grav1. When it gets to 10, perform your gravity routine and reset grav1 back to 0.

[bogax]

Hard to know exactly what you want since you don't
give any detail about how you want player0 to behave

Here's some gravity using 16 bits for fractional pixel
movement calculations

Untested

rem 16 bit player0 y position
dim P0y_position = player0y.y

rem 16 bit velocity
dim P0y_velocity = v.w

rem gravity is acceleration
rem the smallest fraction is 1/256 rounded up here to 0.004
rem assuming gravity is applied each drawscreen this should
rem work out to ~7 pixels in 1 second, 28 pixels in 2 seconds
rem 63 pixels in 3 seconds
def acceleration = 0.004

if collision(player0,playfield) then skip_move
if joy0up then P0y_velocity = 0.0 : player0y = player0y - 1 : y = 0 : m = 1 : goto skip_gravity
if joy0down then P0y_velocity = 0.0 : player0y = player0y + 1 : y = 0 : m = 3 : goto skip_gravity

rem apply gravity
P0y_velocity = P0y_velocity + acceleration
P0y_position = P0y_position + P0y_velocity

skip_gravity
if joy0left then player0x = player0x - 1 : m = 2
if joy0right then player0x = player0x + 1 : m = 4

skip_move

Edited June 25, 2014 by bogax

[RHillFake]

 

Hard to know exactly what you want since you don't

give any detail about how you want player0 to behave

 

Here's some gravity using 16 bits for fractional pixel

movement calculations

 

Untested

 

rem 16 bit player0 y position
dim P0y_position = player0y.y

rem 16 bit velocity
dim P0y_velocity = v.w

rem gravity is acceleration
rem the smallest fraction is 1/256 rounded up here to 0.004
rem assuming gravity is applied each drawscreen this should
rem work out to ~7 pixels in 1 second, 28 pixels in 2 seconds
rem 63 pixels in 3 seconds
def acceleration = 0.004

if collision(player0,playfield) then skip_move
if joy0up then P0y_velocity = 0.0 : player0y = player0y - 1 : y = 0 : m = 1 : goto skip_gravity
if joy0down then P0y_velocity = 0.0 : player0y = player0y + 1 : y = 0 : m = 3 : goto skip_gravity

rem apply gravity
P0y_velocity = P0y_velocity + acceleration
P0y_position = P0y_position + P0y_velocity

skip_gravity
if joy0left then player0x = player0x - 1 : m = 2
if joy0right then player0x = player0x + 1 : m = 4

skip_move

That is actually perfect! Thank you!

 

For future reference can you explain to me how it works though? I understand a little bit.

[bogax]

Motion is changing position with time.

Velocity how much position changes with time.

Acceleration is changing how much the change
of position changes with time, ie changing velocity.

Gravity is acceleration in a downward direction.

In this case, you get time in discrete ticks of the
clock (each drawscreen) so you add discrete amounts
of position (the velocity, the amount of change of
position per tick) to get motion.

To affect gravity you do a similar thing with
velocity as you do with position.
You add a discrete per-tick-change in velocity
(the acceleration) to the velocity.

But since you normally do things in increments of
1 pixel and that's apparently too much, I defined some
8.8 variables so it can be done fractionally.

An 8.8 variable has eight bits of integer part and eight
bits of fractional part. 8 bits gives you 256
possibilities so eight bits of fraction allows a minimum
(other than zero) of 1/256 = 0.00390625 which I rounded
to 0.004 decimal which bB will round to 0.00390625
internally (because it's actually binary ie in powers of 2,
not decimal)

Since you add a fixed increment of velocity per
tick/drawscreen (ie the acceleration) the velocity after
t ticks is

v = t * acceleration

(assuming you start from zero) and since acceleration
is constant the average velocity is

v(average) = (t * acceleration) / 2

and since the change in position is

y(change) = v(average) * t

which comes out to

y(change) = (acceleration * t * t) / 2

and if t is 60/second

That works out to about 7 for one second,
29 for two seconds, 65 for three seconds, etc.


If there's a collision, the code skips the
movement stuff.

If you're moving (no collision) and joy0 is either
up or down it zeros the velocity and applies the
joy0 movement and skips the gravity (it throws away
the effects of gravity and lets the joy stick take
over)

If joy0 is neither up or down it applies gravity
by adding the acceleration to the y velocity
and adding the y velocity to the y position.

[RHillFake]

Motion is changing position with time.

 

Velocity how much position changes with time.

 

Acceleration is changing how much the change

of position changes with time, ie changing velocity.

 

Gravity is acceleration in a downward direction.

 

In this case, you get time in discrete ticks of the

clock (each drawscreen) so you add discrete amounts

of position (the velocity, the amount of change of

position per tick) to get motion.

 

To affect gravity you do a similar thing with

velocity as you do with position.

You add a discrete per-tick-change in velocity

(the acceleration) to the velocity.

 

But since you normally do things in increments of

1 pixel and that's apparently too much, I defined some

8.8 variables so it can be done fractionally.

 

An 8.8 variable has eight bits of integer part and eight

bits of fractional part. 8 bits gives you 256

possibilities so eight bits of fraction allows a minimum

(other than zero) of 1/256 = 0.00390625 which I rounded

to 0.004 decimal which bB will round to 0.00390625

internally (because it's actually binary ie in powers of 2,

not decimal)

 

Since you add a fixed increment of velocity per

tick/drawscreen (ie the acceleration) the velocity after

t ticks is

 

v = t * acceleration

 

(assuming you start from zero) and since acceleration

is constant the average velocity is

 

v(average) = (t * acceleration) / 2

 

and since the change in position is

 

y(change) = v(average) * t

 

which comes out to

 

y(change) = (acceleration * t * t) / 2

 

and if t is 60/second

 

That works out to about 7 for one second,

29 for two seconds, 65 for three seconds, etc.

 

 

If there's a collision, the code skips the

movement stuff.

 

If you're moving (no collision) and joy0 is either

up or down it zeros the velocity and applies the

joy0 movement and skips the gravity (it throws away

the effects of gravity and lets the joy stick take

over)

 

If joy0 is neither up or down it applies gravity

by adding the acceleration to the y velocity

and adding the y velocity to the y position.

Thanks