[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: How to continue
From: |
David Philippi |
Subject: |
Re: How to continue |
Date: |
Tue, 11 Jun 2002 16:11:11 +0200 |
User-agent: |
KMail/1.4.1 |
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
- How to continue, David Philippi, 2002/06/11
- Re: How to continue, David Philippi, 2002/06/11
- Re: How to continue, Ingo Ruhnke, 2002/06/11
- Re: How to continue, David Philippi, 2002/06/11
- Re: How to continue, Ingo Ruhnke, 2002/06/11
- Re: How to continue,
David Philippi <=
- Re: How to continue, Ingo Ruhnke, 2002/06/11
- Re: How to continue, David Philippi, 2002/06/11
- Re: How to continue, Ingo Ruhnke, 2002/06/11
- Re: How to continue, David Philippi, 2002/06/11
- Re: How to continue, Ingo Ruhnke, 2002/06/11
- Re: How to continue, David Philippi, 2002/06/11
- Re: How to continue, Ingo Ruhnke, 2002/06/11
- Re: How to continue, David Philippi, 2002/06/11
- Re: How to continue, David Philippi, 2002/06/11
- Re: How to continue, Ingo Ruhnke, 2002/06/12