* Fix borderless fullscreen always on top
Don't pass a monitor to glfwSetWindowMonitor(). This avoids setting the flag which keeps the window always on top.
* Update for borderless-windowed always on top bug
Only apply the fix for Windows OS, since that seems to be the only
platform with the issue.
* Update GLFW to 3.5.1
* Remove cocoa_time.c from rglfw.c
* Add macos_time.c to rglfw.c
* Redo changes from pull request #3863
* Makefile: add QuartzCore framework when building for macOS
* Add QuartzCore when building for macOS to other build files
* Remove unused GLFW dependencies
GetPoseAtTimeGLTF searches for the interval containing the requested time
with (tstart <= time) && (time < tend). A time equal to the last keyframe
satisfies no interval, so the loop ends without a match and keyframe stays
at its 0 default, making the function return a pose from the beginning of
the animation.
LoadModelAnimationsGLTF samples at t = j/60 for j in [0, keyframeCount),
with keyframeCount = (int)(duration*60) + 1, so the last sample lands
exactly on the end of the animation whenever duration*60 is a whole
number. The last pose of those clips is wrong, which looks like a jerk
right before the animation ends.
Measured on a glTF with a 0.85 s clip: the delta between the last two
poses was 23x the median delta between consecutive poses; with this
change it is 0.3x, in line with every other step.
* [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.
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`.
