If `innerRadius` is less than 0, it causes the outline to overlap itself and even grow outside of the polygon's bounds when `thick` is greater than `radius`. Clamping `innerRadius` to 0 fixes these problems.
In #5980 a bug was introduced for `DrawRectangleRoundedLines()`. `DrawRectangleRoundedLines()` previously assumed that `DrawRectangleRoundedLinesEx()` uses `RL_LINES` when line thickness is 1 (which is no longer true, it now uses `RL_QUADS` or `RL_TRIANGLES`.)
I copy/pasted the previous `DrawRectangleRoundedLinesEx()` implementation and trimmed it down (since now the line thickness is always 1), so now `DrawRectangleRoundedLines()` uses `RL_LINES`. This makes it consistent with all other `Draw*Lines()` functions, which use `RL_LINES`.
Redesigned to support disabling features on compilation with `-DSUPPORT_FEATURE=0`
REMOVED: `SUPPORT_DEFAULT_FONT`, always supported
REMOVED: `SUPPORT_IMAGE_MANIPULATION `, always supported
REMOVED: `SUPPORT_TEXT_MANIPULATION`, always supported
REDESIGNED: `SUPPORT_FONT_ATLAS_WHITE_REC` to `FONT_ATLAS_CORNER_REC_SIZE`
REVIEWED: Config values (other than 0-1) are already defined on respective modules
Other config tweaks here and there
Examining the code shows that the rectangle is drawn winding counterclockwise, starting
with the top left. Therefore the colors used should be in the order: topLeft, bottomLeft,
bottomRight, topRight.
However, the variables actually being used are topLeft, bottomLeft, topRight,
bottomRight. I was confused by this as I was getting striping where I didn't expect any.
Put another way, the last two parameters are misnamed.
This diff swaps the parameter names and their usages. The result is that no runtime
behaviour changes: the same parameter order yields the same visual result both before and
after this change, but the parameter names now correctly reflect what they are actually
used for.
You can actually see this in the implementation of DrawRectangleGradientV, which
(correctly) passes top, bottom, bottom, top to DrawRectangleGradientEx.
Prevents unnecessary work and division by zero (when segments=0) in DrawCircleSector/DrawCircleSectorLines when startAngle equals endAngle, matching existing behavior in DrawRing/DrawRingLines.
