Proposal: Arduboy2Base::drawBitmap overload
Pharap opened this issue · 3 comments
This is an idea I had some time ago and suddenly remembered while doing something else.
The idea is that it would be useful to provide an overload of Arduboy2Base::drawBitmap
that doesn't have width
and height
parameters, and instead extracts those from the image in the same way that the Sprites
functions do. I.e. it would be an overload that expects the same image format as the Sprites
functions.
Key thoughts:
- Allows the
Sprites
-format images to be used withdrawBitmap
- This might make
drawBitmap
a more viable alternative toSprites
in some situations
- This might make
- Much like with
Sprites::getWidth
andSprited::getHeight
, this hidespgm_read_byte
from inexperienced users. - Backwards compatible - since the new overload has fewer parameters, there's no conflict with any existing usage
Proposed implementation:
void Arduboy2Base::drawBitmap(int16_t x, int16_t y, const uint8_t * bitmap, uint8_t colour = WHITE)
{
uint8_t width = pgm_read_byte(&bitmap[0]);
uint8_t height = pgm_read_byte(&bitmap[1]);
drawBitmap(x, y, &bitmap[2], width, height, colour);
}
(Note: Intentionally does not rely on Sprites
to avoid introducing an unnecessary dependency.)
I see no problem with adding this. I'll add it to the ToDo for the next release.
When would this be useful?
I presume it may help early development, if switching from Sprites::drawOverwrite
<-> drawBitmap
, and not wanting to change the first 2 bytes of the image array...
Not sure how often anyone would do that?
As long as it doesn't increase compiled size of existing code- I guess it's harmless 🤷♂️
When would this be useful?
When someone wants to use drawBitmap
with a Sprites
-format image.
Sprites::drawOverwrite <-> drawBitmap
Arduboy2::drawBitmap
does not behave the same as Sprites::drawOverwrite
, it behaves like Sprites::drawSelfMasked
.
As long as it doesn't increase compiled size of existing code
Why would it? In C++ you don't pay for what you don't use - if you aren't using a function then it's not included in the final executable.
As I expressly stated in my proposal:
- Backwards compatible - since the new overload has fewer parameters, there's no conflict with any existing usage