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…
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.
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…
Width, height and radius are typed to
Open an issue @Olmy! It seems like there is already lots of discussion
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.
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 )