| Age | Commit message (Collapse) | Author |
|---|
|
It has no sense to be inside LoadOBJ(), mesh processing moved to own functions: MeshTangents() and MeshBinormals(). Not exposed to user yet.
|
|
Found by LeakSanitizer in #494.
|
|
$ make clean
Makefile:296: *** missing separator. Stop.
|
|
Fixes UB in #489, found by UBSan.
|
|
Width specifier doesn't include NUL terminator.
Fixes #487 found by AddressSanitizer.
|
|
jar_xm.h does some shady pointer casts leading to unaligned accesses
and breaking strict aliasing. x86 has special circuitry for doing
unaligned accesses, but on other architectures, it may trap and require
kernel fix-up or crash outright. With this patch, one obstacle in
porting raylib to the GameBoy Advance has been removed. Go for it ;-)
To avoid having to rewrite that `mempool' code, insert padding before
structs and instruct the compiler (GCC, most importantly), to be gentle
when optimizing.
This fixes #490 (Unless we got ourselves 256-bit pointers, if so,
hello future!)
|
|
RAYMATH_EXTERN_INLINE was renamed to RAYMATH_HEADER_ONLY, which user code
may define if they want to use it as header-only library. If multiple
files in the same project define RAYMATH_HEADER_ONLY, they might each
have duplicate out-of-line definitions of the same functions.
By default, raymath.h exposes inline definitions, which instructs the
compiler _not_ to generate out-of-line definitons, if out-of-line
definitions are required, those of the file defined with
RAYLIB_IMPLEMENTATION are used instead. There may be only one such file.
In C++ mode, the compiler will select only one out-of-line definition
automatically, so no need to define a RAYLIB_IMPLEMENTATION.
Unfortunately, we have to remove raymath function declaration from
raylib.h as those declarations would lead to duplicate out-of-line
definitions which would yield linker errors. This problem didn't
exist with GNU89 or C++, because there multiple defintions are ok,
but in C99 they aren't.
|
|
Besides making it thread-safe, it suppresses a GCC warning
when making them static inline in an upcoming patch.
|
|
|
|
This reverts commit 6ffc8cb7990fb4ff40f205cb53bec797b10e48a2.
and commit e4d7bbec1ef08279495ac41f5f8c4be359c58cf0.
which I pushed by mistake...
|
|
To make bugs like #485, #486, #487 and #488 easier to find in future.
|
|
RAYMATH_EXTERN_INLINE was renamed to RAYMATH_HEADER_ONLY, which user code
may define if they want to use it as header-only library. If multiple
files in the same project define RAYMATH_HEADER_ONLY, they might each
have duplicate out-of-line definitions of the same functions.
By default, raymath.h exposes inline definitions, which instructs the
compiler _not_ to generate out-of-line definitons, if out-of-line
definitions are required, those of the file defined with
RAYLIB_IMPLEMENTATION are used instead. There may be only one such file.
In C++ mode, the compiler will select only one out-of-line definition
automatically, so no need to define a RAYLIB_IMPLEMENTATION.
Unfortunately, we have to remove raymath function declaration from
raylib.h as those declarations would lead to duplicate out-of-line
definitions which would yield linker errors. This problem didn't
exist with GNU89 or C++, because there multiple defintions are ok,
but in C99 they aren't.
|
|
Besides making it thread-safe, it suppresses a GCC warning
when making them static inline in an upcoming patch.
|
|
Added struct Vector4 for convenience
|
|
When UnloadModel() --> UnloadMaterial(), avoid unloading default shader (if used) and avoid unlaoding default texture (if used), that data is managed by raylib internally. The question is... should UnloadModel() also UnloadMaterial()?
|
|
|
|
|
|
|
|
Apparently, before macOS Sierra version, clock_gettime was not available, using MATCH timming system instead
|
|
|
|
Supported UTF8 range equivalent to [128..255] (80h..FFh)
Exposed and renamed text function GetGlyphIndex()
Renamed spriteFont parameter name to simply font
Small security check on transmission mission ending screen
|
|
They were named so for compatibility with make, but make doesn't use
the anymore. I always forget whether it's SHARED_RAYLIB or
RAYLIB_SHARED...
For now, RAYLIB_SHARED and STATIC_RAYLIB may still be used,
but print a deprecation warning.
|
|
Rename: GetHexValue() renamed to ColorToInt()
Added: ColorToHSV()
|
|
|
|
|
|
|
|
These changes are intended to provide context and control over the Linux make install process. make install RAYLIB_LIBTYPE=SHARED now works as expected. libraylib.so is properly installed with attendant runtime links. The examples will be running against the newly installed libraylib.so unless otherwise specified with RAYLIB_RUNTIME_PATH. See raylib/src/Makefile and raylib/examples/Makefile for usage of RAYLIB_INSTALL_PATH, RAYLIB_H_INSTALL_PATH, and RAYLIB_RUNTIME_PATH variables. RAYLIB_RUNTIME_PATH in particular is interesting for portability since sudo isn't needed.
The default configuration and workflow is essentially unchanged and unaffected.
|
|
|
|
If user doesn't build the static library,
`pkg-config --static --libs raylib` should be equivalent to
`pkg-config --libs raylib`.
|
|
Fixes this build failure:
http://www.cpantesters.org/cpan/report/a069fade-0e1f-11e8-a1cf-bb670eaac09d
|
|
|
|
|
|
- Some functions renamed
- Comments reviewed
- Functions reorganized
|
|
Otherwise we may run into LoadDefaultFont and crash in rlLoadTexture
Also moves InitTimer() before InitGraphicsDevice(), to allow it to be
tested even if InitWindow ultimately fails.
|
|
|
|
Otherwise we run into an assertion failure inside GLFW's glfwGetVideoMode.
Example:
http://www.cpantesters.org/cpan/report/b4ba5894-0bdb-11e8-841e-2c60b04e1d2d
This is related to #456.
|
|
Allows loading of shader from text code string directly
|
|
|
|
|
|
|
|
Note that this version is under development and could be buggy on some
platforms...
|
|
|
|
In case graphic device could not be created it returns false instead of
failing with an error tracelog (and consequently closing the program).
Window initialization success could be checked with new function
IsWindowReady()
|
|
You can't do much with raylib if glfwInit or glfwCreateWindow fails,
currently it just exits by means of TraceLog(LOG_ERROR.
User code, however, might want to fall back to a text-only UI
or display a warning if raylib can't be used.
|
|
glfwSetWindowPos was called on a NULL window, triggering an assert
inside GLFW. Check for failure and exit cleanly by means of
TraceLog(LOG_ERROR instead.
|
|
-DWITH_SYSTEM_GLFW=ON: Link against system glfw and fail otherwise
-DWITH_SYSTEM_GLFW=OFF: Use embedded rglfw.c
-DWITH_SYSTEM_GLFW=IF_POSSIBLE: Probe for system glfw but fallback to
rglfw if unavailable
Also change Linux 64-bit CI build to install system glfw and use it,
so this doesn't bitrot.
Addresses #453.
|
|
|
|
|
|
|
|
|
