I’m concerned about the use of dynamic allocation and virtual functions.
Those things both chew up RAM and progmem in large quantities.
I speak from experience. I created a similar system for Minesweeper.
How/why they eat memory
Dynamic allocation adds a speed cost, a RAM cost and a progmem cost:
- Allocating memory can be slow depending on the implementation. Often it involves stepping through unallocated blocks to find a block large enough
- There’s an overhead for every allocated memory block. Typically that consists of at least the size of the allocated block and possibly an offset to another block (to allow walking the block list like a linked list)
delete are backed by
free, meaning those functions have to be compiled and included in the output. On top of which, every time
delete are called, that call itself requires extra calling code.
Virtual functions also add overhead:
- They add an implicit pointer to every instance of a class that has a virtual function
- The implicit pointer must be initialised every time an object of the class is constructed
- To work, everay function needs a virtual function table, which eats quite a bit of progmem
- Every time a virtual function is called, an indirect call must be used, which is more expensive
There’s also the fact your
ArduText class is using a 64 character buffer instead of just storing a pointer to the text and the size of the text.
If you just stored the pointer and the size, it would cost 4 bytes instead of 64 bytes.
Though it would make it difficult to store integers.
You could also make a version of
ArduText that accepts pointers to text in progmem rather than storing the text in RAM.
Don’t get me wrong, this system would be fine on a desktop,
but on the Arduboy it’s going to eat a lot of memory,
and thus reduce the size of the game you can make with it.
It will probably be alright for small games, but not large games.