Re: BUG #1589: The whole concept of forces/move_with_forces/forces_holder > needs to be rethought

[Ingo Ruhnke]

Gervase Lam <address@hidden> writes:

> Could you say what the problem is and possible initial ideas on what
> the solution could be?

The problem is that move_with_forces() doesn't have a well defined
purpose and it doesn't have a useable interface. If you look at
faller.cxx you will see a call to move_with_forces() and a few lines
later a bunch of in theory obsolete code that still gets called and
sometimes does the right thing and sometimes not. The whole behaviour
of move_with_forces() is more random than anything else.

> I know that there is the fallers don't die problem. But I thought
> this was due to the fact that somebody had changed the deadly
> velocity in response to the desert2.xml level being impossible to
> do.
 
The problem was and still is that move_with_forces() has no way to
tell the calling action what just has happended. If Pingu hits the
ground, move_with_forces() will reset the velocity to 0 and the
calling action has no idea that the pingu was to fast on ground hit.

> I don't have an update to date CVS at the moment. I don't want to
> overwrite my stuff in connection with fixed width fonts (I'll most
> probably e-mail about this later).

'cvs update' won't overwrite files, it will merge changes done to that
file with your changes. If changes conflict, than you will get some
markers (<<<<<<<<<</>>>>>>>>>>>) around your code and the other code
and get pick the correct one.

Back to the move_with_forces() thing:

So first, what problem should move_with_forces() solve?
-> Join the fall-code of bomber, jumper, faller, skater and other
-> actions

What is the fall-code of these action?
-> Its basically: new_pos = old_pos + velocity; and a collision check
-> for each pixel on the line between new_pos and old_pos.

Is the collision check and the reaction always equal?
-> No, a bomber once reaching the ground should explode, a faller
-> should turn into a walker and other actions might react different.
-> So the collision resolution must not be placed in
-> move_with_forces() The collision code could also be completly
-> different, a imaginary pingu->ball transformation, would have a
-> different collision shape than a normal pingu, a slider doesn't
-> have head-bounce and things like that.

Do we still have forces?
-> Forces never really worked 100%, so I removed them yesterday. Only
-> force that is left is the gravity which is applied in
-> move_with_forces(). Forces will eventually come back later, but
-> they must be tighter

Are there other solution to aproach the code join?
-> all actions could just call faller and faller could look at
-> previous_action to do the right thing, instead of letting the
-> actions to that alone.

How should the solution look like?
-> No idea, but basically forces (velocity += force) and movement (pos
-> += velocity) needs to be seperated and a virtual collision() function
-> might be needed for each action. Something like:
->
->   PinguAction::apply_forces_to_velocity();
->   PinguAction::move_to(new_pos, collision_func());
                                   ^^^^^^^^^^^^^^^^

This would result in the use of member templates, could somebody
confirm that MSVC6 supports them? As far as I know its only there STL
which is build without them.

-- 
WWW:      http://pingus.seul.org/~grumbel/ 
Games:    http://pingus.seul.org/~grumbel/gamedesigns/
JabberID: address@hidden 
ICQ:      59461927