One of the things I found I needed for games was a way to dynamically create and destroy object such as missiles or particles. At first I got around this with static array large enough to ensure I would never need more memory. But I didn't like this, a) its wasteful & b) you never know exactly how many objects you could need.

So I worte a dynamic array lib, it went through many changes but, I think its finally at a stage where I can't add much more to it.

So here you are, full source is included as well as an rtf explaining how to use it. It late and I wrote the rtf slightly rushed so forgive me if its full of mistakes ;).

This is completly free for all of ye to use, theres nothing here about only non-comercial apps or that crap. However I would appreciated an acknowledgement if you feel it was of help to you in an app, of course thats not a requirement (not that I could enforce it if it were :grin: )

And don't forget, if you do make any nice changes or additions to it then post them here. Let us all benifit.

Well thats it, good luck, good night.
Posted on 2002-01-10 21:00:42 by Eóin
Just a quick question - how do you grow the array? You should do
it in a "delta" fashion - always allocate memory for, say, 64 new
entries (depending on entry size) so you don't end up fragmenting
the heap too much.
Posted on 2002-01-11 01:38:35 by f0dder
I have to be perfectly honest here and say I have no idea what you mean by a 'delta' fashion. :confused: Could you please explain it to me.

As it stands I use GlobalReAlloc to change to size of the array.
Posted on 2002-01-11 09:07:35 by Eóin
Okay... imagine you have an array of relatively small structs, and
you pretty often needs to add a new entry to the array. If you have
other memory allocations going on in your application, the array
size can't just grow, stuff will have to be moved around (well, probably
only on the paging level, but you still fragment your linear address space).
The better solution is to allocate space for, say, 32 or 64 or 128
(or some other number, depending on your needs) entries... that
way the heap will be a lot less fragmented. Of course, again there's
situations when this is not necessary...

hrm, that could have been written in much fewer words and have
made much more sense.
Posted on 2002-01-11 09:18:47 by f0dder
Afternoon, f0dder.

Is that *batching* you're talking about?

Instead of creating missiles/units one-at-a-time when you need them; you allocate another batch of 32/64/128/etc objects when you run out of the currently allocated amount of objects?

I think that BogdanOntanu mentioned something about this (maybe in the old messageboard?) which is used in Hostile Encounter for allocating units/etc.

Cheers,
Scronty

heh. maybe I should have taken a look at the file first:tongue: .
Posted on 2002-01-11 09:35:41 by Scronty
So f0dder do you suggest that each batch should be a completely seperate chunk of memory or do you mean I should only realloc with certain sized chunks.

Also why do you recommend batchs of 32/64/etc, is that more efficient.

And finally what could be the consquences of the method I'm currently using, does it waste memory, or maybe slow down access.

Your insight is much appreciated. :)
Posted on 2002-01-11 18:55:48 by Eóin
Posted on 2002-01-11 19:11:36 by bitRAKE
Eo?n, realloc() is fine. Well, you'll still get some fragmentation, but
you'll hopefully get less when "batching" (new term to me), and the
nice thing is you'll leave larger holes, that can be reused by (new)
allocations.

The power-of-two sizes I've chosen are more or less arbitrary. I'm
a programmer, so I often use 2^x when I need a random number :grin:.
You want to choose a number that improves efficiency but doesn't
add too much slack.
Posted on 2002-01-12 01:40:42 by f0dder
Can I just describe how I manage the array with an example.
Posted on 2002-01-12 12:36:39 by Eóin