ICE 0.1: a moddable shoot-em-up in D

Kiith-Sa kiithsacmp at gmail.com
Thu Dec 20 15:06:34 PST 2012


On Thursday, 20 December 2012 at 22:45:10 UTC, Benjamin Thaut 
wrote:
> Did you do something special about the GC?
> Does it run at all or do you somehow pool your objects?
>
> Kind Regards
> Benjamin Thaut

I do use the GC; however, in general, I avoid using it for 
anything
that gets called very often; e.g. once per entity per frame.
Code that calls the GC once per frame is not a problem.

The game entities are composed of components (disjoint in memory;
every component type has a manually allocated array of all 
components of
  that type, and an entity has indices into these arrays), which
are structs. When some action triggers an entity spawn (in 
SpawnerSystem,
one of subsystems working on entities), an EntityPrototype - 
(struct
of components, not yet an entity) is either reused or allocated. 
I preallocate
a large number of these. Once the time comes for the entity to 
appear in the game, components from the EntityPrototype are 
copied to their respective arrays.
These arrays are once again preallocated, and if they run out of 
space, they are enlarged. These are actually "segmented" (arrays 
of arrays), so I never reallocate, just allocate a next segment.

Overall, memory allocation is no longer a concern.
Actually, GC was never a problem (I always worked with the rule -
if called many times per frame, don't use GC). However, manual 
allocation
_was_ a problem; until I rewrote most of the code to preallocate.
The worst case I had with the GC was about 10% of total time;
now both GC and manual allocation is below 1%. Actually; just
profiled (two-level game)- GC about 0.2% ; malloc & friends about 
0.4%.

In some cases I use pooling for structs that get 
created/destroyed often;
these usually are arrays stored within components, e.g. 
WeaponComponent, which might have any number of weapons. I do 
this in a very hacky way, using
an allocator template argument for my (custom) collections; this 
allocator
is generally static and specific for type being allocated.


More information about the Digitalmars-d-announce mailing list