Re: How to continue

[Ingo Ruhnke]

David Philippi <address@hidden> writes:

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

Hm, not sure about that one, but I had problem with it in some version
of gcc. Not sure about MSVC here.
 
> This happens nearly everytime. Question is - does one rewrite the code?

As long as the code works I don't (should not) rewrite it. Most of the
time one can get away with rewriting parts of the interface.
 
>>  - 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?

No, for cutscenes and the credits screen I might want to run two World
instances in parallel, so this has to be passed around instead of
having one global instance.
 
> 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... ;-)

I wouldn't invest to much time into this, since ClanLib-0.6 is a dead
brunch, for ClanLib-0.7 many things have/will change dramatically.
 
> 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.

In the end this isn't really an issue, copying an std::vector<> of a
hundred pointers shouldn't really take that much time.

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

If one finished the level, none. If the time runs out, then the ones
which are still around and not killed or exited.

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

No. We currently have three main types of objects WorldObjs (exit,
entrances, traps, etc.), Pingus and Particles. Both Pingus and
particles are dynamic and get removed/added quite a bit, both of them
already have there own manager class which handles allocation and
deletion. The WorldObjs themself are currently static, they get
created on level creation and get removed an level destruction. To
keeping a second garbage list arround isn't necessary at the moment. 

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