Presumably you have a lot more private repos than you do public.
I must admit the idea of only having public repos put me off at first,
but I soon realised that most of my public repos hardly ever get read anyway,
so effectively they’re as good as private.
Linked lists are rarely a good data structure to use.
On modern systems they thrash the cache, and even on old systems they have an awkard amount of overhead.
I’m going to throw out some unsolicited suggestions anyway.
Just disregard them if you aren’t interested.
I’d recommend looking into ways to avoid
As soon as you add
virtual functions it introduces a ‘vtable’,
which means an extra (hidden) pointer is added to the class and an array of pointers to functions is hidden somewhere.
(I haven’t determined if it ends up in progmem or in RAM though.)
Also I think inheritance in general can end up using additional memory by causing common code to be duplicated once per class in some cases,
but it’s been a while since I’ve tested that so I can’t remember the specifics.
Using inheritance for things like
Sprite are pretty much a no-go on embedded systems.
The amount of added overhead is generally too wasteful.
In the case of
Sprite, if you change your images to use the
Sprites format (i.e. prefix the image data with the width and height) and use the
Sprites::drawOverwrite instead of
arduboy.drawBitmap for rendering then you don’t need to keep the width and height in RAM.
As for flaggable, you’re quite possibly preventing functions from being inlined.
Flaggable being a parent class doesn’t really give you any benefit because the flags mean different things for different kinds of objects - i.e. it breaks the liskov substitution principle.
If you’re just using it for the sake of utility then you’d be better off using free functions rather than resorting to inheritance.
In many other OO languages free functions either aren’t possible or are sometimes frowned upon,
but in C++ they’re a viable alternative and sometimes an invaluable tool.
And you could provide a ‘magnitudeSquared’ function for your vectors so you can avoid using
sqrt in certain circumstances.
E.g. if you’re just comparing the magnitude of two vectors then you don’t need the exact magnitude,
you can compare the magnitude squared instead because the relative scale will be maintained.
That’s usually used as a speed ‘hack’, but could result in better memory usage in some circumstances.
Going off on a tangent briefly:
Talking about inheritance reminded me, the
GameObject approach is considered somewhat old fashioned these days due to its inflexibility.
Modern games tend to be moving towards ‘component-based architecture’.
The downside of the component approach is that it’s marginally more expensive,
but the amount of flexibility it affords greatly outweighs the downsides.
It’s not really applicable to an embedded system though,
it’s only really suited for desktop programming or at least reasonably powerful consoles.
Thought I’d mention it on the off-chance that it’s of interest.
By the way, your use of Font3x5 appears to be violating the licence because you aren’t including the licence and copyright notice.