Currently, every example fails linking likeso:
[ 3%] Linking C executable audio_mixed_processor
/usr/bin/ld: ../raylib/libraylib.a(raudio.c.o): undefined reference to symbol 'exp@@GLIBC_2.29'
/usr/bin/ld: /usr/lib/libm.so.6: error adding symbols: DSO missing from command line
collect2: error: ld returned 1 exit status
Apparently, linking libm explicitly is the solution.
Fixed a grammatical error by removing "are" to change `... but some are have multiple purposes ...` to `... but some have multiple purposes ...` in `textures/textures_image_generation`
The purpose of this directory in GLFW is to provide some headers that
"mingw.org" doesn't. Raylib has long been unable to build with mingw.org
due to using certain symbols that aren't exposed in their headers.
(_ftelli64 and _access, among others.). Mingw-w64 already has the
necessary headers included, and doesn't need any of these external
implementations. For some reason, this also causes the following error
when building with Visual Studio's clang:
clang -c rglfw.c -Wall -D_GNU_SOURCE -DPLATFORM_DESKTOP -DGRAPHICS_API_OPENGL_33 -Wno-missing-braces -Werror=pointer-arith -fno-strict-aliasing -std=c99 -O1 -Werror=implicit-function-declaration -I. -Iexternal/glfw/include -Iexternal/glfw/deps/mingw
In file included from rglfw.c:61:
In file included from ./external/glfw/src/init.c:30:
In file included from ./external/glfw/src/internal.h:331:
In file included from ./external/glfw/src/platform.h:31:
In file included from ./external/glfw/src/win32_platform.h:70:
external/glfw/deps/mingw\xinput.h:227:26: error: a parameter list without types is only allowed in a function definition
227 | void WINAPI XInputEnable(WINBOOL);
|
If the last -Iexternal/glfw/deps/mingw is removed, the build works fine.
So, this workaround causes other problems, while not actually helping
raylib.
0bb605cd79/src/CMakeLists.txt (L272-L279)
GLFW's CMakeLists.txt first checks if either dinput.h or xinput.h are
provided by the toolchain, before telling the compiler to search for
headers in that directory. For EVERY compiler that can build raylib,
this is true.
In summary: This directory causes issues when building with some
compilers, and every toolchain that needs this workaround can't build
raylib anyway.
* basic pbr example
pbr implementation includes rpbr.h and few shader files header only file, which self contain everything needed for pbr rendering. Few textures and one model of the car which is under free licence which is included inside basic_pbr.c example file currently supported shader versions are 120 and 330 , version 100 has small issue which I have to resolve
* Unloading PBRMAterial
I forgot unloading PBRMaterial
* fix small issue with texOffset assigment.
value was Vector4 at first but I found out it would be unclear for and users, so I change to have two Vector2 instead, but forgot to assign offset .
* Changed size of textures and file name changed
Changed size of textures from 2048x2048 to 1024x1024 and file name changed to shaders_basic_pbr.c ,
Added the function PBRModel PBRModelLoadFromMesh(Mesh mesh);
but GenMeshPlane(2, 2.0, 3, 3) culdn't be used because it crash once GenMeshTangents() is used with that plane mesh
* Update audio_stream_effects.c
This may slightly improve performance and be more welcoming for new users despite being an more advanced feature.
void * usually throws an error in most compilers and it would be better to just avoid it.
Also added <stdbool.h> because booleans are, sometimes, not defined by <stddef.h>.
* Update audio_stream_effects.c
* Added missing textures_image_kernel example in web makefile
* Added missing --preload-file for textures_image_kernel
---------
Co-authored-by: zap <zap@physlab.ru>
RENAMED: `DrawLine<spline_type>()` to `DrawSpline<spline_type>()` for more consistent and clear naming
REVIEWED: Bezier drawing parameters order, more consistent
REVIEWED: Spline-based examples -WIP-