This commit implements a big update of rlgl module, intended to optimize some parts. This change could break some code bases... hopefully not, but it could.
The BIG changes to the module are:
- Replaced LINES-TRIANGLES-QUADS buffers by a single one, now all vertex data is accumulated on a single buffer and managed with registered draw calls. LINES-TRIANGLES-QUADS could be used the same way as before, rlgl will manage them carefully. That's a big improvement of the system.
- Support multi-buffering if required. Just define MAX_BATCH_BUFFERING desired size (currently set to 1 batch). Should be enough for most of the situations.
- Removed temporal accumulative buffers for matrix transformations, now transformations are directly applied to vertex when on rlVertex3f()
- Reviewed rlPushMatrix()/rlPopMatrix() to be consistent with OpenGL 1.1, probably I should remove that ancient behaviour but... well, it was not consistent and now it is.
- Minor tweaks: LoadText(), I broke it in last update... also multiple comments reviewed.
- TODO: MAX_BATCH_ELEMENTS checking should probably be reviewed... done some tests and it works but...
raylib resource data file for Windows platform (containing raylib icon and metadata for executable file) has been renamed to a more consistent name: raylib.rc.data
Also required to work with tcc compiler.
Now `BeginTextureMode()` does not clean buffers automatically, that behaviour has been changed because there could be some case (i.e. painting software) where texture buffer does not ned to be cleared; user is responsible of clearing buffers using `ClearBackground()`
Useful for bitmaps pixelated fonts where anti-aliasing is not desired!
Change also enables additional font generation mechanisms in a future (cleartype, hinting...).
With the recent CMake cleanup, getting raylib's dependencies for use
when building rlgl_standalone is quite straight forward, so lets enable
it again.
Fixes#508, just properly this time. :)
Remove that link_libraries_to_executable() hack and defines a proper
raylib target that can be used with target_link_libraries.
The same target is also available for external (user) code by using
find_package(raylib).
This results in:
- Remove hardcoded build directories from examples and games CMakeLists.txt
- Allow rlgl_standalone and other special examples to be built easily
- Allow CMake projects to find_package(raylib instead of fiddling with pkg-config
- Makes code a little more maintainable
- Fixes#471, #606.
- Makes code less confusing by removing the double use of PLATFORM (#584).
Note that this is still not _The Right Way_(TM), because normally
raylib-config.cmake (or its includes) would be automatically generated.
I didn't manage to get that to work though, so I went the easier route
of just wrapping pkg_check_modules for consumption by find_package.
1. Always synthesize a complete frame of audio, using a second buffer (this prevents gaps in playback)
2. Sine is computed correctly, with an adjustable frequency
3. User can modulate frequency in real-time with mouse
4. Entire audio buffer data is shown, visually demonstrating how sine changes in wavelength
Examples can be compiled for web with no code change at all! Usually
examples need to be refactored for web... using emscripten code
interpreter (emterpreter), it can manage synchronous while() loops
internally... as a downside, execution is very slow...
This change allows rlgl.h usage as independent single-file header-only module... still some tweaks required, like removing GLAD dependency... required extensions could be manually loaded!
Also removed shader_distortion.h, embedded in rlgl.h
Currently, if:
* GCC doesn't supports -no-pie: Build error
* GCC supports -no-pie
* GCC is not configured with --enable-default-pie: No-op
* GCC is configured with --enable-default-pie:
Slightly worse performance because we still generate -fpie code
(-pie affects linker, -fpie affects compiler)
So instead of probing for existence of -fno-pie -no-pie, remove it altogether.
Fixes#540: Build breakage on Debian 8 with gcc 4.9.
- Added Vector3OrthoNormalize() to raymath.h - not sure if it is correct
- Implemented MeshBinormals() - Mesh struct has not a place for them...
- Updated model_material_pbr example - tested but not working on my GPU
(old Intel HD), actually, it never worked on it...
Renamed function for consistency with a possible Mesh manipulation functions (maybe added in a future). Naming follows Image*() manipulation functions.
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.
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.
- Renamed VERSION to RAYLIB_VERSION
- Renamed API_VERSION to RAYLIB_API_VERSION
- Renamed RAYLIB_RELEASE to RAYLIB_RELEASE_PATH
- Support Web Assembly compilation on PLATFORM_WEB
Updated to latest GLFW library and working on Wayland support, still
looking how to implement it on raylib because it just exposes
PLATFORM_DESKTOP and defaults to X11 windowing system on Linux...
OpenAL Soft backend is still available in audio module, I'm thinking if
exposing it for building in some way or just left it there for advance
users to switch to it manually in case of necessity...
They were disabled because they failed to build,
but this patch set fixes the build on Linux and macOS.
This doesn't apply to the AppVeyor build on Windows yet;
it currently fails at linking with OpenAL.
libEGL and libGLESv2 have been renamed on latest Raspbian Stretch
version (also included on latest Jessie upgrade).
It seems to be done to avoid conflicts between official Mesa libs and
Broadcomm provided ones.
Namely:
- GenImageHorizontalV
- GenImageHorizontalH
- GenImageChecked
- GenImageWhiteNoise
- GenImageCellular
The gradient implementation may be a bit naive, for example it doesn't do any gamma correction.
