Re: Fallers slown down

[Gervase Lam]

> Date: 25 Mar 2003 14:13:35 +0100
> From: Ingo Ruhnke <address@hidden>
> Subject: Re: Fallers slown down

> And another bug, fallers seem to survive some falls now, which they
> shouldn't, i.e. the faller is already tumbling, then touches the
> ground, but still survies.

I added some debug messages to try to find out what was going on and got 
the results similar to the following (Pingu 2 is the one underneath the 
arrow in "faller.xml".  Pingu 3 is the pingu to the left of it.  There is 
also a Pingu 1 to the right of Pingu 2):

pingu:2 below:0 collided:0 velocity:0 0.25 0 pos:390 265 0
pingu:2 below:0 collided:0 velocity:0 0.5 0 pos:390 265 0
pingu:2 below:0 collided:0 velocity:0 0.75 0 pos:390 265 0
:
:
pingu:2 below:0 collided:0 velocity:0 10.25 0 pos:390 465 0
pingu:2 below:0 collided:0 velocity:0 10.5 0 pos:390 475 0
pingu:2 below:3 collided:1 velocity:0 10.75 0 pos:390 476 0

pingu:3 below:0 collided:0 velocity:0 0.25 0 pos:333 266 0
pingu:3 below:0 collided:0 velocity:0 0.5 0 pos:333 266 0
pingu:3 below:0 collided:0 velocity:0 0.75 0 pos:333 266 0
:
:
pingu:3 below:0 collided:0 velocity:0 10.25 0 pos:333 466 0
pingu:3 below:3 collided:0 velocity:0 10.5 0 pos:333 476 0
pingu:3 below:3 collided:1 velocity:0 10.75 0 pos:333 476 0

As you can see, with a gravity (i.e. acceleration) of 0.25, both Pingus 
hit the ground with exactly the same velocity.  The same thing happened 
when I patched in the faller code that existed before move_with_forces() 
was introduced.

Also note the positions of the Pingus at the start of their fall.  Even 
though in three updates the Pingu should have travelled about (0.25 + 0.5 
+ 0.75) = 1.5 pixels, instead the Pingu has moved nowhere.

Basically speaking, this is because the Mover engine and also the old 
faller code only allowed the Pingu to move in whole pixels.  This was one 
of the reasons why the deadly velocity I calculated didn't work.

So, to more accurately position the Pingu, I allowed it to move fractions 
of a pixel.  However, this in itself would not have been good enough to 
make Pingu 2 die and Pingu 3 survive.  Calculating the velocities of each 
of the Pingus when they each hit the ground, I got:

Pingu 1: v^2 = u^2 + 2as = 2as = 2*0.25*(212 pixels) = 106 => v = 10.29
Pingu 2: v^2 = u^2 + 2as = 2as = 2*0.25*(211 pixels) = 105.5 => v = 10.27
Pingu 3: v^2 = u^2 + 2as = 2as = 2*0.25*(210 pixels) = 105 => v = 10.24

v = Final velocity.
u = Initial velocity (equals 0 at the start of a fall).
a = Acceleration (in this case gravity).
s = Distance move.

I have added Pingu 1 as it is easier to illustrate the potential problem 
whenever the gravity is changed.

The faller code, which can sort of be seen in the debug messages, would 
give both Pingus 1 and 2 a velocity of 10.25.  On updating the position of 
the Pingus, both would have a velocity of 10.5.  If both the Pingus were 
to hit the ground on this update, it would be impossible to make Pingu 1 
die and Pingu 2 survive.

Therefore, I added into the faller code the above equation so that the 
velocity of the Pingu on hitting the ground can be found and not the 
velocity "before" it hits the ground.

So that the equation could be used consistently, I replaced the equation 
(s = u + a) that used to be used when updating the velocity of fallers to 
the proper equation (s = ut + 0.5at^2 = u + 0.5a, where t is the time 
taken to move).

The old equation resulted in a model whereby the faller only accelerated 
at each interval (i.e. interval 1, 2, 3, 4...).  In between each interval, 
the Pingu would not be accelerating.  Using the proper equation allows the 
modeling of the acceleration that should still happen in between the 
intervals.

As I mentioned in a previous post, I have slightly modified how Movers and 
Colliders worked so that the pixel which an object (e.g. a Pingu) collided 
with could be found out.  This means that Jumpers die when they jump into 
water instead of bouncing off it.  This was done by making the Collider 
"pass back" this information indirectly.

I thought of other ways of doing like passing back directly by using a 
return value.  However, this meant that (strictly speaking) I would have 
had to make a new class that contained both a flag to say whether the 
object collided with something and a variable to say what the object 
collided with.  Movers don't know how to process the latter, and so need 
the former whereas the code for a Pingu's action (e.g. Faller, Bomber) 
needs the latter.

Another way I thought of doing it was to put the information in the 
Collider.  Movers can then use member functions of the Collider to get the 
required information.  However, this meant that Collider would not be 
const (like now) and would be have to be passed by value (unlike now).  
This would result in another construction being done for the Collider.

I thought of other ways to do this (there are many ways to skin a cat).  
However, the solution I came up with seemed to most sensible.  It's 
probably better to see the diff and read the code to see if what I've 
done is OK or not instead of me trying to explain it.  If it isn't good, 
just say so.

There are a few minor things I changed because gravity has changed.  This 
includes the jumper and bomber code.  I've also made Walkers die when they 
walk into water/lava rather then reflect off it.

Thanks,
Gervase.

pingus.200304060047.cvs.diff
Description: Text Data