pingus-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Inconsistent fall survival & jumpers bouncing off


From: Gervase Lam
Subject: Re: Inconsistent fall survival & jumpers bouncing off
Date: Mon, 22 Sep 2003 00:33:45 +0100

> Date: Thu, 04 Sep 2003 09:27:24 +0200
> From: David Philippi <address@hidden>
> Subject: Re: Inconsistent fall survival & jumpers bouncing off

> If you have a bugfix and an explanation/testcase that shows how to
> reproduce the bug and how your patch fixes it, then by all means, send
> it to the list to get it into CVS.

Just a quick update on this.  A mixture of motivational problems, work, me 
not being fully well earlier this week and trying to sort out other things 
has meant this is still in progress.

I finished most of the work last weekend.  However, on starting to change 
the Bomber code, I realised that it needed to act in basically the same 
way as Fallers.

So, I eventually decided that it would be a good idea to have a new Mover 
class called MidAirPinguMover, which in turn would use the existing 
LinearMover class!  This new class has yet to be created.

I don't think I'll have time this week because of work commitments and 
I'll be holiday for one week starting on Wednesday.  Therefore, I think 
the earliest I'll be able to get the patch posted to the list is about 2 
weeks from now.

> What's the problem with that bugfix?

Class PinguAction
{
        AnotherMover Another_Mover;

        Another_Mover.update(Collider()); // etc...
}

Class AnotherMover
{
AnotherMover (Collider& collider_arg) : collider(collider_arg) {};

update ()
        {
        have_you_collided = collider();
        };
}

The code in CVS is something like the above.  However, it is not trivial 
for PinguAction to find out whether it has collided with a ground or lava, 
for example.  PinguAction could use a loop to do so, but why does it need 
to considering that is already a part of Collider's job?

Class PinguAction
{
        AnotherMover Another_Mover;

        Another_Mover.update(Collider()); // etc...

        Another_Mover.collided_with();
}

Class AnotherMover
{
AnotherMover (Collider& collider_arg) : collider(collider_arg) {};

update ()
        {
        collider(*this);        // Pass by reference
        };
}

The idea I coded went something like the above.  The collider used the 
mover as a function object to pass have_you_collided and the collision 
pixel back to the mover.  The problem is that this is stupid and messy.  
(Hmm.  Unintended pun in the previous sentence.  Nevertheless, the pun 
points out the main problem.)

So, what I've decided to do is go back to one of the ideas I had before 
the stupid idea.  That is to do it like the old way of doing it but to add 
a vector reference parameter.  The mover can then have not only a method 
to find out where the collision was, but it can also have a method to 
convert the vector into a collision pixel.

I initially rejected this idea because I thought it was stupid to get a 
return value (have_you_collided) from the collider plus another value (the 
vector in this case) returned via a reference parameter.  Shouldn't these 
two values really be "returned" in the form of an object or class, which 
means another class/struct needs to be written?  I've obviously changed my 
mind.

Thanks,
Gervase.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]