Re: How to continue

[David Philippi]

On Tuesday 11 June 2002 15:41, Ingo Ruhnke wrote:
> auto_ptr<> wasn't there in g++-2.9x when I remember correctly and

It's there. I didn't install any additional library to use it and I'm very 
sure that I used it with gcc-2.9x .

> 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.

This happens nearly everytime. Question is - does one rewrite the code?

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

Something like a singleton, accessible from everywhere?

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

Another way to solve the problem.

> I commited some files to CVS (GameDelta, InputEvent, GameEvent) which
> can of show what I have in mind.

I'll look into them. I'm just working on a ClanLib patch since there are 
quite a few headers which can't be included alone. I first encountered this 
when I removed core.h / display.h from Pingus. At first I planned to ignore 
this and let someone else fix this bug. Then I encountered a comment above 
an include: "required because of a missing #include in a ClanLib header". So 
I thought waiting on someone else to do it could take a bit of time... ;-)

> 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.

std::vector isn't really a performance problem, but unless you have a fixed 
number of entries with a fixed size it'll be slower because vector needs 
continous memory which is harder to allocate and with bad luck need to be 
reallocated when you push a new element into it. Therefore one should only 
use it when the arraylike access is required.

> > 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::vector of all ever allocated pingus which will stay
>    there till the level ends, this std::vector is used just for
>    garbage collection

Which pingus stay until the level ends?

> 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.

Sorry, I don't catch what you're saying here. Do you want a seperate garbage 
list for every type of object ? Would be better if not every object is 
derived from a common base class.

Bye David