Fixed an issue where the mouse position was inaccurate when the raylib library was compiled to WASM for web pages.
Problem Cause:
Upon investigation, the issue was determined to be caused by glfwSetCursorPosCallback (which is emulated in the WASM environment) returning the mouse position relative to the initial canvas size created during the InitWindow call. This means that even if the canvas element's size on the web page changed (e.g., after a window resize via CSS or JavaScript), glfwSetCursorPosCallback would still report mouse positions based on the original, fixed canvas dimensions. This led to incorrect mouse coordinates calculated by raylib's internals when the web page was not full-screen or when the Canvas element's size was dynamic.
Fixes a regression since 5.5, where `ScanDirectoryFilesRecursively` no
longer does the "recursively" part due to `path` being `static`.
The issue was once already fixed in
5530a3ceb8
but recently made it back it in.
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.
