clang was complaining about the type conversions. For example...
```
node_modules/raylib-src/src/core.c:1888:15: error: cannot initialize a variable of type 'char *' with an
rvalue of type 'void *'
char *cmd = calloc(strlen(url) + 10, sizeof(char));
^ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
```
When capturing framebuffer, if some element with transparency has been drawn, it retrieves that data... it could be a bit annoying in some situations because we could expect color compositing with background color... It depends on the situation and our needs... but most of the time we don't want that transparency on screenshots.
This specific change could be very annoying for people already using FLAG_MSAA_4X_HINT, their programs will compile correctly but window won't be shown...
Planning to promote raudio module as a simple and easy-to-use front-end for the amazing mini_al library, so the name change.
Name comes from raylib-audio but in spanish it also remembers to word "raudo", meaning "very fast", an analogy that fits perfectly to the usefulness and performance of the library!
Consequently, raylib version has been bumped to 2.4-dev.
glfw/glfw@5595fa3ae6 implements a proper fix for the macOS Mojave
problem of OpenGL windows not being rendered until moved or manually
updated.
Pull in the current master and rebase the three patches we have on top:
- two commits we have for reuse of the GLFW CMake build system for Wayland
It hasn't yet to be acknowledged upstream.
- one commit removing #include <windows.h> in glfw3native.h to avoid
duplicate declarations.
Fixes#655 and #665.
Specific textures generation code is quite redundant and not flexible for the user, I'm trying to figure out some easy way to allow raylib users to do the same without needing those functions (very specific and shader dependant). RenderTexture loading and Cubemap textures support must be improved.
Decided to allow user to provide values directly instead of requiring a Vector2 struct, probably more confortable to use.
- SetMousePosition()
- SetMouseOffset()
- SetMouseScale()
funopen is only needed on Android, so declare it
only there. This fixes following MinGW build failure:
utils.c:50:7: error: conflicting types for ‘funopen’
FILE *funopen(const void *cookie, int (*readfn)(void *, char *, int),
^~~~~~~
In file included from utils.c:45:0:
/usr/include/stdio.h:586:7: note: previous declaration of ‘funopen’ was here
FILE *funopen (const void *__cookie,
^~~~~~~
Added a bunch of useful text management functions.
Consequently, some already available functions like `FormatText()` and `SubText()` has been renamed for consistency. Created temporal fallbacks for old names.
raylib version bumped to 2.3.
Problem aligning provided vertex data to multiples of four, because main buffer is intended to bu used with indexed quads... but also shared with triangles and lines.
Changed parameters order for consistency with LoadFontData() and other functions when an array is passed by parameter and array size is the following parameter.
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()`
When doing a8dffc63fb I was not aware that
printing a warning and not executing the code would be an option. I only
learned that through 618f220851.
So I propose that we allow all URLs except if the string contains a `'`.
Which could end the URL and call another command via `system()`.
Related to https://github.com/raysan5/raylib/issues/686
Calling just `xdg-open` is not right. One needs to pack the URL in `'`.
If we don't do this then some special characters (like ampersand) will
be executed.
Maybe this is true for Windows and Apple case too, but I don't own any
such system. So please merge this, and if it's true for more cases let's
use `sprintf()` in the other cases too.
OpenURL() is a function that most games probably will never need.
Wasting 512 bytes to store of a static char to store an the URL is not
wise.
I propose to have it dynamic building the string on the fly.
Some projects need the buffer to not be empited when drawing to the render texture. I would suggest making maybe a variation of the function if you'd like to keep backwards compatibility, maybe like: BeginTextureModeNoClear() ?
By default, internal white texture was used to draw most of the shapes; some time ago, support for white font character from default internal font was added. That way, all basic drawing (shapes, text) could be performed without a texture change and in a single drawing pass.
Now, we move a step further and we allow configuring the texture (and rectangle) used to do the shapes drawing.
On Linux systems the length of the path is defined in linux/limits.h as
PATH_MAX.
Lets use that for MAX_FILEPATH_LENGTH, which is a define that we can
find in some comments in the code that is actually never used. Instead
often we see 256 handwritten.
So lets have MAX_FILEPATH_LENGTH as a proper define, being set to
PATH_MAX on Linux and to 256 on Windows systems.
- Added a function to get the last write time of a file. I used this so I can reload files or resources if the time since they were last loaded changes.
The prototype of GenImageFontAtlas() in the main raylib.h header has a set of swapped parameter names.
Going through the usage of the function within raylib itself, it appears as if the correct order is:
1) charsCount
2) fontSize
However, it's exposed to the world as the other way around, which may cause some major confusion.
Generating the projects using CMake, targeting VS2017, results in an error when compiling.
This is due to physac.h trying to make a 'vertices' array of size 'int count', making it const does not work, either.
This changes the static declaration to a malloc/free combo.
Tested using the physics-demo.
This implementation is a bit limited, does not support wide characters directories but it's a temporal solution...
This solution uses "io.h" (like MinGW provided one) while other modern solutions use the "windows.h", that result in duplicate symbols issues... need to review it carefully.
REVIEW: Reorganized global variables for consistency
ADDED: GetWindowHandle() to get native window handle
ADDED: GetDirectoryFiles() to get files list for a DIR
Apple ought to fix their OpenGL implementation, but with OpenGL now
deprecated this might not happen.
This has been reported upstream in GLFW in glfw/glfw#1334.
The workaround comes from kovidgoyal/kitty@b82e74f99
This also fixes the HiDPI (Retina) scaling issues reported in #497,
so the workaround is enabled anywhere __APPLE__ is defined.
Previously, if <raylib.h> was #included prior to another header that
defined bool, the compilation would fail.
This is e.g. the case for <perl.h> and <objc/objc.h> which both fall
back to the <stdbool.h> if C99 is available.
The following commit includes <objc/objc.h> in src/core.c, which causes
the same problem.
Avoid this by checking for C99 bool like we already do for C++'s.
- Added PLATFORM_DESKTOP check for Monitor functions to try to fix issue on android.
- Not sure what return types should be when not on desktop. Added rough guess for now.
Useful for bitmaps pixelated fonts where anti-aliasing is not desired!
Change also enables additional font generation mechanisms in a future (cleartype, hinting...).
strprbrk() does not follow raylib function name convention but as it is
very similar to the standard strpbrk(), we'll keep the naming... also,
don't like to mix static functions with API functions but as strprbrk()
is just used in the two functions below, it's ok to be there... maybe it
could be refactored in a future or even move the logic inside the
required functions...
When a batch reach its vertex limit, a draw call is issued and batch restarted for refilling but if the draw call was issued for vertex data accumulated inside rlPushMatrix/rlPopMatrix, draw call was issued before the rlPopMatrix, consequently modelview matrix was not properly recovered before the draw call... obviously, it only happened the following draw calls, not the first one...
Now it works ok but this system needs to reviewed, noticed and important frames drop when processing around 20 dynamic batch draw calls, it means filling MAX_QUADS_BATCH (8192) quads of data 20 times per frame, including data updating and sending for draw processing.
Doing some maths, it means:
Vertex data (float) -----> 8192 quads * 4 vertex * 3 comp * 4 byte = 393216 bytes
Texcoords data (float) -> 8192 quads * 4 vertex * 2 comp * 4 byte = 262144 bytes
Color data (uchar) -----> 8192 quads * 4 vertex * 4 comp * 1 byte = 131072 bytes
Thats a total of 786432 bytes (0.75MB) sent to GPU 20 times per frame for processing... I'm testing in an Intel HD Graphics integrated, I imagine is too much data to be sent and and it causes stalls, so the frames drop...
Added support form vertical and horizontal 3-patches.
Corrected the distortion caused when destRec size is smaller than 4x4. Now even 1x10 or 0x0 sizes are drawn correctly.
Added support form vertical and horizontal 3-patches.
Corrected the distortion caused when destRec size is smaller than 4x4. Now even 1x10 or 0x0 sizes are drawn correctly.
The GLFW tree distributed with raylib has two modifications:
- GLFW_PKG_{DEPS,LIBS} are exported to PARENT_SCOPE, so we can use them
in our pkg-config file
- An intermediary glfw_objlib target is added, so we can reexport GLFW
symbols from libraylib.a
rglfw can fix the second point, but for Wayland usage, we would have to
replicate protocol generation, so we just leverage GLFW's existing
support instead.
To make maintenance easier, I have submitted a pull request for
including these modifications to upstream GLFW.
And to make that one easier, this patch dog-foods the modifications,
so raylib users can help find regressions. :-)
glfw/glfw#1307
Homebrew doesn't ship 32-bit libraries anymore, so using both
-DUSE_EXTERNAL_GLFW and -DMACOS_FATLIB with a Homebrew GLFW would fail.
With -DUSE_EXTERNAL_GLFW=OFF, this is not a problem, but I think keeping
it off by default makes more sense. If someone wants universal
libraries, they can just toggle it.
PLATFORM_WEB is not the only platform that doesn't define
GLFW_TRANSPARENT_FRAMEBUFFER, it's also recent enough that it's not
included in the most recent GLFW 3.2.1 release, so this error can creep
up when using USE_EXTERNAL_GLFW.
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.
also makes one configuration shared-only
dr_flac is not built on i386, because GCC 4.8 complains about asm("cpuid"
clobbering ebx, as it's using ebx for PIC.
Instead of downloading a newer GCC (and multilib),
disable FLAC for that one configuration...
It would be good to have a way to continue execution even when loading a stream didn't work.
Free music and set it to NULL in case something went wrong, so that users can check for it.
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
if (${PLATFORM} MATCHES "Desktop")
target_link_libraries(${RAYLIB}_shared glfw ${GLFW_LIBRARIES})
was never true because PLATFORM STREQUAL "PLATFORM_DESKTOP"...
This fixes#551 and makes the changes suggested in #552 (commited as 965cc8ab)
unnecessary.
From 2019 64bit support will be mandatory to publish an Android app.
Google plans to require that new apps target Oreo (API level 26) in
August of 2018.
This reverts commit 2d6fb5c628,
and adds a fix for Alien::raylib's test failures.
The tests failed because the resulting static library didn't reexport
GLFW symbols. As a fix, we now have GLFW create a CMake "object library"
target that we can link with both the static and shared raylib.
This is arguably ugly... Proper fix would probably be a GLFW upstream
object library target.
Closes#536.
We need the CMake stuff for wayland configuration.
Otherwise, we would have to replicate that ourselves.
This is the full 7ef34eb06de54dd9186d3d21a401b2ef819b59e7 tree except
for tests/ examples/ and docs/
Panders to the idiosyncrasies of my work flow:
I have my raylib build directory mounted as a VirtualBox vboxfs for use
with my Linux VM, but vboxfs doesn't support symlinks, while raylib shared
library versioning on Unix expects symlinks to work.
If this happens, library versioning is now disabled on Unix with
an error message instead of just failing the build.
- 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...
Reported in #435, tcc generates out-of-line definitions for inline
symbols, something it shouldn't. This fix punishes tcc for that
by making applications it compiles (slightly) larger...
That way, a user needs only to touch a single file to configure what
features raylib is built with.
Include guards are left out intentionally, because config.h should only
be included in source files, not headers.
Later on, config.h can also define the raylib version (#461).
This is already the order that is used for Android. It doesn't appear to
make a difference on desktop but on web using the timer before it's been
initialized (by glfwInit, inside InitGraphicsDevice) causes the a long
(and variable but often several seconds) sleep between the first and
second frame.
Fixes: 468309d ("Early-exit InitWindow if InitGraphicsDevice fails")
Inspired by #504.
Instead of requiring the user to do PLATFORM_ANDROID #ifdefery,
have the android_main entry point exported by raylib and call
the user-defined main. This way many games could (in theory)
run unmodified on Android and elsewhere.
This is untested!
- SetWindowSize() to scale Windows in runtime
- SetMouseScale() to scale mouse input, useful when rendering game to a
RenderTexture2D that will be scaled to Window size (used on rFXGen tool)
GLFW has been updated to latest version, probably this code is not
required any more due to already been integrated into library... but it
needs to be tested...
Renamed function for consistency with a possible Mesh manipulation functions (maybe added in a future). Naming follows Image*() manipulation functions.
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.
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.
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()?
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.
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.
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.
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.
Review rlLoadTexture() function to make it simpler, now OpenGL texture
glInternalFormat, glFormat and glType are retrieved with new function
GetGlFormats()
- Support OpenGL 1.1 if selected macro
- Corrected MSVC compiler issues with (void *) data
- Removed raylib.dll project
- Created DEBUG_DLL and RELEASE_DLL configurations
- 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
- Renamed enum TextureFormat to PixelFormat for consistency
- Added support for pixel format UNCOMPRESSED_R32
- Using GetPixelDataSize() where required
That function depends on SavePNG() and forces platform check on textures
module, that behaviour should be changed, platform definition should be
only required on core module...
