- make sure that src/external/rl_gputex.h uses it's own macros
for printing warnings and allocating memory
- add few additional macros in order to decouple rl_gputex from headers
that are being included by Raylib (e.g. *_MEMSET, *_NULL and so on)
- make sure that rl_gputex uses RL_*ALLOC, TRACELOG and RLAPI macros
when (and only when) being included by src/rtextures.c
- replace LOG() and RL_GPUTEX_SHOW_LOG_INFO macros with: RL_GPUTEX_WARN
and RL_GPUTEX_SHOW_WARN_INFO (this is a breaking change, but it was
broken and unusable anyway, see:
https://github.com/raysan5/raylib/issues/5039#issuecomment-3065732596 )
- fixes issue all issues mentioned in:
https://github.com/raysan5/raylib/issues/5039#issuecomment-3065732596
- remove logging upon successfully saving a file; Raylib does this
anyway and we want rl_gputex to only print WARNings upon failures;
see: https://discord.com/channels/426912293134270465/541710686468702250/1394406734306480352
- add additional condition when saving a file; now checks for both
fwrite() and fclose() failures; before it would warn about both,
but only return result based on fclose()
- add some notes about the current state of compiling rl_gputex
without depending on Raylib (spoiler: it's still broken...)
- bump rl_gputex version to 1.1 since this is a potential breaking
change (only for people attempting to use it without Raylib)
Fixes: https://github.com/raysan5/raylib/issues/5039
Reference: https://discord.com/channels/426912293134270465/541710686468702250/1394403611852931255
I did this with the intention of fixing
https://github.com/raysan5/raylib/issues/5027
but it's hard to tell if it will help in that case or not.
Anyway, bumping the header with mappings should be done once in a while.
I haven't found any Raylib script for doing this, so here's how I did it
step-by-step with CMake rule provided by GLFW (I'm on Linux, but this
should be similar on any other POSIX system):
```sh
$ git clone https://github.com/raysan5/raylib.git
$ cd raylib/src/external/glfw/
$ cmake -B ./build -DGLFW_BUILD_EXAMPLES=OFF -DGLFW_BUILD_TESTS=OFF -DGLFW_BUILD_DOCS=OFF -G "Unix Makefiles"
$ make -C ./build update_mappings
$ rm -fr ./build
```
then I checked, if any mappings were deleted (without updating) with
following shell one-liner:
```sh
# you must be at 'raylib/src/external/glfw/' when executing this
$ for i in $(git diff ./src/mappings.h | sed -n -e 's/^-"\([0-9a-z]*\),.*$/\1/p'); do grep <./src/mappings.h "$i" > /dev/null || echo "$i"; done;
```
which gave me the following IDs:
```txt
0300000066f700000500000000000000
030000000d0f00001600000000007803
03000000efbe0000edfe000000000000
03000000786901006e70000000000000
050000005e040000e002000030110000
03000000790000000600000010010000
030000000d0f00000d00000000010000
030000000d0f0000d800000072056800
03000000c0160000dc27000001010000
030000008916000000fd000024010000
```
I have checked all those IDs with `git log -p` against
https://github.com/mdqinc/SDL_GameControllerDB
and it seems that all of them were deleted by upstream (I was afraid that
maybe some mappings were added manually by a Raylib contributor and then
overwritten by my patch, but they weren't; All good!)
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.
The original implementation created/destroyed framebuffers (FBs) per-frame, leading to kernel overhead and screen tearing. This commit replaces it with a different approach using:
- Asynchronous `drmModePageFlip()` with vblank sync
- Framebuffer caching to reduce repeated FB creation/removal operations
- Proper resource management through BO callbacks and buffer release synchronization
- Added error handling for busy displays, cache overflows, and flip failures
- Event-driven cleanup via page_flip_handler to prevent GPU/scanout conflicts
Co-authored-by: rob-bits
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.
