Bug in Arduboy::drawRoundRect() with small rectangles

if your rectangle is smaller than the rounded edges, for example a 2 pixel wide round rectangle. While trying to compute the sizes for the corners and edges you need up with a bunch of unit8_t type underflows, which results is a LARGE rectangle… aka 2-4 = 253 type of things…

I’ll do up a generalized fix and then figure out how to contribute the change back to the library unless somebody else has already got a fix in flight…

B

1 Like

Please also file an issue on github to track this:

Honestly the right answer here simply might e don’t use round rectangles for small rectangles… adding bounds check code ofr obvious cases that can be caught by testing that don’t cause crashes just slows down things for the 99% who will never run into the problem.

What type of solution did you have in mind?

Maybe just add a comment to the code so if people have this issue and they look into the library they will at least understand whats going on?

That would be my suggestion. :slight_smile:

Every programmer just died a little inside. @olmy, go ahead and make the PR, there are other contributors that might have different opinions. Plus you can get the github points. The worst that happens is it is decided a comparison check on an 8-bit value causes the processor to melt and it’s not merged.

Except x and y are typically passed as 16-bit values… :slight_smile:

1 Like

Width, height and radius are typed to uint8_t yeah?

Open an issue @Olmy! It seems like there is already lots of discussion :smiley:

how about if its under a certain bounds it just draws a normal rect or a circle perhaps? I mean, is it bad if I didn’t even know we had a draw rect function before I read this thread?

Lets get an issue first and a proposed solution (there was a hint there was some idea what SHOULD be done) and then see if it makes sense in the grand scheme. I just think there is a danger of going overboard with bounds checking - and on a tiny embedded platform that can really sap your speed… so for things where the UI is obviously glitched and should be caught by a developer while building a game I’m less inclined to “protect” that than I am to protect something that could result in a hard crash.

But lets get an issue and look at it. :slightly_smiling:

1 Like

It’s not hard to imagine a game with an object that’s dynamically sized, and not every possible size comes up in testing. Seems worthy of a discussion at least… (as seems to be happening :slight_smile: )

1 Like