Signed-off-by: Per Hallsmark <per.hallsmark@bitjuggler.se>

* 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>

* [rmodels] Fixed null pointer dereference in LoadGLTF

* [rmodels] Add parenthesis around conditionals in LoadGLTF

* Update raylib.h: GeyKeyName prototype

Prototype for GetKeyName, which is already implemented elsewhere.

* Update raylib_to_parse.h: GetKeyName prototype

This reverts commit c53dd8a931.

* Improve cmake config file generation

This allows for finding raylib on a non-standard location (eg, not in /usr/lib{,64})

* Only have glfw as private if using internal glfw and not static

Co-authored-by: Listeria monocytogenes <listeria@disroot.org>

* increased vertex data precision to match blender exports

* modified memory allocation to better fit higher precision data

* now accounting for newline characters during allocation

* now accounting for potentially higher vertex counts

* removed unnecessary final newline

The nextShapeEnd integer is a pointer in the OBJ data structures.
The faceVertIndex is a vertex index counter for the mesh we are
about to create. Both integers are not compatible, which causes
the code to finish the meshes too early, thus writing the OBJ data
incompletely into the target meshes.

It wasn't noticed because for the last mesh, it process all remaining
data, causing the last mesh to contain all remaining triangles.

This would have been noticed if the OBJ meshes used different textures
for each mesh.

Tested with w64devkit/MSVC and all seem to work as expected

* [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

If we borrow from the GPU skinned animation code, we can just multiply the vertex by the matrix * weight and shave a chunk of CPU time.

Still, not fully convinced of those functions naming, despite quite descriptive, sounds a bit confusing to me...

When creating a new sphere mesh with high number of slices/rings the top and bottom parts of the generated sphere are removed. This happens because the triangles in those parts, due to high resolution, end up being very small and are removed as part of the 'par_shapes' library's optimization. Adding par_shapes_set_epsilon_degenerate_sphere(0.0); before generating the sphere mesh sets the threshold for removal of small triangles is removed and the sphere is returned to raylib correctly.