I've introduced the foundational infrastructure for a Vulkan rendering backend in raylib.
Key changes:
- CMake:
- I added a `SUPPORT_VULKAN` option (default OFF) to enable Vulkan.
- It finds the Vulkan SDK and links appropriate libraries when enabled.
- I defined `CF_VULKAN_` (0 by default, 1 if Vulkan enabled) and `GRAPHICS_API_VULKAN` preprocessor macros.
- I updated `LibraryConfigurations.cmake` and `src/CMakeLists.txt` to handle Vulkan as a graphics API.
- Vulkan Abstraction Layer:
- I created `src/rlvk.h` and `src/rlvk.c` with stub implementations for Vulkan rendering functions (e.g., `rlvkInit`, `rlvkClose`, drawing functions). These are compiled only when `SUPPORT_VULKAN` is ON.
- Core Integration:
- `rlgl.h` and `rcore.c` now have conditional code paths for `GRAPHICS_API_VULKAN`.
- `InitWindow` and `CloseWindow` in `rcore.c` call Vulkan-specific platform and backend initialization/deinitialization stubs.
- Platform Layer (GLFW):
- `src/platforms/rcore_desktop_glfw.c` includes stubbed `InitPlatformVulkan` and `ClosePlatformVulkan` to set up GLFW for a Vulkan context (actual Vulkan instance/surface creation is stubbed).
This commit establishes the necessary build system changes and C code structure to allow for the incremental implementation of the Vulkan renderer. Currently, enabling Vulkan will compile the stubs, allowing your application to run but without actual Vulkan rendering. The `CF_VULKAN_` flag controls the compilation and selection of Vulkan as the default renderer when active.
I believe it makes sense to only do this when there are no known
touch points. I am not even sure if this should be done at all.
See https://github.com/raysan5/raylib/issues/4872 for more information.
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.
raylib app crashing when started and a gamepad is already connected to the PC (even if the gamepad is not used in the app). I only tested this with a gamepad that has a layout which is not recognized. Using SDL3 as backend.
Raylib allows for providing custom allocators via macros.
GLFW supports this too, but via function pointers.
Make sure that GLFW uses those Raylib macros, by wrapping them in
function calls and setting them up inside of InitPlatform().
This is possible because of glfwInitAllocator() and GLFWallocator.
Fixes: https://github.com/raysan5/raylib/issues/4776
Relates-to: https://github.com/raysan5/raylib/issues/4751
This change is replacing the hardcoded "#canvas" element references in
rcore_web to allow using canvas elements that use different names
(which is necessary when using multiple canvas elements on one page).
Also adding a cursor hiding example to mouse example.
