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.
Restore window currently says it sets the window state to:
"not minimized/maximized"
However, if a window is maximized and then minimized, it's typical that
it would restore back to being maximized, which is what seems to happen
from my testing. I've reworded the description to better reflect
this behavior.
Lately got some compilation `errors` related, it seems GCC 14 interprets some `const`-missmatch as errors instead of warnings (as previous versions).
But in any case, I don't see why an user won't be able to operate directly over of those returned buffers; `const` adds a restriction (for security reasons?) that in my opinion is useless.
From an expert on compilers (w64devkit creator), here there are some notes I agree with:
```
No const. It serves no practical role in optimization, and I cannot recall an instance where it caught, or would have caught, a mistake. I held out for awhile as prototype documentation, but on reflection I found that good parameter names were sufficient. Dropping const has made me noticeably more productive by reducing cognitive load and eliminating visual clutter. I now believe its inclusion in C was a costly mistake.
(One small exception: I still like it as a hint to place static tables in read-only memory closer to the code. I’ll cast away the const if needed. This is only of minor importance.)
```
Ref: https://nullprogram.com/blog/2023/10/08/
* Make sure ShaderUniformDataType matches rlShaderUniformDataType
* Update raylib_api.* by CI
---------
Co-authored-by: github-actions[bot] <github-actions[bot]@users.noreply.github.com>
Co-authored-by: Ray <raysan5@gmail.com>
* [rcore] add 'GetClipboardImage' for windows
* [rcore] GetClipboardImage removed some unneeded defines
* [rcore] PLATFORM_SDL: create a compatility layer for SDL3
* external: add win32_clipboard.h header only lib
* [rcore] using win32_clipboard on platforms rlfw and rgfw
* [rcore] fix warnings in SDL3 compatibility layer
* Makefile: Allow specifying SDL_LIBRARIES to link, this helps with SDL3
* Makefile: examples makefile now compile others/rlgl_standalone only when TARGET_PLATFORM is PLATFORM_DESKTOP_GFLW
* Makefile: examples makefile now compile others/rlgl_standalone only when TARGET_PLATFORM is PLATFORM_DESKTOP_GFLW
* [rcore]: PLATFORM_SDL: improve clipboard data retrieval
* external: remove unused function from win32_clipboard.h
* Makefile: allow for extra flags necessary when compiling for SDL3
* [rcore]: fix string typo
* [rcore]: Properly handle NULL dpi passing. As is allowed in SDL2
* external: fix arch finding on win32_clipboard.h to allow compilation on msvc cmake CI
* [rcore]: PLATFORM_SDL: Treat monitor as an ID in SDL3 as opposed to an index as in SDL2
* [rcore]: typo
* Remove the panorama cubemap layout, it was not implemented.
Left a todo in the code for some aspiring developer to finish.
* Update raylib_api.* by CI
---------
Co-authored-by: github-actions[bot] <github-actions[bot]@users.noreply.github.com>
Ray