On Android (AAudio) the callback thread could still run when the mutex was
destroyed, causing a SIGABRT (pthread_mutex_lock on a destroyed mutex).
Uninit the device first so its callback thread stops before ma_mutex_uninit.
When the activity is destroyed while the app is paused, PollInputEvents
kept looping after setting CORE.Window.shouldClose: while paused,
ALooper_pollAll is called with an infinite timeout (-1), so on the next
iteration it blocked forever waiting for an event that never arrives.
main() never returned, the native thread stayed alive, and the following
launch hung inheriting that thread.
* [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.
* rlsw config section
* use raster flags to define rasterizer variants
* simplifies the generation of dispatch tables
* single dispatch table for the lines
same logic as for the points
* internal color interp state
* check whether vertex colors should be interpolated
* vector op helper macro + pick sampler once before primitive drawing
* op order tweaks
* refactoring without gotos for triangle and quad rasterizers
* same cleaning for the lines
* pico doesn't implement time.h
* add option for RLSW to hold a back buffer, and give it a sw method to swap
* Remove unused pointer and give swSwapColorBuffers a default nop-behaviour
* Fix compilation by removing old colorBackBuffer setters
* use the correct logger
* return line
* rename RLSW_BACKBUFFER to SW_DOUBLE_BUFFERING
* Fix DrawSphereWires (Less aggressively)
Summary:
- Eliminated some redundancies
- Fixed a bug(?) where the sphere would have 1 more "ring" (latitude division) than expected
- Fixed a bug where the top ring was double-covered
- Added comments denoting which code draws which lines
* DrawSphereWires + DrawSphereEx parity
Summary:
- Replaced DrawSphereWires algorithm with one based on the much faster algorithm from DrawSphereEx
- Fixed +1 ring quirk on DrawSphereEx to match the change made to DrawSphereWires
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`.
