While refactoring the animation editor, I tasted a new design pattern as an alternative to the usual Singleton pattern: the Using* anti-pattern. The idea was simple: for every item that needs to be there one and only one time, there is a class who has the sole responsibility for holding the variables describing that item. Let's take for instance the hardware sprites of the Nintendo DS. We have an array of 'sprites', an array of 'rotations' and a z-order list.The Using* anti-pattern said "these 3 should be static members of UsingSprites, and any code who needs to access them (read or write) will derive from UsingSprites". What it guarantees, is that if something messed up with * global, shared state, then that something is in one of the classes Using*. The one nice thing, is that code in those sub-classes can access the array quite directly: the location of UsingSprites::sprites is stored next to the functions that need it and it just needs a ld r*, [pc, offset] to be ready to use it. No additional pointer dereferencing required. This is the very same as accessing e.g. the address of a constant string (ARM thumb code doesn't seem to have mov reg, imm32 instruction).What I hadn't foreseen when I decided to generalise that to the whole game engine, is that a) there would be so many Using* for simple classes such as an animation and b) that they would all introduce a virtual table where the pointers to virtual methods for that class are stored.
The issue with th...