Added support for multicolor pixmaps in drawRGBBitmap.

[marcmerlin]

This adds support for multicolor bitmaps as supported by my software PWM matrix driver

[marcmerlin]

You can find example code using this new library call here:
https://github.com/marcmerlin/LED-Matrix/blob/master/examples/directmatrix8x8_bicolor_direct_sr/directmatrix8x8_bicolor_direct_sr.ino

[marcmerlin]

I just had one of my users confused because he was using the wrong GFX library (yours, not mine) and I just realized that I still have a fork from you because of this patch.
Since this is a generic function for your generic GFX library, would you be willing to add it?

[marcmerlin]

As a followup, I have tested this code with adafruit_neomatrix, and it works out of the box.

[PaintYourDragon]

Just heading out for a weekend thing but will have a good look and likely merge this when I get back. I've been hesitant to add 565-specific functions to core GFX, but after some things went not-so-well in one of the subclasses, this might just be the way to go. Tangent ideas are brewing, this'll be a good starting point. Thanks!

[marcmerlin]

@PaintYourDragon thanks for the reply. For what it's worth, this code is not 565 specific at all. I wrote it for my own backend that happens to be 444 BGR and then used it unmodified on 565 RGB neomatrix and it just worked for both because it passes the 16 bits of colors unmodified without caring how they are interpreted by the backend after that.
I agree that it won't work for 24bit color, but my understanding is that adafruit-gfx doesn't really deal well with that anyway, and that 24bit color is kind of overrated for many displays anyway as one of your pages explains (i.e. you can't tell the difference from more bits)
Enjoy your weekend :)

[marcmerlin]

During testing, I found it helpful to be able to display bitmaps that have been generated or modified in RAM, so I made a small change to allow this.
I've tested it in 328p with NeoMatrix and it works fine with and without progmem.

[marcmerlin]

Neomatrix demo that uses this code: https://github.com/marcmerlin/Adafruit_NeoMatrix/tree/master/examples/MatrixGFXDemo

[pacav69]

this issue was raised over 2 years ago i think it would be prudent to add this minor change to this wonderful library.

[marcmerlin]

@pacav69 . He already replied that he was going to review it soon. Please give him a chance to :)

[pacav69]

@marcmerlin i know i just thought i would give him a nudge and give you a helping hand as it is most annoying that i have to use a different version so that i can compile your code.

[marcmerlin]

Hi @PaintYourDragon I now have 3 different demos on 3 different backends that depend on this patch. It is nice to be able to display multi color pixmaps on totally different backends that happen to support Adafruit::GFX even though they don't even have the same color bit depth.
Obviously, it would be very nice to have it integrated, more things are depending on it.

[marcmerlin]

@PaintYourDragon
Ok, this code has now been tested on 328p, Teensy 3.1 and ESP8266 with 3 different Adafruit GFX backends that kind of rely on this now, for their demos: my own ( https://github.com/marcmerlin/LED-Matrix/ ), NeoMatrix, and RGB-matrix-Panel
Honestly, not being able to display RGB pixmaps on those backends is pretty limiting and this patch fixes this with very little code.
Could you please merge, and this will then also unblock the other demos I've submitted (which you are welcome not to merge, I'm just giving those out for people who care for better demos/examples)

[marcmerlin]

Thanks a bunch.

[PaintYourDragon]

Thanks for your patience, was handling a variety of other things.

Minor detail, I might go in and tweak this to have separate const (PROGMEM) and non-const (RAM) versions, consistent with the existing drawBitmap() functions, rather than the extra parameter.

[marcmerlin]

Understood. If you do so, I'll modify the code that calls into it and send updated demo patches, no problem at all.

[PaintYourDragon]

OK yeah, for consistency with other bitmap-related functions I've broken it out into PROGMEM- and RAM-resident versions of the function (instead of a trailing progmem argument).

Also added a variant that lets you additionally pass a bitmask to make non-rectangular overlays.