Re: How to continue

[Ingo Ruhnke]

David Philippi <address@hidden> writes:

> Why didn't you use auto_ptr<> in the first place? Most people
> knowing C++ will know what an auto_ptr<> is, but who many know a
> boost::shared_ptr<>?

auto_ptr<> wasn't there in g++-2.9x when I remember correctly and
since I discovered the shared_ptr<> at that time and got used to it, I
simply used that, since it was there. I haven't planed much in
advanced while programming Pingus, so some things turned out ugly in
the end.
 
> Since I can't read your mind, I've got to ask again. What's wrong
> with the currenct Controller concept (whatever it might be)

Just look at Controller.hh and Controllable.hh, it contains far to
much signal mumbo jumbo stuff at the moment, which makes event
recording quite a bit difficult and ugly. I would also like to get
everything input related into the update() function, which would be
cleaner IMHO.

> and what's your idea how it should be.

I am not sure what would be the correct way, but I plan something like that:

 - have a GameDelta class which encapsules all input events and the
   time delta, so recording/playback is trivial

 - pass that GameDelta to the update() function and route it from
   there through the class hierachy

 - input event dispatching has than do be done inside the update class

 - advantage would be that manipulation, recording and playback of
   events would be easier and the code could get simpler, even so I am
   not sure on this issue

I commited some files to CVS (GameDelta, InputEvent, GameEvent) which
can of show what I have in mind.
 
> Let's see if I got this right - every object in the world is in some
> shared_ptr<> and if noone references it anymore, it's getting
> deleted.

Yep.

> The better alternative would be to place every object beeing created
> in a std::list (why pay the performance penalty of std::vector?)

Why should std::vector be a performance problem (since this would be
an ever growing list of objects)? IIRC we currently don't have a way
to add or remove objects at runtime, so a std::vector should do a good
job.

> gaining the advantage that there's one place to find every object
> and to delete any of them at level end.

For the pingus itself I currently do the following:

 * keep a std::list of active pingus, which get be removed from there
   if they get killed, this list is used for drawing, updating, etc.

 * keep a std::vector of all ever allocated pingus which will stay
   there till the level ends, this std::vector is used just for
   garbage collection

Something similar might work for the world, but we could actually get
rid of the std::list, since currently the world is static, all dynamic
things like pingus and particles are handled in there own classes.
Even so that might change in the future.

-- 
Advent:     http://www.freesoftware.fsf.org/advent/
Feuerkraft: http://www.freesoftware.fsf.org/feuerkraft/
Pingus:     http://pingus.seul.org/           || ICQ:      59461927
Home:       http://pingus.seul.org/~grumbel/  || JabberID: address@hidden