* [rshapes] Fix drawing circle sectors
Functions that draw a sector of a circle would keep drawing segments past a full rotation, which looked bad.
* [rshapes] Change `DrawCircleSectorLines()` and `DrawRingLines()`
`DrawCircleSectorLines()` and `DrawRingLines()` drew the cap lines even when drawing a full circle, which seems undesirable.
* [rshapes] Update `DrawRectangleLinesEx()`
Add support for negative `thick` values. When `thick` is negative, lines are drawn growing outside of the rectangle.
* [rshapes] Update `DrawPolyLinesEx()`
Add support for negative `thick` values. When `thick` is negative, lines are drawn growing outside of the polygon. Also refactored to explicitly use an `outerRadius` variable instead of using `radius` as the outer radius.
* [rshapes] Update `DrawRectangleRoundedLinesEx()`
Make the outline vertices easier to work with.
* [rshapes] Updated `DrawRectangleRoundedLinesEx()`.
Lines used to draw outside when `thick` was positive. Added support for negative `thick` values. When `thick` is negative, lines are drawn growing outside of the rectangle.
* [rshapes] Update `DrawRectangleRoundedLines()`.
Make the formatting of the points' x and y coordinates in DrawRectangleRoundedLines() match DrawRectangleRoundedLinesEx().
NOTE: raylib data validation policy defines not to validate any data that does not suppose a crash in the program, letting user manage that layer... probably several functions should be carefully reviewed or the policy itself...
Previously DrawRectangleLinesEx() would draw lines overlapping each other when they were thick enough (which was only noticeable if the color's alpha was lower than 255.)
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.
