Proposal: Arduboy2Base::drawBitmap overload

[Pharap]

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 with drawBitmap
  • This might make drawBitmap a more viable alternative to Sprites in some situations
• Much like with Sprites::getWidth and Sprited::getHeight, this hides pgm_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.)

[MLXXXp]

I see no problem with adding this. I'll add it to the ToDo for the next release.

[ace-dent]

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 🤷‍♂️

[Pharap]

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