remapFn for non-rectangles fails *CONTAINS FIX*

[marcmerlin]

remapFn for non-rectangles fails *CONTAINS FIX*

[marcmerlin]

Interesting. normally when I've seen such code, no one writes in the cells that aren't mapped to any hardware pixels, so it's not an issue (you can assign them to 0 instead of -1)

So basically you recommend that I edit
Framebuffer_GFX::drawPixel
and have this instead
uint32_t idx = _fb[XY(x,y)];
if (idx<0 || idx>numpix) return;
_fb[idx] = passThruFlag ? passThruColor : expandColor(color);

I'm not sure how I feel about returning fake index values, when you could just return 0 on empty cells, or numpix-1, or have a empty pixel (define numpix+1 and the last pixel isn't actually there, but exists in the array), but I guess it doesn't hurt to have defense in depth and reject bad mappings either.

If you'd rather keep using -1, can you check the code I just gave you and confirm it fixes your issue?

[jrork]

uint32_t idx = XY(x,y);
if (idx<0 || idx>numpix) return;
_fb[idx] = passThruFlag ? passThruColor : expandColor(color);

--and--

uint32_t idx = XY(x,y);
if (idx<0 || idx>numpix) return;
_fb[idx] = color;

...works. The code above still crashes as it returns the value of _fb[XY(x,y)] instead of XY(x,y);

0 and numpix-1 are both visible pixels. I've tried the led(numpix+1) trick but it can become a hassle to maintain when setting up the matrix numbering. As you noted, this is a very unusual use case and was difficult to find a working example to pattern off of. However, the examples I did find used -1, and it also makes it much easier to visualize the layout when looking at the array initialization.

Thanks Marc, and thank you for the great libraries! I'll do a post when I'm complete

[marcmerlin]

Ok, thanks for confirming. I'll apply #1 then.

[jrork]

For clarity, i was attempting (and failing) to point out that the fix needed to go into two different places...

[marcmerlin]

Ooops, sorry. This should be better.
Next time, feel free to send a PR so that you can get credit for your change :)

[jrork]

This is my first ever, so didn't realize I could/should do a PR. Next time...

Thanks again!

[marcmerlin]

1. could => you always can :)
2. should => there is no rule, any contribution is welcome, even if it's a bug report without a fix :)

Basically you can contribute to whichever level is interesting and/or challenging to you, and if you send a PR, you get your name in the git history :)
After some amount of that, you may end up writing your own library and share it with others too.

[jrork]

If you don’t mind waiting a few moments to learn how to do that, I will create one and appreciate the opportunity to “contribute" to your amazing library!

…

On Wednesday, Mar 17, 2021 at 4:42 PM, Marc MERLIN ***@***.*** ***@***.***)> wrote: could => you always can :) should => there is no rule, any contribution is welcome, even if it's a bug report without a fix :) Basically you can contribute to whichever level is interesting and/or challenging to you, and if you send a PR, you get your name in the git history :) After some amount of that, you may end up writing your own library and share it with others too. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub (#9 (comment)), or unsubscribe (https://github.com/notifications/unsubscribe-auth/ABAMVLFHAMY4SI76POJ4X7TTEEH5DANCNFSM4ZHTDKRA).

[marcmerlin]

the fix is already in, so no need to send it again (or send stuff that doesn't really need to be in), but if you find another bug or you want to add a worthwhile addition (and that's more tricky, because I get to decide whether it makes sense to add, or not :) ), feel free

[jrork]

Ah, too slow. Thanks for being so responsive in the fix!

…

On Wednesday, Mar 17, 2021 at 5:08 PM, Joseph Rork ***@***.*** ***@***.***)> wrote: If you don’t mind waiting a few moments to learn how to do that, I will create one and appreciate the opportunity to “contribute" to your amazing library! > On Wednesday, Mar 17, 2021 at 4:42 PM, Marc MERLIN ***@***.*** ***@***.***)> wrote: > could => you always can :) > should => there is no rule, any contribution is welcome, even if it's a bug report without a fix :) > > > Basically you can contribute to whichever level is interesting and/or challenging to you, and if you send a PR, you get your name in the git history :) > After some amount of that, you may end up writing your own library and share it with others too. > > > — > You are receiving this because you authored the thread. > Reply to this email directly, view it on GitHub (#9 (comment)), or unsubscribe (https://github.com/notifications/unsubscribe-auth/ABAMVLFHAMY4SI76POJ4X7TTEEH5DANCNFSM4ZHTDKRA). > > >

[marcmerlin]

but in the meantime, you can send me details on your project when it's up and running :)

[marcmerlin]

look in the history of this issue for
marcmerlin closed this in marcmerlin/Framebuffer_GFX@e14e11a 3 hours ago
marcmerlin added a commit to marcmerlin/Framebuffer_GFX that referenced this issue 2 hours ago
and click on both