When using FormatText() several times in same function, returned string is static and so, the same is returned, resulting in failures on shader loading.
Now dividing by the zoom instead of multiplying (in the shader), so zoom works as expected. Also zoom increase/decrease is now scaled depending on the current zoom.
extra-cmake-modules 5.38.0a is no longer hosted at the specified
kernel.org link. Use the occasion to move on to 5.58.
Because newer ECM debian packages have the control.tar file
xz-compressed, we need to update dpkg as well on trusty.
For more information, see
https://bugs.launchpad.net/ubuntu/+source/dpkg/+bug/1730627
Note that building examples for web as they are (no code adaptation for web avoiding while loop) implies using the emterpreter... and that's very slow!
Square root calls are computationally expensive. In this case, they can be avoided. Instead of checking distance<RadA+RadB, check distance squared against (RadA+RadB) squared. The dot product of Vector3Subtract(B,A) with itself gives distance squared, so I used this code instead of an element-by-element computation of distance squared. The only downside is that your geometric code is very readable, whereas this is less so.
They not only result in discrepancies between different compiler,
but trigger undefined behavior. Avoid them by having them break
the CMake build and CI.
CI is failing because we still test with GLFW 3.2, while
the internal GLFW is 3.3. To avoid such breakages in future,
build and install our own GLFW instead of relying on an external
Debian package.
We were doing this before, but it was deleted during the
last GLFW update. Readd it to fix the associated macOS CI failure.
Fixes: cd934c9f6 ("Update GLFW to 3.3.1")
The example requires pthreads and now C11 <stdatomic.h>, thus skip it
if either isn't available.
This also fixes the current Travis CI build failure for the
Windows configuration.
A plain variable is insuffecient for inter-thread communication. Both the
compiler and the processor may reorder accesses. The compiler could even
cache dataLoaded with the result that STATE_FINISHED becomes unreachable.
Fix this by using C11 atomic_bool, which guarantees sequential consistency.
This fixes#827.
Added guards to not redefine it if the user is using it with raylib.h
also added an 'f' at the end of the define to keep compliant with raylib's PI define
This change could break things. So, I created SUPPORT_HIGH_DPI flag to enable it (disabled by default).
Basically, it detects HighDPI display and scales all drawing (and mouse input) appropiately to match the equivalent "standardDPI" screen size on highDPI. It uses screenScaling matrix to do that.
This scaling comes with some undesired effects, like aliasing on default font text (keep in mind that font is pixel-perfect, not intended for any non-rounded scale factor).
The only solution for this aliasing would be some AA postpro filter or implementing the highDPI scaling in a different way: rendering to a texture and scaling it with FILTER_BILINEAR, check `core_window_scale_letterbox.c` example for reference.
Use at your own risk.
Two functions have been renamed for coherence; previous naming was confusing for several users:
- DrawPolyEx() ---> DrawTriangleFan()
- DrawPolyExLines() ---> DrawLineStrip()
* Working build
* Fix build again, stop deleting files
* Hotfix crash, needs investigating
* Remove VS2015.UWP, I cannot update the project
* Lots of UWP work, added keyboard and mouse press support. Still need to finish scroll wheel, mouse position and cursor hiding, plus other stuff that I haven't seen yet.
* Implemented a ton more things, added BaseApp.h to provide common code to UWP apps.
* Remove constant window dimensions
* Enable and Disable cursor support.
* Actually use mouse delta
* Gamepad Support
* Cleaning and small tweaks
* Restore original example.
* Update comment
* Use 'Messages' to handle the cursor functions so code is more portable.
* Comment
* Comment unused message fields and use vector for mouse pos instead.
* Move messages to utils.h and use messages for everything. No more plat-specific code in raylib.h
* Working build
* Fix build again, stop deleting files
* Hotfix crash, needs investigating
* Remove VS2015.UWP, I cannot update the project
* Lots of UWP work, added keyboard and mouse press support. Still need to finish scroll wheel, mouse position and cursor hiding, plus other stuff that I haven't seen yet.
* Implemented a ton more things, added BaseApp.h to provide common code to UWP apps.
* Remove constant window dimensions
* Enable and Disable cursor support.
* Actually use mouse delta
* Gamepad Support
* Cleaning and small tweaks
* Restore original example.
* Update comment
* Use 'Messages' to handle the cursor functions so code is more portable.
* Comment
* Comment unused message fields and use vector for mouse pos instead.
* Move messages to utils.h and use messages for everything. No more plat-specific code in raylib.h
* Tested some desktop stuff and added projection matrix updates for window resizing.
* Fixed big bad mouse bug
* Fix alt buttons and add hack to combat flickery key presses (far from perfect)
* Remove debug code
* Final commit
* Well, so I thought
* Wow, i am bad
* Remove packages folder
* Remove useless include
* Apply requested changes and fix linux build
* Try to stop packages folder
* Have we fixed the formatting properly?
* Third time's the charm?
* Where did this come from?
* Re-fix
* Autoformat is gonna kill
* Fixed XBOX ONE Support
* Fix tabs
Found some issues when building for web using latest emscripten 1.38.30, traced the error and found that eglGetProcAdress does not return function pointers for VAO functionality, supported by extension.
It requires more investigation but now it works (avoiding VAO usage)
Users can define their custom memory management macros.
NOTE: Most external libraries support custom macros in the same way, raylib should redefine those macros to raylib ones, to unify custom memory loading. That redefinition is only implemented as example for stb_image.h in [textures] module.
Issue was related to vertex tangent attibutes not uploaded to GPU, a quick solution was implemented for new vertex attributes loading for already existing meshes... I don't like it specially but it will work for now.
This is quite a big change, Model struct has been redesigned to support multiple meshes and multiple materials, most 3d fileformats contain multiple meshes and reference multiple materials.
Consequently, multiple functions have been reviewed.
LoadOBJ(), LoadIQM(), LoadGLFT() now return a Model.
Current LoadOBJ() is not valid anymore, actually, tinyobj_loader_c library is considered for replacement.
If we have no data to update/draw, we avoid update/draw. On `DrawBuffersDefault()` if no vertes data is available nothing is drawn but some globals: vertexData, projection, modelview, draws... are reseted.
There shouldn't be any problem if we don't touch those globals in case no vertex have been processed but, just in case, I warn about it.
Based on pull request from user "DarkElvenAngel", better integrated with the current event system and enhanced with buffer to help with fast typing at low framerates.
When drawing LINES or TRIANGLES, vertex are accumulated in same buffer as QUADS and new draw calls are registered but QUADS drawing uses an index buffer for optimization, so, when adding LINES/TRIANGLES vertices we need to make sure next draw calls for QUADS keep aligned with indices buffer.
To get that we just add some alignment vertex at the end of the LINES/TRIANGLES draw calls, to make them multiple of 4 vertex.
The idea is supporting additional raygui and physac modules building with raylib but those modules are distributed as header-only libraries and it makes a bit dificult to build them inside raylib...
raudio AudioBuffer internal struct collides on macOS with CoreAudio same name struct. In this case struct has been renamed because is internal to raudio... but probably all system should be redesigned.
Getting the following strict error....
```
src/text.c:117:105: error: constant expression evaluates to 2398692640 which
cannot be narrowed to type 'int' [-Wc++11-narrowing]
...0x00000000, 0x00000000, 0x00200020, 0x0001b000, 0x00000000, 0x00000000, 0x8ef92520, 0x00020a00...
^~~~~~~~~~
```
Switching it to an unsigned int fixes it.
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));
^ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
```
No examples built for the Web platform functioned properly due to lack
of resources in the virtual file system provided by emscripten.
This patch addresses this problem by adding
'--preload-file local_path/resources@resources' emcc option to link
flags whenever necessary.
The default memory limit for emscripten applications is 16 mergabytes,
which might be to little for some examples, especially given that the
resources are also included in that limit.
Normally, using this option disables some asm.js optimizations, but
there's no such cost for WebAssembly.
$prefix/lib isn't in pc_path on Fedora 28:
[root@fedora-28 ~]# pkg-config --variable=pc_path pkg-config
/usr/lib64/pkgconfig:/usr/share/pkgconfig
This has the effect that the pkg-config file is written to the
correct location but pkg-config --libs raylib doesn't output
the correct library path. This fixes this problem by substituting
the directory names into the .pc, same as we do with the CMakeLists.txt
since #518.
This issue popped up during the automated test of the Perl bindings:
https://github.com/athreef/Alien-raylib/issues/3
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.
CMake defaults to generating a Visual Studio build on Windows,
which doesn't involve make. Thus use cmake --build to abstract
that detail away. We already do that in the appveyor.yml.
The install line is a bit hacky: cmake might not be in the search
path when using sudo, thus use "$(which cmake)" to get the path,
sudo doesn't seem to be available on the Travis CI windows
environment, so use $(which sudo) without quotes to expand to
nothing if that's the case...
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.
* changed bitwise & to logical &&
* removed redundant state check
* moved a strcpy inside a NULL check to prevent a crash.
NOTE: nothing sensible will happen as a result, but no crash at least.
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...).
This requires the user to explicitly specify the path to their raylib folder. We need a better way around this (something like what we do for windows would help).
With the CI system, release directory has not much sense, actually,
every new commit it gets outdated and latest stable release is already
available in GitHub Release tab.
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...
CheckCollisionRecs() returns true on edge-collision what means that the
snake eats the fruit when colliding with it but also when sliding by one
unit above or below the fruit.
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
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. :)
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.
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
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.
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.
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
Mouse input is implemented, with all bells-and-whistles. This includes
cursor locking and scroll wheel support.
Keyboard input is reverted to a callback model to better reflect the
existing architecture in "core.c"
- 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...
* `Alien::raylib` downloads raylib, builds it and installs it in the Perl module path (Basically abusing CPAN as package manager)
* `Graphics::Raylib::XS` depends on `Alien::raylib` and reexports all C symbols as XS symbols usable in Perl
* `Graphics::Raylib` depends on `Graphics::Raylib::XS` and is the actual Perl wrapper with a Perlish API, which users should be using
Now with external OpenAL and GLFW dependencies removed,
we don't have to worry about installing them in CI.
Shared libraries are now always built along with static libs.
Games and examples are built everwhere except for Visual Studio,
because Physac needs pthreads, which VS doesn't provide.
See #401 for the discussion.
Also bumps version number to 1.9.2 without the -dev,
because neither ELF nor MachO like such a suffix.
The -dev suffix will have to be restricted to the git tags.
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.
... for now.
Syntax was confusing Travis CI, AppVeyor is reporting 401,
so lets see if this change at least fixes Travis.
If this doesn't work, it might be that @raysan5's token is required.
cmake --build . --target package # or make package if make is used
can now be used to create binary packages for raylib.
AppVeyor and Travis CI are configured to push the artifacts
that result from building git tags to the related Github releases page.
After installation, compiling new programs is possible with
$ cc game.c `pkg-config --static --libs --cflags raylib`
or
$ cc game.c `pkg-config --libs --cflags raylib`
depending on configuration
Also adds following configuration options:
- WITH_PIC "Compile static library as position-independent code"
- STATIC_RAYLIB "Build raylib as a static library"
- MACOS_FATLIB "Build fat library for both i386 and x86_64 on macOS"
This bug is a result of the buffer of an AudioStream being smaller than
that of a period of the backend playback device. In this situation,
AudioStream's would have pauses between buffer updates because the
backend is not able to re-fill the AudioStream buffer's quick enough
due to it's periods being longer than the AudioStream buffer.
We already have automatic Linux and macOS build via Travis CI.
This adds the same for Windows x86 and x86_64 with both
Microsoft Visual Studio 2015 as well as MinGW-w64.
There have been two problems:
* GLFW itself was compiled with the definitions for compiling
_against_ GLFW (fixed by removing requirement for external glfw)
* rglfw.c was being compiled as C code, although it includes
Objective C files.
This _might_ break the Windows build, needs to be checked.
Fixes#391, but as noted I'd prefer though a separate source directory
and build script for GLFW.
Feature macros need to be defined before #including any headers,
preferably through the build system, but this is good enough.
Fixes a compile error on my fork's Travis CI.
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.
Using the library() function instead of shared_library() allows changing
of the library type via the default_library option.
This allows for easy change between static and dynamic library building.
Use 'meson --default-library=static builddir' to build as static, if no builddir yet exists.
Use 'mesonconf -Ddefault_library=static builddir' to change the type for
an existing builddir.
It seems Sleep() behaves weird on my computer, disabled by default
returning to the busy wait loop... also re-implemented DrawFPS() to
avoid frame blitting...
According to Man Pages, timespec with std=c99 needs "_POSIX_C_SOURCE 199309L". Due a some kind of bug, "#define _POSIX_C_SOURCE 199309L" doesn't work, so we must use "-D_POSIX_C_SOURCE=199309L" in compiler options.
raylib webpage has been completely reorganized and moved from gh-pages
(a pain to work with) to docs folder. Useless libs have been removed,
webs have been renamed, etc.
Now it would be easier (hopefully) to update webpage. :)
- Improved ImageCopy() to support compressed formats
- Renaming file-formats header structs for consistency
- Review variables naming on ImageDither() for consistency
- Improved LoadImagePro() to make a copy of data
- Preliminary support of rRES file format on LoadImage()
- Renamed WritePNG() to SavePNG() for consistency with other file
loading functions
- Renamed WriteBitmap() to SaveBMP() for consistency with other file
loading functions
- Redesigned SaveBMP() to use stb_image_write
The function means to accept a const * so let's declare it.
Will allow passing const buffers in games.
Also constness is next to godliness!
Signed-off-by: Saggi Mizrahi <saggi@mizrahi.cc>
Mask was wrongly applied to 8-bit font image, it generated dark borders
on the font. Grayscale image has to be considered as the alpha mask for
a completely white image to use it correctly.
The first target allow makefile to install the dev files (static library and
header) to standard directories on GNU/Linux platforms; the second allow it to
unistall (remove) the dev files.
It needs lot of improvements.
Matching the same stereo rendering result given by Oculus PC SDK for
Oculus Rift CV1 is very difficult because hardware has changed a lot and
DK2 distortion shader and parameters don't fit on CV1. Some custom
parameters have been calculated to simulate kind of CV1 stereo
rendering. Further work is required on this point.
- Embedded VR distortion shader
- Ready to support multiple VR devices
- Fallback to VR Simulator if device not ready
- Support mono rendering over stereo rendering
...to avoid dynamic conditions on for loop (lightsCount) on standard
shader, it seems GLSL 100 doesn't support that feature... on some GPUs
like RaspberryPi...
... and now physac thread creation is done in InitPhysics() and it is
destroyed in ClosePhysics(). User just need to call these functions to
use physac module.
Old physics update system used a static number of steps to calculate
physics (450 for desktop and 64 for android). It was too much and it was
limited by target frame time...
Now physics update runs in a secondary thread using a fixed delta time
value to update steps. Collisions are perfectly detected and resolved
and performance has been improved so much.
Moved all external libraries used by raylib to external folder inside
raylib src. Makefile has already been update and also the different
includes in raylib modules.
- Added normal and specular maps to standard shader.
- Added full tint attribute to standard shader and material data type.
- Changed point light attenuation to radius.
- 3 light types added (point, directional, spot).
- DrawLights() function added using line shapes.
- Standard lighting example added.
- Removed useless struct variables from material and light.
- Fixed light attributes dynamic locations errors.
- Standard vertex and fragment shaders temporally added until rewrite it
as char pointers in rlgl.
TODO:
- Add normal and specular maps calculations in standard shader.
- Add control structs to handle which attributes needs to be calculated
(textures, specular...).
- Adapt standard shader to version 110.
- Rewrite standard shader as char pointers in rlgl.
- Ambient and lambert lighting added.
- Ambient and diffuse colors linked to standard shader.
- Single light linked to standard shader.
- LoadStandardMaterial() and depending functions added.
Now GLFW3 windows/context creation works ok and a sample red rectangle
has been drawn using rlgl. Next step is working in tracking
position/orientation maths and try to get a simple 3d scene...
- Renamed some functions for consistency (default buffers)
- Removed mystrdup() function (implemented inline)
- Renamed TextFileRead() to ReadTextFile()
This is an early draft, needs lots of work. Still need to figure out way
to calculate total length of song. This is hard because xm tracks stream
out zeros when done, only position in track can be found. Position does
not give any direct value of how much more time is left. I think that by
setting the loop count to 1 and seeking until the end I can total up the
number of samples and come up with a length.
NOTE: It requires a depth texture as input, it should be configured on
rlgl, by default RenderTexture (fbo) uses Depth Renderbuffer instead of
Depth Texture. Check rlglLoadRenderTexture()
Finally, physics update is handled in main thread using steps to get
accuracy in collisions detection instead of moving it to a new thread.
Examples are finished as simple and clear as I could. Finally, physac
module is MORE simpler than in the first version, calculation everything
by the same way for both types of physic objects.
I tryed to add rotated physics a couple of times but I didn't get
anything good to get a base to improve it. Maybe for the next version...
No bugs or strange behaviours found during testing.
physac module base almost finished. All collisions are now resolved
properly and some force functions was added.
COLLIDER_CAPSULE removed for now because in 2D everything is composed by
rectangle and circle colliders...
The last step is move physics update loop into another thread and update
it in a fixed time step based on fps.
If you have raylib on standard directories ("/usr/local/include/raylib/raylib.h" for the header and "/usr/local/lib/libraylib.a" for raylib library) you can compile without edit the makefile.
physac modules is being redesigned. Physics base behaviour is done and
it is composed by three steps: apply physics, resolve collisions and fix
overlapping.
A basic example is currently in progress. The next steps are try to add
torque and unoriented physic collisions and implement physics basic
functions to add forces. Rigidbody grounding state is automatically
calculated and has a perfect result. Rigidbodies interacts well with
each others.
To achieve physics accuracy, UpdatePhysics() is called a number of times
per frame. In a future, it should be changed to another thread and call
it without any target frame restriction.
Basic physics example has been redone (not finished) using the new
module functions. Forces examples will be redone so I removed it from
branch.
title: "[module] Short description of the issue/bug/feature"
labels: ''
assignees: ''
---
Please, before submitting a new issue verify and check:
- [ ] I tested it on latest raylib version from master branch
- [ ] I checked there is no similar issue already reported
- [ ] My code has no errors or misuse of raylib
### Issue description
*Briefly describe the issue you are experiencing (or the feature you want to see added to raylib). Tell us what you were trying to do and what happened instead. Remember, this is not the best place to ask questions. For questions, go to [raylib Discord server](https://discord.gg/VkzNHUE).*
### Environment
*Provide your Platform, Operating System, OpenGL version, GPU details where you experienced the issue.*
### Issue Screenshot
*If possible, provide a screenshot that illustrates the issue. Usually an image is better than a thousand words.*
### Code Example
*Provide minimal reproduction code to test the issue. Please, format the code properly and try to keep it as simple as possible, just focusing on the experienced issue.*
- *raylib flat-assembler Usage example*: not uploaded yet...
Missing some language? Check the [bindings not yet in this list](https://gist.github.com/raysan5/5764cc5b885183f523fce47f098f3d9b#bindings-not-yet-in-the-official-list) or create a new binding! :)
Usually, raylib bindings follow the convention: `raylib-{language}`
Let me know if you're writing a new binding for raylib, I will list it here and I usually
provide the icon/logo for that new language binding.
In the interest of fostering an open and welcoming environment, we as contributors and maintainers pledge to making participation in our project and our community a harassment-free experience for everyone, regardless of age, body size, disability, ethnicity, gender identity and expression, level of experience, nationality, personal appearance, race, religion, or sexual identity and orientation.
## Our Standards
Examples of behavior that contributes to creating a positive environment include:
* Using welcoming and inclusive language
* Being respectful of differing viewpoints and experiences
* Gracefully accepting constructive criticism
* Focusing on what is best for the community
* Showing empathy towards other community members
Examples of unacceptable behavior by participants include:
* The use of sexualized language or imagery and unwelcome sexual attention or advances
* Trolling, insulting/derogatory comments, and personal or political attacks
* Public or private harassment
* Publishing others' private information, such as a physical or electronic address, without explicit permission
* Other conduct which could reasonably be considered inappropriate in a professional setting
## Our Responsibilities
Project maintainers are responsible for clarifying the standards of acceptable behavior and are expected to take appropriate and fair corrective action in response to any instances of unacceptable behavior.
Project maintainers have the right and responsibility to remove, edit, or reject comments, commits, code, wiki edits, issues, and other contributions that are not aligned to this Code of Conduct, or to ban temporarily or permanently any contributor for other behaviors that they deem inappropriate, threatening, offensive, or harmful.
## Scope
This Code of Conduct applies both within project spaces and in public spaces when an individual is representing the project or its community. Examples of representing a project or community include using an official project e-mail address, posting via an official social media account, or acting as an appointed representative at an online or offline event. Representation of a project may be further defined and clarified by project maintainers.
## Enforcement
Instances of abusive, harassing, or otherwise unacceptable behavior may be reported by contacting the project team at ray@raylib.com. The project team will review and investigate all complaints, and will respond in a way that it deems appropriate to the circumstances. The project team is obligated to maintain confidentiality with regard to the reporter of an incident. Further details of specific enforcement policies may be posted separately.
Project maintainers who do not follow or enforce the Code of Conduct in good faith may face temporary or permanent repercussions as determined by other members of the project's leadership.
## Attribution
This Code of Conduct is adapted from the [Contributor Covenant][homepage], version 1.4, available at [http://contributor-covenant.org/version/1/4][version]
Do you enjoy raylib and want to contribute? Nice! You can help with the following points:
- C programming - Can you write/review/test/improve the code?
- Documentation/Tutorials/Example - Can you write some tutorial/example?
- Web Development - Can you help [with the web](https://github.com/raysan5/raylib.com)?
- Porting to other platforms - Can you port and compile raylib on another systems?
- Testing - Can you find some bugs on raylib?
This document contains a set of guidelines to contribute to the project. These are mostly guidelines, not rules.
Use your best judgement, and feel free to propose changes to this document in a pull-request.
### raylib philosophy
- raylib is a tool to enjoy videogames programming, every single function in raylib should be a tutorial on itself.
- raylib is SIMPLE and EASY-TO-USE, I tried to keep it compact with a small set of functions, if a function is too complex or is not clearly useful, better not to include it.
- raylib is open source and free; educators and institutions can use this tool to TEACH videogames programming completely by free.
- raylib is collaborative; contribution of tutorials / code-examples / bugs-solving / code-comments are highly appreciated.
- raylib's license (and its external libs respective licenses) allow using it for commercial products.
[raylib Wiki](https://github.com/raysan5/raylib/wiki) contains some information about the library and is open to anyone for edit.
Feel free to review it if required, just take care not to break something.
### raylib C coding conventions
Despite being written in C, raylib does not follow the standard Hungarian notation for C,
it [follows Pascal-case/camel-case notation](https://github.com/raysan5/raylib/wiki/raylib-coding-conventions),
more common on C# language. All code formatting decisions have been carefully taken
to make it easier for students to read, write and understand code.
Source code is extensively commented for that purpose, raylib primary learning method is:
> learn by reading code and examples
For detailed information on building raylib and examples, please check [raylib Wiki](https://github.com/raysan5/raylib/wiki).
### Opening new Issues
To open new issue for raylib (bug, enhancement, discussion...), just try to follow these rules:
- Make sure the issue has not already been reported before by searching on GitHub under Issues.
- If you're unable to find an open issue addressing the problem, open a new one. Be sure to include a
title and clear description, as much relevant information as possible, and a code sample demonstrating the unexpected behavior.
- If applies, attach some screenshot of the issue and a .zip file with the code sample and required resources.
- On issue description, add a brackets tag about the raylib module that relates to this issue.
If don't know the module, just report the issue, I will review it.
- You can check other issues to see how is being done!
### Sending a Pull-Request
- Make sure the PR description clearly describes the problem and solution. Include the relevant issue number if applicable.
- Don't send big pull-requests (lots of changelists), they are difficult to review. It's better to send small pull-request, one at a time.
- Verify that changes don't break the build (at least on Windows platform). As many platforms where you can test it, the better, but don't worry
if you cannot test all the platforms.
### Contact information
If you have any doubt, don't hesitate to [contact me](mailto:ray@raylib.com)!.
You can write me a direct mail but you can also contact me on the following networks:
- [raylib reddit](https://www.reddit.com/r/raylib/) - A good place for discussions or to ask for help.
- [raylib Discord](https://discord.gg/VkzNHUE) - A direct communication channel for project discussions.
- [raylib twitter](https://twitter.com/raysan5) - My personal twitter account, I usually post about raylib, you can send me PMs.
- [raylib web](http://www.raylib.com/) - On top-right corner there is a bunch of networks where you can find me.
Thank you very much for your time! :)
----
Here is a list of raylib contributors, these people have invested part of their time
contributing (in some way or another) to make the raylib project better. Huge thanks to all of them!
- [Zopokx](https://github.com/Zopokx) for testing the web.
- [Elendow](http://www.elendow.com) for testing and helping on web development.
- Victor Dual for implementing and testing 3D shapes functions.
- Marc Palau for implementing and testing 3D shapes functions and contribute on camera and gestures modules.
- Kevin Gato for improving texture internal formats support and helping on raygui development.
- Daniel Nicolas for improving texture internal formats support and helping on raygui development.
- Marc Agüera for testing and using raylib on a real product ([Koala Seasons](http://www.koalaseasons.com))
- Daniel Moreno for testing and using raylib on a real product ([Koala Seasons](http://www.koalaseasons.com))
- Daniel Gomez for testing and using raylib on a real product ([Koala Seasons](http://www.koalaseasons.com))
- [Sergio Martinez](https://github.com/anidealgift) for helping on raygui development and tools development (raygui_styler).
- [Victor Fisac](https://github.com/victorfisac) for developing physics raylib module (physac) and implementing PBR materials and lighting systems... among multiple other improvements and multiple tools and games.
- Albert Martos for helping on raygui and porting examples and game-templates to Android and HTML5.
- Ian Eito for helping on raygui and porting examples and game-templates to Android and HTML5.
- [procedural](https://github.com/procedural) for testing raylib on Linux, correcting some bugs and adding several mouse functions.
- [Chris Hemingway](https://github.com/cHemingway) for improving raylib on OSX build system.
- [Emanuele Petriglia](https://github.com/LelixSuper) for working on multiple GNU/Linux improvements and developing [TicTacToe](https://github.com/LelixSuper/TicTacToe) raylib game.
- [Joshua Reisenauer](https://github.com/kd7tck) for adding audio modules support (XM, MOD) and reviewing audio system.
- [Marcelo Paez](https://github.com/paezao) for helping on OSX High DPI display issue.
- [Ghassan Al-Mashareqa](https://github.com/ghassanpl) for an amazing contribution to raylib Lua module.
- [Teodor Stoenescu](https://github.com/teodor-stoenescu) for improvements on OBJ object loading.
- [RDR8](https://github.com/RDR8) for helping with Linux build improvements.
- [Saggi Mizrahi](https://github.com/ficoos) for multiple fixes on Linux and audio system.
- [Daniel Lemos](https://github.com/xspager) for fixing issues on Linux games building.
- [Joel Davis](https://github.com/joeld42) for adding raycast picking utilities and a [great example](https://github.com/raysan5/raylib/blob/master/examples/models/models_mesh_picking.c)
- [Richard Goodwin](https://github.com/AudioMorphology) for adding RPI touchscreen support.
- [Milan Nikolic](https://github.com/gen2brain) for adding Android build support with custom standalone toolchain.
- [Michael Vetter](https://github.com/jubalh) for improvements on build system and his work on Suse Linux package... and multiple fixes!
- [Wilhem Barbier](https://github.com/nounoursheureux) for adding Image generation functions and some fixes.
- [Benjamin Summerton](https://github.com/define-private-public) for improving OSX building and his amazing work on CMake build sytem.
- [MartinFX](https://github.com/Martinfx) for adding compilation support for FreeBSD OS and derivatives.
- [Wilhem Barbier](https://github.com/nounoursheureux) for supporting default shaders on shader loading, if shader not provided.
- [Ahmad Fatoum](https://github.com/a3f) for implementing CI support for raylib (Travis and AppVeyor) and great improvements on build system.
- [SamNChiet](https://github.com/SamNChiet) for a greatly improved UWP input implementation.
- [David Reid](https://github.com/mackron) for a complete review of audio module to support his amazing miniaudio library.
- [Kai](https://github.com/questor) for multiple code reviews and improvements.
- [RDR8](https://github.com/RDR8) for improvements on Makefiles for Linux.
- [Max Danielsson](https://github.com/autious) for adding support for orthographic 3d camera projection
- [Lumaio](https://github.com/TheLumaio) for his great work on GBuffers and GetCollisionRayModel().
- [Jonas Daeyaert](https://github.com/culacant) for an amazing work on IQM animated models support.
- [Seth Archambault](https://github.com/SethArchambault) for the work on Android Gamepad support (SNES model).
- [D3nX](https://github.com/D3nX) for adding Code::Blocks project template.
- [Jak Barnes](https://github.com/Syphonx) for a great work on `rnet`, new raylib network module
- [Vlad Adrian](https://github.com/Demizdor) for an amazing work on Unicode support, new shapes functions and raygui.
- [Reece Mackie](https://github.com/Rover656) for a great work on improving UWP support
- [flashback-fx](flashback-fx) for improving easings library and example
- [Jorge A. Gomes](https://github.com/overdev) for adding nine-patch textures support and example
- [Berni8k](https://github.com/Berni8k) for improving Raspberry Pi input system, using evdev
- [Wilhem Barbier](https://github.com/wbrbr) for implementing glTF loading support and solving several issues
- [Marco Lizza](https://github.com/MarcoLizza) for improving logging system and multiple issues
- [Anata](https://github.com/anatagawa) for creating amazing examples and contributing with them
- [Narice](https://github.com/narice) made easings.h includable as standalone header
- [Eric J.](https://github.com/ProfJski) for shaders_eratosthenes example contribution
Please, if I forget someone in this list, excuse me and send a PR!
I’m working hard on raylib but my resources are quite limited. If you enjoy raylib and want to help / contribute in some way,
please, [let me know][raysan5].
The following help is highly appreciated:
- C programming - Can you write / review / test / improve the code?
- Translators / Localizators - Can you translate raylib to another language?
- Documentation / Tutorials / Example writters - Can you write some tutorial / example?
- Web Development - Can you help with the web? Can you setup a forum?
- Porting to Linux, OSX... - Can you compile and test raylib on another OS?
- Testers of current features and multiple systems - Can you find some bug on raylib?
If you can not help on any of the above points but you still want to contribute in some way... please, consider helping
with a small [donation](http://www.raylib.com/helpme.htm) (just some euros...). It will really motivate to continue improving this project (and pay some bills… or some coffee).
raylib philosophy
------------------
* raylib is a tool to LEARN videogames programming, every single function in raylib should be a tutorial on itself (clear code).
* raylib is SIMPLE and EASY-TO-USE, I tried to keep it compact with a small set of functions, if a function is too complex or
has not a clear usefulness, better not to include it.
* raylib is open source and free; educators and institutions can use this tool to TEACH videogames programming completely by free.
* raylib is, hopefully, collaborative; contribution of tutorials / code-examples / bugs-solving / code-comments are highly appreciated.
* raylib's license (and its external libs respective licenses) allow using it for commercial products.
I've developed videogames since 2006 and in 2012 I started teaching videogames development to young people with artistic profile, most of them had never written a single line of code.
I started with C language basis and, after searching for the most simple and easy-to-use library to teach videogames programming, I found WinBGI; it was great and it worked very well with students, in just a couple of weeks that people that had never written a single line of code were able to program (and understand) a simple PONG and some of them even a BREAKOUT!
But WinBGI was not the clearer and most organized lib. There were a lot of things I found confusing and some function names were not clear enough for most of the students; not to mention points like no transparencies support or no hardware acceleration.
So, I decided to create my own library, hardware accelerated, clear function names, quite organized, well structured, plain C coding and, the most important, primarily intended to learn videogames programming.
Most of my videogames coding experience was in C# and XNA and I really love it (in fact, my students learn C# after C), so, I decided to use C# language notation and XNA naming conventions. That way, students can jump from raylib to XNA, MonoGame or similar libs extremely easily.
raylib started as a weekend project and after three months of hard work, raylib 1.0 was published on November 2013.
Enjoy it.
notes on raylib 1.1
-------------------
On April 2014, after 6 month of first raylib release, raylib 1.1 has been released. This new version presents a complete internal redesign of the library to support OpenGL 1.1, OpenGL 3.3+ and OpenGL ES 2.0.
A new module named [rlgl](https://github.com/raysan5/raylib/blob/master/src/rlgl.h) has been added to the library. This new module translates raylib-OpenGL-style immediate mode functions (i.e. rlVertex3f(), rlBegin(), ...) to different versions of OpenGL (1.1, 3.3+, ES2), selectable by one define.
[rlgl](https://github.com/raysan5/raylib/blob/master/src/rlgl.h) also comes with a second new module named [raymath](https://github.com/raysan5/raylib/blob/master/src/raymath.h), which includes a bunch of useful functions for 3d-math with vectors, matrices and quaternions.
Some other big changes of this new version have been the support for OGG files loading and stream playing, and the support of DDS texture files (compressed and uncompressed) along with mipmaps support.
Lots of code changes and lot of testing have concluded in this amazing new raylib 1.1.
notes on raylib 1.2
-------------------
On September 2014, after 5 month of raylib 1.1 release, it comes raylib 1.2. Again, this version presents a complete internal redesign of [core](https://github.com/raysan5/raylib/blob/master/src/core.c) module to support two new platforms: [Android](http://www.android.com/) and [Raspberry Pi](http://www.raspberrypi.org/).
It's been some month of really hard work to accomodate raylib to those new platforms while keeping it easy for the users. On Android, raylib manages internally the activity cicle, as well as the inputs; on Raspberry Pi, a complete raw input system has been written from scratch.
A new display initialization system has been created to support multiple resolutions, adding black bars if required; user only defines desired screen size and it gets properly displayed.
Now raylib can easily deploy games to Android devices and Raspberry Pi (console mode).
Lots of code changes and lot of testing have concluded in this amazing new raylib 1.2.
In December 2014, new raylib 1.2.2 was published with support to compile directly for web (html5) using [emscripten](http://kripken.github.io/emscripten-site/) and [asm.js](http://asmjs.org/).
notes on raylib 1.3
-------------------
On September 2015, after 1 year of raylib 1.2 release, arrives raylib 1.3. This version adds shaders functionality, improves tremendously textures module and also provides some new modules (camera system, gestures system, immediate-mode gui).
Shaders support is the biggest addition to raylib 1.3, with support for easy shaders loading and use. Loaded shaders can be attached to 3d models or used as fullscreen postrocessing effects. A bunch of postprocessing shaders are also included in this release, check raylib/shaders folder.
Textures module has grown to support most of the internal texture formats available in OpenGL (RGB565, RGB888, RGBA5551, RGBA4444, etc.), including compressed texture formats (DXT, ETC1, ETC2, ASTC, PVRT); raylib 1.3 can load .dds, .pkm, .ktx, .astc and .pvr files.
A brand new [camera](https://github.com/raysan5/raylib/blob/master/src/camera.c) module offers to the user multiple preconfigured ready-to-use camera systems (free camera, 1st person, 3rd person). Camera modes are very easy to use, just check examples: [core_3d_camera_free.c](https://github.com/raysan5/raylib/blob/master/examples/core_3d_camera_free.c) and [core_3d_camera_first_person.c](https://github.com/raysan5/raylib/blob/master/examples/core_3d_camera_first_person.c).
New [gestures](https://github.com/raysan5/raylib/blob/master/src/gestures.h) module simplifies gestures detection on Android and HTML5 programs.
[raygui](https://github.com/raysan5/raylib/blob/master/src/raygui.h), the new immediate-mode GUI module offers a set of functions to create simple user interfaces, primary intended for tools development. It's still in experimental state but already fully functional.
Most of the examples have been completely rewritten and +10 new examples have been added to show the new raylib features.
Lots of code changes and lot of testing have concluded in this amazing new raylib 1.3.
notes on raylib 1.4
-------------------
On February 2016, after 4 months of raylib 1.3 release, it comes raylib 1.4. For this new version, lots of parts of the library have been reviewed, lots of bugs have been solved and some interesting features have been added.
First big addition is a set of [Image manipulation functions](https://github.com/raysan5/raylib/blob/master/src/raylib.h#L673) have been added to crop, resize, colorize, flip, dither and even draw image-to-image or text-to-image. Now a basic image processing can be done before converting the image to texture for usage.
SpriteFonts system has been improved, adding support for AngelCode fonts (.fnt) and TrueType Fonts (using [stb_truetype](https://github.com/nothings/stb/blob/master/stb_truetype.h) helper library). Now raylib can read standard .fnt font data and also generate at loading a SpriteFont from a TTF file.
New [physac](https://github.com/raysan5/raylib/blob/master/src/physac.h) physics module for basic 2D physics support. Still in development but already functional. Module comes with some usage examples for basic jump and level interaction and also force-based physic movements.
[raymath](https://github.com/raysan5/raylib/blob/master/src/raymath.h) module has been reviewed; some bugs have been solved and the module has been converted to a header-only file for easier portability, optionally, functions can also be used as inline.
[gestures](https://github.com/raysan5/raylib/blob/master/src/gestures.c) module has redesigned and simplified, now it can process touch events from any source, including mouse. This way, gestures system can be used on any platform providing an unified way to work with inputs and allowing the user to create multiplatform games with only one source code.
Raspberry Pi input system has been redesigned to better read raw inputs using generic Linux event handlers (keyboard:`stdin`, mouse:`/dev/input/mouse0`, gamepad:`/dev/input/js0`). Gamepad support has also been added (experimental).
Other important improvements are the functional raycast system for 3D picking, including some ray collision-detection functions,
and the addition of two simple functions for persistent data storage. Now raylib user can save and load game data in a file (only some platforms supported). A simple [easings](https://github.com/raysan5/raylib/blob/master/src/easings.h) module has also been added for values animation.
Up to 8 new code examples have been added to show the new raylib features and +10 complete game samples have been provided to learn
how to create some classic games like Arkanoid, Asteroids, Missile Commander, Snake or Tetris.
Lots of code changes and lots of hours of hard work have concluded in this amazing new raylib 1.4.
notes on raylib 1.5
-------------------
On July 2016, after 5 months of raylib 1.4 release, arrives raylib 1.5. This new version is the biggest boost of the library until now, lots of parts of the library have been redesigned, lots of bugs have been solved and some **AMAZING** new features have been added.
VR support: raylib supports **Oculus Rift CV1**, one of the most anticipated VR devices in the market. Additionally, raylib supports simulated VR stereo rendering, independent of the VR device; it means, raylib can generate stereo renders with custom head-mounted-display device parameteres, that way, any VR device in the market can be **simulated in any platform** just configuring device parameters (and consequently, lens distortion). To enable VR is [extremely easy](https://github.com/raysan5/raylib/blob/master/examples/core_oculus_rift.c).
New materials system: now raylib supports standard material properties for 3D models, including diffuse-ambient-specular colors and diffuse-normal-specular textures. Just assign values to standard material and everything is processed internally.
New lighting system: added support for up to 8 configurable lights and 3 light types: **point**, **directional** and **spot** lights. Just create a light, configure its parameters and raylib manages render internally for every 3d object using standard material.
Complete gamepad support on Raspberry Pi: Gamepad system has been completely redesigned. Now multiple gamepads can be easily configured and used; gamepad data is read and processed in raw mode in a second thread.
Redesigned physics module: [physac](https://github.com/raysan5/raylib/blob/master/src/physac.h) module has been converted to header only and usage [has been simplified](https://github.com/raysan5/raylib/blob/master/examples/physics_basic_rigidbody.c). Performance has also been singnificantly improved, now physic objects are managed internally in a second thread.
Audio chiptunese support and mixing channels: Added support for module audio music (.xm, .mod) loading and playing. Multiple mixing channels are now also supported. All this features thanks to the amazing work of @kd7tck.
Other additions include a [2D camera system](https://github.com/raysan5/raylib/blob/master/examples/core_2d_camera.c), render textures for offline render (and most comprehensive [postprocessing](https://github.com/raysan5/raylib/blob/master/examples/shaders_postprocessing.c)) or support for legacy OpenGL 2.1 on desktop platforms.
This new version is so massive that is difficult to list all the improvements, most of raylib modules have been reviewed and [rlgl](https://github.com/raysan5/raylib/blob/master/src/rlgl.c) module has been completely redesigned to accomodate to new material-lighting systems and stereo rendering. You can check [CHANGELOG](https://github.com/raysan5/raylib/blob/master/CHANGELOG) file for a more detailed list of changes.
Up to 8 new code examples have been added to show the new raylib features and also some samples to show the usage of [rlgl](https://github.com/raysan5/raylib/blob/master/examples/rlgl_standalone.c) and [audio](https://github.com/raysan5/raylib/blob/master/examples/audio_standalone.c) raylib modules as standalone libraries.
Lots of code changes (+400 commits) and lots of hours of hard work have concluded in this amazing new raylib 1.5.
notes on raylib 1.6
-------------------
On November 2016, only 4 months after raylib 1.5, arrives raylib 1.6. This new version represents another big review of the library and includes some interesting additions. This version conmmemorates raylib 3rd anniversary (raylib 1.0 was published on November 2013) and it is a stepping stone for raylib future. raylib roadmap has been reviewed and redefined to focus on its primary objective: create a simple and easy-to-use library to learn videogames programming. Some of the new features:
Complete [raylib Lua binding](https://github.com/raysan5/raylib-lua). All raylib functions plus the +60 code examples have been ported to Lua, now Lua users can enjoy coding videogames in Lua while using all the internal power of raylib. This addition also open the doors to Lua scripting support for a future raylib-based engine, being able to move game logic (Init, Update, Draw, De-Init) to Lua scripts while keep using raylib functionality.
Completely redesigned [audio module](https://github.com/raysan5/raylib/blob/master/src/raudio.c). Based on the new direction taken in raylib 1.5, it has been further improved and more functionality added (+20 new functions) to allow raw audio processing and streaming. [FLAC file format support](https://github.com/raysan5/raylib/blob/master/src/external/dr_flac.h) has also been added. In the same line, [OpenAL Soft](https://github.com/kcat/openal-soft) backend is now provided as a static library in Windows to allow static linking and get ride of OpenAL32.dll. Now raylib Windows games are completey self-contained, no external libraries required any more!
[Physac](https://github.com/victorfisac/Physac) module has been moved to its own repository and it has been improved A LOT, actually, library has been completely rewritten from scratch by [@victorfisac](https://github.com/victorfisac), multiple samples have been added together with countless new features to match current standard 2D physic libraries. Results are amazing!
Camera and gestures modules have been reviewed, highly simplified and ported to single-file header-only libraries for easier portability and usage flexibility. Consequently, camera system usage has been simplified in all examples.
Improved Gamepad support on Windows and Raspberry Pi with the addition of new functions for custom gamepad configurations but supporting by default PS3 and Xbox-based gamepads.
Improved textures and text functionality, adding new functions for texture filtering control and better TTF/AngelCode fonts loading and generation support.
Build system improvement. Added support for raylib dynamic library generation (raylib.dll) for users that prefer dynamic library linking. Also thinking on advance users, it has been added pre-configured [Visual Studio C++ 2015 solution](https://github.com/raysan5/raylib/tree/master/project/vs2015) with raylib project and C/C++ examples for users that prefer that professional IDE and compiler.
New examples, new functions, complete code-base review, multiple bugs corrected... this is raylib 1.6. Enjoy making games.
notes on raylib 1.7
-------------------
On May 2017, around 6 month after raylib 1.6, comes another raylib instalment, raylib 1.7. This time library has been improved a lot in terms of consistency and cleanness. As stated in [this patreon article](https://www.patreon.com/posts/raylib-future-7501034), this new raylib version has focused efforts in becoming more simple and easy-to-use to learn videogames programming. Some highlights of this new version are:
More than 30 new functions added to the library, functions to control Window, utils to work with filenames and extensions, functions to draw lines with custom thick, mesh loading, functions for 3d ray collisions detailed detection, funtions for VR simulation and much more... Just check [CHANGELOG](CHANGELOG) for a detailed list of additions!
Support of [configuration flags](https://github.com/raysan5/raylib/issues/200) on every raylib module. Advance users can customize raylib just choosing desired features, defining some configuration flags on modules compilation. That way users can control library size and available functionality.
Improved [build system](https://github.com/raysan5/raylib/blob/master/src/Makefile) for all supported platforms (Windows, Linux, OSX, RPI, Android, HTML5) with a unique Makefile to compile sources. Added support for Android compilation with a custom standalone toolchain and also multiple build compliation flags.
New [examples](http://www.raylib.com/examples.html) and [sample games](http://www.raylib.com/games.html) added. All samples material has been reviewed, removing useless examples and adding more comprehensive ones; all material has been ported to latest raylib version and tested in multiple platforms. Examples folder structure has been improved and also build systems.
Improved library consistency and organization in general. Functions and parameters have been renamed, some parts of the library have been cleaned and simplyfied, some functions has been moved to examples (lighting, Oculus Rift CV1 support) towards a more generic library implementation. Lots of hours have been invested in this process...
Some other features: Gamepad support on HTML5, RPI touch screen support, 32bit audio support, frames timing improvements, public log system, rres file format support, automatic GIF recording...
And here it is another version of **raylib, a simple and easy-to-use library to enjoy videogames programming**. Enjoy it.
notes on raylib 1.8
-------------------
October 2017, around 5 months after latest raylib version, another release is published: raylib 1.8. Again, several modules of the library have been reviewed and some new functionality added. Main changes of this new release are:
[Procedural image generation](https://github.com/raysan5/raylib/blob/master/examples/textures/textures_image_generation.c) function, a set of new functions have been added to generate gradients, checked, noise and cellular images from scratch. Image generation could be useful for certain textures or learning pourpouses.
[Parametric mesh generation](https://github.com/raysan5/raylib/blob/master/examples/models/models_mesh_generation.c) functions, create 3d meshes from scratch just defining a set of parameters, meshes like cube, sphere, cylinder, torus, knot and more can be very useful for prototyping or for lighting and texture testing.
PBR Materials support, a completely redesigned shaders and material system allows advance materials definition and usage, with fully customizable shaders. Some new functions have been added to generate the environment textures required for PBR shading and a a new complete [PBR material example](https://github.com/raysan5/raylib/blob/master/examples/models/models_material_pbr.c) is also provided for reference.
Custom Android APK build pipeline with [simple Makefile](https://github.com/raysan5/raylib/blob/master/templates/simple_game/Makefile). Actually, full code building mechanism based on plain Makefile has been completely reviewed and Android building has been added for sources and also for examples and templates building into final APK package. This way, raylib Android building has been greatly simplified and integrated seamlessly into standard build scripts.
[rlgl](https://github.com/raysan5/raylib/blob/master/src/rlgl.h) module has been completely reviewed and most of the functions renamed for consistency. This way, standalone usage of rlgl is promoted, with a [complete example provided](https://github.com/raysan5/raylib/blob/master/examples/others/rlgl_standalone.c). rlgl offers a pseudo-OpenGL 1.1 immediate-mode programming-style layer, with backends to multiple OpenGL versions.
[raymath](https://github.com/raysan5/raylib/blob/master/src/raymath.h) library has been also reviewed to align with other advance math libraries like [GLM](https://github.com/g-truc/glm). Matrix math has been improved and simplified, some new Quaternion functions have been added and Vector3 functions have been renamed all around the library for consistency with new Vector2 functionality.
Additionally, as always, examples and templates have been reviewed to work with new version (some new examples have been added), all external libraries have been updated to latest stable version and latest Notepad++ and MinGW have been configured to work with new raylib. For a full list of changes, just check [CHANGELOG](CHANGELOG).
New installer provided, web updated, examples re-builded, documentation reviewed... **new raylib 1.8 published**. Enjoy coding games.
notes on raylib 2.0
-------------------
It's been 9 month since last raylib version was published, a lots of things have changed since then... This new raylib version represents an inflexion point in the development of the library and so, we jump to a new major version... Here it is the result of almost **5 years and thousands of hours of hard work**... here it is... **raylib 2.0**
In **raylib 2.0** the full API has been carefully reviewed for better consistency, some new functionality has been added and the overall raylib experience has been greatly improved... The key features of new version are:
**Complete removal of external dependencies.** Finally, raylib does not require external libraries to be installed and linked along with raylib, all required libraries are contained and compiled within raylib. Obviously some external libraries are required but only the strictly platform-dependant ones, the ones that come installed with the OS. So, raylib becomes a self-contained platform-independent games development library.
**Full redesign of audio module to use the amazing miniaudio library**, along with external dependencies removal, OpenAL library has been replaced by [miniaudio](https://github.com/dr-soft/miniaudio), this brand new library offers automatic dynamic linking with default OS audio systems. Undoubtly, the perfect low-level companion for raylib audio module!
**Support for continuous integration building*** through AppVeyor and Travis CI. Consequently, raylib GitHub develop branch has been removed, simplyfing the code-base to a single master branch, always stable. Every time a new commit is deployed, library is compiled for **up-to 12 different configurations**, including multiple platforms, 32bit/64bit and multiple compiler options! All those binaries are automatically attached to any new release!
**More platforms supported and tested**, including BSD family (FreeBSD, openBSD, NetBSD, DragonFly) and Linux-based family platforms (openSUSE, Debian, Ubuntu, Arch, NixOS...). raylib has already been added to some package managers! Oh, and last but not less important, **Android 64bit** is already supported by raylib!
**Support for TCC compiler!** Thanks to the lack of external dependencies, raylib can now be easily compiled with a **minimal toolchain**, like the one provide by Tiny C Compiler. It opens the door to an amazing future, allowing, for example, static linkage of libtcc for **runtime compilation of raylib-based code**... and the library itself if required! Moreover, TCC is blazing fast, it can compile all raylib in a couple of seconds!
Refactored all raylib configuration #defines into a **centralized `config.h` header**, with more than **40 possible configuration options** to compile a totally customizable raylib version including only desired options like supported file-formats or specific functionality support. It allows generating a trully ligth-weight version of the library if desired!
A part of that, lots of new features, like a brand **new font rendering and packaging system** for TTF fonts with **SDF support** (thanks to the amazing STB headers), new functions for **CPU image data manipulation**, new orthographic 3d camera mode, a complete review of `raymath.h` single-file header-only library for better consistency and performance, new examples and way, [way more](https://github.com/raysan5/raylib/blob/master/CHANGELOG).
Probably by now, **raylib 2.0 is the simplest and easiest-to-use library to enjoy (and learn) videogames programming**... but, undoubtly its development has exceeded any initial objective; raylib has become a simple and easy-to-use trully multiplatform portable standalone media library with thousands of possibilities... and that's just the beginning!
notes on raylib 2.5
-------------------
After almost one years since latest raylib installment, here it is **raylib 2.5**. A lot of work has been put on this new version and consequently I decided to bump versioning several digits. The complete list of changes and additions is humungous, details can be found in the [CHANGELOG](CHANGELOG), and here it is a short recap with the highlight improvements.
New **window management and filesystem functions** to query monitor information, deal with clipboard, check directory files info and even launch a URL with default system web browser. Experimental **High-DPI monitor support** has also been added through a compile flag.
**Redesigned Gamepad mechanism**, now generic for all platforms and gamepads, no more specific gamepad configurations.
**Redesigned UWP input system**, now raylib supports UWP seamlessly, previous implementation required a custom input system implemented in user code.
`rlgl` module has been redesigned to **support a unique buffer for shapes drawing batching**, including LINES, TRIANGLES, QUADS in the same indexed buffer, also added support for multi-buffering if required. Additionally, `rlPushMatrix()`/`rlPopMatrix()` functionality has been reviewed to behave exactly like OpenGL 1.1, `models_rlgl_solar_system` example has been added to illustrate this behaviour.
**VR simulator** has been reviewed to **allow custom configuration of Head-Mounted-Device parameters and distortion shader**, `core_vr_simulator` has been properly adapted to showcase this new functionality, now the VR simulator is a generic configurable stereo rendering system that allows any VR device simulation with just a few lines of code or even dynamic tweaking of HMD parameters.
Support for **Unicode text drawing**; now raylib processes UTF8 strings on drawing, supporting Unicode codepoints, allowing rendering mostly any existent language (as long as the font with the glyphs is provided). An amazing example showing this feature has also been added: `text_unicode`.
Brand **new text management API**, with the addition of multiple functions to deal with string data, including functionality like replace, insert, join, split, append, to uppercase, to lower... Note that most of those functions are intended for text management on rendering, using pre-loaded internal buffers, avoiding new memory allocation that user should free manually.
Multiple **new shapes and textures drawing functions** to support rings (`DrawRing()`, `DrawRingLines()`), circle sectors (`DrawCircleSector()`, `DrawCircleSectorLines()`), rounded rectangles (`DrawRectangleRounded()`, `DrawRectangleRoundedLines()`) and also n-patch textures (`DrawTextureNPatch()`), detailed examples have been added to illustrate all this new functionality.
Experimental **cubemap support**, to automatically load multiple cubemap layouts (`LoadTextureCubemap()`). It required some internal `rlgl` redesign to allow cubemap textures.
**Skeletal animation support for 3d models**, this addition implied a redesign of `Model` data structure to accomodate multiple mesh/multiple materials support and bones information. Multiple models functions have been reviewed and added on this process, also **glTF models loading support** has been added.
This is a just a brief list with some of the changes of the new **raylib 2.5** but there is way more, about **70 new functions** have been added and several subsystems have been redesigned. More than **30 new examples** have been created to show the new functionalities and better illustrate already available ones.
It has been a long year of hard work to make raylib a solid technology to develop new products over it.
raylib is licensed under an unmodified zlib/libpng license, which is an OSI-certified,
BSD-like license that allows static linking with closed source software:
Copyright (c) 2013 Ramon Santamaria (Ray San - raysan@raysanweb.com)
Copyright (c) 2013-2019 Ramon Santamaria (@raysan5)
This software is provided "as-is", without any express or implied warranty. In no event
will the authors be held liable for any damages arising from the use of this software.
@@ -27,7 +27,7 @@ applications, and to alter it and redistribute it freely, subject to the followi
fonts
------
All rBMF fonts provided with raylib are free to use (freeware) and have been designed by the following people:
The following fonts [provided with raylib](https://github.com/raysan5/raylib/tree/master/examples/text/resources/fonts) are free to use (freeware) and have been designed by the following people:
* Alpha Beta - Brian Kent (AEnigma)
* Setback - Brian Kent (AEnigma)
@@ -38,344 +38,14 @@ All rBMF fonts provided with raylib are free to use (freeware) and have been des
* PixelPlay - Aleksander Shevchuk
* PixAntiqua - Gerhard Großmann
2d art
------
[scarfy spritesheet](https://github.com/raysan5/raylib/blob/master/examples/textures/resources/scarfy.png) and [fudesumi image](https://github.com/raysan5/raylib/blob/master/examples/textures/resources/fudesumi.png) have been created by [Eiden Marsal](https://www.artstation.com/artist/marshall_z) and are licensed as [Creative Commons Attribution-NonCommercial 3.0](https://creativecommons.org/licenses/by-nc/3.0/legalcode)
[cyberpunk street environments](https://github.com/raysan5/raylib/blob/master/examples/textures/resources) have been created by Luis Zuno ([@ansimuz](https://twitter.com/ansimuz)) and are licensed as [CC-BY-3.0](http://creativecommons.org/licenses/by/3.0/)
3d models
---------
dwarf 3d model used in examples is created by David Moreno and licensed as Creative Commons Attribution-NonCommercial 3.0
Full license provided below:
Creative Commons Legal Code
Attribution-NonCommercial 3.0 Unported
CREATIVE COMMONS CORPORATION IS NOT A LAW FIRM AND DOES NOT PROVIDE
LEGAL SERVICES. DISTRIBUTION OF THIS LICENSE DOES NOT CREATE AN
ATTORNEY-CLIENT RELATIONSHIP. CREATIVE COMMONS PROVIDES THIS
INFORMATION ON AN "AS-IS" BASIS. CREATIVE COMMONS MAKES NO WARRANTIES
REGARDING THE INFORMATION PROVIDED, AND DISCLAIMS LIABILITY FOR
DAMAGES RESULTING FROM ITS USE.
License
THE WORK (AS DEFINED BELOW) IS PROVIDED UNDER THE TERMS OF THIS CREATIVE
COMMONS PUBLIC LICENSE ("CCPL" OR "LICENSE"). THE WORK IS PROTECTED BY
COPYRIGHT AND/OR OTHER APPLICABLE LAW. ANY USE OF THE WORK OTHER THAN AS
AUTHORIZED UNDER THIS LICENSE OR COPYRIGHT LAW IS PROHIBITED.
BY EXERCISING ANY RIGHTS TO THE WORK PROVIDED HERE, YOU ACCEPT AND AGREE
TO BE BOUND BY THE TERMS OF THIS LICENSE. TO THE EXTENT THIS LICENSE MAY
BE CONSIDERED TO BE A CONTRACT, THE LICENSOR GRANTS YOU THE RIGHTS
CONTAINED HERE IN CONSIDERATION OF YOUR ACCEPTANCE OF SUCH TERMS AND
CONDITIONS.
1. Definitions
a. "Adaptation" means a work based upon the Work, or upon the Work and
other pre-existing works, such as a translation, adaptation,
derivative work, arrangement of music or other alterations of a
literary or artistic work, or phonogram or performance and includes
cinematographic adaptations or any other form in which the Work may be
recast, transformed, or adapted including in any form recognizably
derived from the original, except that a work that constitutes a
Collection will not be considered an Adaptation for the purpose of
this License. For the avoidance of doubt, where the Work is a musical
work, performance or phonogram, the synchronization of the Work in
timed-relation with a moving image ("synching") will be considered an
Adaptation for the purpose of this License.
b. "Collection" means a collection of literary or artistic works, such as
encyclopedias and anthologies, or performances, phonograms or
broadcasts, or other works or subject matter other than works listed
in Section 1(f) below, which, by reason of the selection and
arrangement of their contents, constitute intellectual creations, in
which the Work is included in its entirety in unmodified form along
with one or more other contributions, each constituting separate and
independent works in themselves, which together are assembled into a
collective whole. A work that constitutes a Collection will not be
considered an Adaptation (as defined above) for the purposes of this
License.
c. "Distribute" means to make available to the public the original and
copies of the Work or Adaptation, as appropriate, through sale or
other transfer of ownership.
d. "Licensor" means the individual, individuals, entity or entities that
offer(s) the Work under the terms of this License.
e. "Original Author" means, in the case of a literary or artistic work,
the individual, individuals, entity or entities who created the Work
or if no individual or entity can be identified, the publisher; and in
addition (i) in the case of a performance the actors, singers,
musicians, dancers, and other persons who act, sing, deliver, declaim,
play in, interpret or otherwise perform literary or artistic works or
expressions of folklore; (ii) in the case of a phonogram the producer
being the person or legal entity who first fixes the sounds of a
performance or other sounds; and, (iii) in the case of broadcasts, the
organization that transmits the broadcast.
f. "Work" means the literary and/or artistic work offered under the terms
of this License including without limitation any production in the
literary, scientific and artistic domain, whatever may be the mode or
form of its expression including digital form, such as a book,
pamphlet and other writing; a lecture, address, sermon or other work
of the same nature; a dramatic or dramatico-musical work; a
choreographic work or entertainment in dumb show; a musical
composition with or without words; a cinematographic work to which are
assimilated works expressed by a process analogous to cinematography;
a work of drawing, painting, architecture, sculpture, engraving or
lithography; a photographic work to which are assimilated works
expressed by a process analogous to photography; a work of applied
art; an illustration, map, plan, sketch or three-dimensional work
relative to geography, topography, architecture or science; a
performance; a broadcast; a phonogram; a compilation of data to the
extent it is protected as a copyrightable work; or a work performed by
a variety or circus performer to the extent it is not otherwise
considered a literary or artistic work.
g. "You" means an individual or entity exercising rights under this
License who has not previously violated the terms of this License with
respect to the Work, or who has received express permission from the
Licensor to exercise rights under this License despite a previous
violation.
h. "Publicly Perform" means to perform public recitations of the Work and
to communicate to the public those public recitations, by any means or
process, including by wire or wireless means or public digital
performances; to make available to the public Works in such a way that
members of the public may access these Works from a place and at a
place individually chosen by them; to perform the Work to the public
by any means or process and the communication to the public of the
performances of the Work, including by public digital performance; to
broadcast and rebroadcast the Work by any means including signs,
sounds or images.
i. "Reproduce" means to make copies of the Work by any means including
without limitation by sound or visual recordings and the right of
fixation and reproducing fixations of the Work, including storage of a
protected performance or phonogram in digital form or other electronic
medium.
2. Fair Dealing Rights. Nothing in this License is intended to reduce,
limit, or restrict any uses free from copyright or rights arising from
limitations or exceptions that are provided for in connection with the
copyright protection under copyright law or other applicable laws.
3. License Grant. Subject to the terms and conditions of this License,
Licensor hereby grants You a worldwide, royalty-free, non-exclusive,
perpetual (for the duration of the applicable copyright) license to
exercise the rights in the Work as stated below:
a. to Reproduce the Work, to incorporate the Work into one or more
Collections, and to Reproduce the Work as incorporated in the
Collections;
b. to create and Reproduce Adaptations provided that any such Adaptation,
including any translation in any medium, takes reasonable steps to
clearly label, demarcate or otherwise identify that changes were made
to the original Work. For example, a translation could be marked "The
original work was translated from English to Spanish," or a
modification could indicate "The original work has been modified.";
c. to Distribute and Publicly Perform the Work including as incorporated
in Collections; and,
d. to Distribute and Publicly Perform Adaptations.
The above rights may be exercised in all media and formats whether now
known or hereafter devised. The above rights include the right to make
such modifications as are technically necessary to exercise the rights in
other media and formats. Subject to Section 8(f), all rights not expressly
granted by Licensor are hereby reserved, including but not limited to the
rights set forth in Section 4(d).
4. Restrictions. The license granted in Section 3 above is expressly made
subject to and limited by the following restrictions:
a. You may Distribute or Publicly Perform the Work only under the terms
of this License. You must include a copy of, or the Uniform Resource
Identifier (URI) for, this License with every copy of the Work You
Distribute or Publicly Perform. You may not offer or impose any terms
on the Work that restrict the terms of this License or the ability of
the recipient of the Work to exercise the rights granted to that
recipient under the terms of the License. You may not sublicense the
Work. You must keep intact all notices that refer to this License and
to the disclaimer of warranties with every copy of the Work You
Distribute or Publicly Perform. When You Distribute or Publicly
Perform the Work, You may not impose any effective technological
measures on the Work that restrict the ability of a recipient of the
Work from You to exercise the rights granted to that recipient under
the terms of the License. This Section 4(a) applies to the Work as
incorporated in a Collection, but this does not require the Collection
apart from the Work itself to be made subject to the terms of this
License. If You create a Collection, upon notice from any Licensor You
must, to the extent practicable, remove from the Collection any credit
as required by Section 4(c), as requested. If You create an
Adaptation, upon notice from any Licensor You must, to the extent
practicable, remove from the Adaptation any credit as required by
Section 4(c), as requested.
b. You may not exercise any of the rights granted to You in Section 3
above in any manner that is primarily intended for or directed toward
commercial advantage or private monetary compensation. The exchange of
the Work for other copyrighted works by means of digital file-sharing
or otherwise shall not be considered to be intended for or directed
toward commercial advantage or private monetary compensation, provided
there is no payment of any monetary compensation in connection with
the exchange of copyrighted works.
c. If You Distribute, or Publicly Perform the Work or any Adaptations or
Collections, You must, unless a request has been made pursuant to
Section 4(a), keep intact all copyright notices for the Work and
provide, reasonable to the medium or means You are utilizing: (i) the
name of the Original Author (or pseudonym, if applicable) if supplied,
and/or if the Original Author and/or Licensor designate another party
or parties (e.g., a sponsor institute, publishing entity, journal) for
attribution ("Attribution Parties") in Licensor's copyright notice,
terms of service or by other reasonable means, the name of such party
or parties; (ii) the title of the Work if supplied; (iii) to the
extent reasonably practicable, the URI, if any, that Licensor
specifies to be associated with the Work, unless such URI does not
refer to the copyright notice or licensing information for the Work;
and, (iv) consistent with Section 3(b), in the case of an Adaptation,
a credit identifying the use of the Work in the Adaptation (e.g.,
"French translation of the Work by Original Author," or "Screenplay
based on original Work by Original Author"). The credit required by
this Section 4(c) may be implemented in any reasonable manner;
provided, however, that in the case of a Adaptation or Collection, at
a minimum such credit will appear, if a credit for all contributing
authors of the Adaptation or Collection appears, then as part of these
credits and in a manner at least as prominent as the credits for the
other contributing authors. For the avoidance of doubt, You may only
use the credit required by this Section for the purpose of attribution
in the manner set out above and, by exercising Your rights under this
License, You may not implicitly or explicitly assert or imply any
connection with, sponsorship or endorsement by the Original Author,
Licensor and/or Attribution Parties, as appropriate, of You or Your
use of the Work, without the separate, express prior written
permission of the Original Author, Licensor and/or Attribution
Parties.
d. For the avoidance of doubt:
i. Non-waivable Compulsory License Schemes. In those jurisdictions in
which the right to collect royalties through any statutory or
compulsory licensing scheme cannot be waived, the Licensor
reserves the exclusive right to collect such royalties for any
exercise by You of the rights granted under this License;
ii. Waivable Compulsory License Schemes. In those jurisdictions in
which the right to collect royalties through any statutory or
compulsory licensing scheme can be waived, the Licensor reserves
the exclusive right to collect such royalties for any exercise by
You of the rights granted under this License if Your exercise of
such rights is for a purpose or use which is otherwise than
noncommercial as permitted under Section 4(b) and otherwise waives
the right to collect royalties through any statutory or compulsory
licensing scheme; and,
iii. Voluntary License Schemes. The Licensor reserves the right to
collect royalties, whether individually or, in the event that the
Licensor is a member of a collecting society that administers
voluntary licensing schemes, via that society, from any exercise
by You of the rights granted under this License that is for a
purpose or use which is otherwise than noncommercial as permitted
under Section 4(c).
e. Except as otherwise agreed in writing by the Licensor or as may be
otherwise permitted by applicable law, if You Reproduce, Distribute or
Publicly Perform the Work either by itself or as part of any
Adaptations or Collections, You must not distort, mutilate, modify or
take other derogatory action in relation to the Work which would be
prejudicial to the Original Author's honor or reputation. Licensor
agrees that in those jurisdictions (e.g. Japan), in which any exercise
of the right granted in Section 3(b) of this License (the right to
make Adaptations) would be deemed to be a distortion, mutilation,
modification or other derogatory action prejudicial to the Original
Author's honor and reputation, the Licensor will waive or not assert,
as appropriate, this Section, to the fullest extent permitted by the
applicable national law, to enable You to reasonably exercise Your
right under Section 3(b) of this License (right to make Adaptations)
but not otherwise.
5. Representations, Warranties and Disclaimer
UNLESS OTHERWISE MUTUALLY AGREED TO BY THE PARTIES IN WRITING, LICENSOR
OFFERS THE WORK AS-IS AND MAKES NO REPRESENTATIONS OR WARRANTIES OF ANY
KIND CONCERNING THE WORK, EXPRESS, IMPLIED, STATUTORY OR OTHERWISE,
INCLUDING, WITHOUT LIMITATION, WARRANTIES OF TITLE, MERCHANTIBILITY,
FITNESS FOR A PARTICULAR PURPOSE, NONINFRINGEMENT, OR THE ABSENCE OF
LATENT OR OTHER DEFECTS, ACCURACY, OR THE PRESENCE OF ABSENCE OF ERRORS,
WHETHER OR NOT DISCOVERABLE. SOME JURISDICTIONS DO NOT ALLOW THE EXCLUSION
OF IMPLIED WARRANTIES, SO SUCH EXCLUSION MAY NOT APPLY TO YOU.
6. Limitation on Liability. EXCEPT TO THE EXTENT REQUIRED BY APPLICABLE
LAW, IN NO EVENT WILL LICENSOR BE LIABLE TO YOU ON ANY LEGAL THEORY FOR
ANY SPECIAL, INCIDENTAL, CONSEQUENTIAL, PUNITIVE OR EXEMPLARY DAMAGES
ARISING OUT OF THIS LICENSE OR THE USE OF THE WORK, EVEN IF LICENSOR HAS
BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES.
7. Termination
a. This License and the rights granted hereunder will terminate
automatically upon any breach by You of the terms of this License.
Individuals or entities who have received Adaptations or Collections
from You under this License, however, will not have their licenses
terminated provided such individuals or entities remain in full
compliance with those licenses. Sections 1, 2, 5, 6, 7, and 8 will
survive any termination of this License.
b. Subject to the above terms and conditions, the license granted here is
perpetual (for the duration of the applicable copyright in the Work).
Notwithstanding the above, Licensor reserves the right to release the
Work under different license terms or to stop distributing the Work at
any time; provided, however that any such election will not serve to
withdraw this License (or any other license that has been, or is
required to be, granted under the terms of this License), and this
License will continue in full force and effect unless terminated as
stated above.
8. Miscellaneous
a. Each time You Distribute or Publicly Perform the Work or a Collection,
the Licensor offers to the recipient a license to the Work on the same
terms and conditions as the license granted to You under this License.
b. Each time You Distribute or Publicly Perform an Adaptation, Licensor
offers to the recipient a license to the original Work on the same
terms and conditions as the license granted to You under this License.
c. If any provision of this License is invalid or unenforceable under
applicable law, it shall not affect the validity or enforceability of
the remainder of the terms of this License, and without further action
by the parties to this agreement, such provision shall be reformed to
the minimum extent necessary to make such provision valid and
enforceable.
d. No term or provision of this License shall be deemed waived and no
breach consented to unless such waiver or consent shall be in writing
and signed by the party to be charged with such waiver or consent.
e. This License constitutes the entire agreement between the parties with
respect to the Work licensed here. There are no understandings,
agreements or representations with respect to the Work not specified
here. Licensor shall not be bound by any additional provisions that
may appear in any communication from You. This License may not be
modified without the mutual written agreement of the Licensor and You.
f. The rights granted under, and the subject matter referenced, in this
License were drafted utilizing the terminology of the Berne Convention
for the Protection of Literary and Artistic Works (as amended on
September 28, 1979), the Rome Convention of 1961, the WIPO Copyright
Treaty of 1996, the WIPO Performances and Phonograms Treaty of 1996
and the Universal Copyright Convention (as revised on July 24, 1971).
These rights and subject matter take effect in the relevant
jurisdiction in which the License terms are sought to be enforced
according to the corresponding provisions of the implementation of
those treaty provisions in the applicable national law. If the
standard suite of rights granted under applicable copyright law
includes additional rights not granted under this License, such
additional rights are deemed to be included in the License; this
License is not intended to restrict the license of any rights under
applicable law.
Creative Commons Notice
Creative Commons is not a party to this License, and makes no warranty
whatsoever in connection with the Work. Creative Commons will not be
liable to You or any party on any legal theory for any damages
whatsoever, including without limitation any general, special,
incidental or consequential damages arising in connection to this
license. Notwithstanding the foregoing two (2) sentences, if Creative
Commons has expressly identified itself as the Licensor hereunder, it
shall have all rights and obligations of Licensor.
Except for the limited purpose of indicating to the public that the
Work is licensed under the CCPL, Creative Commons does not authorize
the use by either party of the trademark "Creative Commons" or any
related trademark or logo of Creative Commons without the prior
written consent of Creative Commons. Any permitted use will be in
compliance with Creative Commons' then-current trademark usage
guidelines, as may be published on its website or otherwise made
available upon request from time to time. For the avoidance of doubt,
this trademark restriction does not form part of the License.
Creative Commons may be contacted at https://creativecommons.org/.
[medieval city 3d models and textures](https://github.com/raysan5/raylib/tree/master/examples/models/resources/medieval) have been created by Alberto Cano and are licensed as [Creative Commons Attribution-NonCommercial 4.0](https://creativecommons.org/licenses/by-nc/4.0/legalcode)
**raylib is a simple and easy-to-use library to enjoy videogames programming.**
raylib is a simple and easy-to-use library to learn videogames programming.
raylib is highly inspired by Borland BGI graphics lib and by XNA framework and it's specially well suited for prototyping, tooling, graphical applications, embedded systems and education.
raylib is highly inspired by Borland BGI graphics lib and by XNA framework.
*NOTE for ADVENTURERS: raylib is a programming library to enjoy videogames programming; no fancy interface, no visual helpers, no auto-debugging... just coding in the most pure spartan-programmers way.*
NOTE for ADVENTURERS: raylib is a programming library to learn videogames programming;
no fancy interface, no visual helpers, no auto-debugging... just coding in the most
pure spartan-programmers way. Are you ready to learn? Jump to [code examples!](http://www.raylib.com/examples.htm)
Ready to learn? Jump to [code examples!](http://www.raylib.com/examples.html)
history
-------
I've developed videogames for some years and 4 years ago I started teaching videogames development
to young people with artistic profile, most of them had never written a single line of code.
I started with C language basis and, after searching for the most simple and easy-to-use library to teach
videogames programming, I found WinBGI; it was great and it worked very well with students, in just a
couple of weeks that people that had never written a single line of code were able to program (and understand)
a simple PONG and some of them even a BREAKOUT!
But WinBGI was not the clearer and most organized lib. There were a lot of things I found useless and
confusing and some function names were not clear enough for most of the students; not to mention points
like no transparencies support or no hardware acceleration.
So, I decided to create my own lib, hardware accelerated, clear function names, quite organized, well structured,
plain C coding and, the most important, primarily intended to LEARN videogames programming.
I've coded quite a lot in C# and XNA and I really love it (in fact, my students learn C# after C),
so, I decided to use C# language notation and XNA naming conventions. That way, students can jump from
raylib to XNA, MonoGame or similar libs extremely easily.
raylib started as a weekend project and after three months of hard work, raylib 1.0 was published on November 2013.
Enjoy it.
notes on raylib 1.1
-------------------
On April 2014, after 6 month of first raylib release, raylib 1.1 has been released. This new version presents a
complete internal redesign of the library to support OpenGL 1.1, OpenGL 3.3+ and OpenGL ES 2.0.
A new module named [rlgl](https://github.com/raysan5/raylib/blob/master/src/rlgl.h) has been added to the library. This new module translate raylib-OpenGL-style
immediate mode functions (i.e. rlVertex3f(), rlBegin(), ...) to different versions of OpenGL (1.1, 3.3+, ES2), selectable by one define.
[rlgl](https://github.com/raysan5/raylib/blob/master/src/rlgl.h) also comes with a second new module named [raymath](https://github.com/raysan5/raylib/blob/master/src/raymath.h), which includes
a bunch of useful functions for 3d-math with vectors, matrices and quaternions.
Some other big changes of this new version have been the support for OGG files loading and stream playing, and the
support of DDS texture files (compressed and uncompressed) along with mipmaps support.
Lots of code changes and lot of testing have concluded in this amazing new raylib 1.1.
notes on raylib 1.2
-------------------
On September 2014, after 5 month of raylib 1.1 release, it comes raylib 1.2. Again, this version presents a
complete internal redesign of [core](https://github.com/raysan5/raylib/blob/master/src/core.c) module to support two new platforms: [Android](http://www.android.com/) and [Raspberry Pi](http://www.raspberrypi.org/).
It's been some month of really hard work to accomodate raylib to those new platforms while keeping it easy for the user.
On Android, raylib manages internally the activity cicle, as well as the inputs; on Raspberry Pi, a complete raw input
system has been written from scratch.
A new display initialization system has been created to support multiple resolutions, adding black bars if required;
user only defines desired screen size and it gets properly displayed.
Now raylib can easily deploy games to Android devices and Raspberry Pi (console mode).
Lots of code changes and lot of testing have concluded in this amazing new raylib 1.2.
In December 2014, new raylib 1.2.2 was published with support to compile directly for web (html5) using [emscripten](http://kripken.github.io/emscripten-site/) and [asm.js](http://asmjs.org/).
notes on raylib 1.3
-------------------
On September 2015, after 1 year of raylib 1.2 release, arrives raylib 1.3. This version adds shaders functionality,
improves tremendously textures module and also provides some new modules (camera system, gestures system, IMGUI).
Shaders support is the biggest addition to raylib 1.3, with support for easy shaders loading and use. Loaded shaders can be
attached to 3d models or used as fullscreen postrocessing effects. A bunch of postprocessing shaders are also included
in this release, check raylib/shaders folder.
Textures module has grown to support most of the internal texture formats available in OpenGL (RGB565, RGB888, RGBA5551, RGBA4444, etc.),
including compressed texture formats (DXT, ETC1, ETC2, ASTC, PVRT); raylib 1.3 can load .dds, .pkm, .ktx, .astc and .pvr files.
A brand new [camera](https://github.com/raysan5/raylib/blob/develop/src/camera.c) module offers to the user multiple preconfigured ready-to-use camera systems (free camera, 1st person, 3rd person).
Camera modes are very easy to use, just check examples: [core_3d_camera_free.c](https://github.com/raysan5/raylib/blob/develop/examples/core_3d_camera_free.c) and [core_3d_camera_first_person.c](https://github.com/raysan5/raylib/blob/develop/examples/core_3d_camera_first_person.c).
New [gestures](https://github.com/raysan5/raylib/blob/develop/src/gestures.h) module simplifies gestures detection on Android and HTML5 programs.
[raygui](https://github.com/raysan5/raylib/blob/develop/src/raygui.h), the new IMGUI (Immediate Mode GUI) module offers a set of functions to create simple user interfaces,
primary intended for tools development. It's still in experimental state but already fully functional.
Most of the examples have been completely rewritten and +10 new examples have been added to show the new raylib features.
Lots of code changes and lot of testing have concluded in this amazing new raylib 1.3.
notes on raylib 1.4
-------------------
On February 2016, after 4 months of raylib 1.3 release, it comes raylib 1.4. For this new version, lots of parts of the library have been reviewed, lots of bugs have been solved and some interesting features have been added.
First big addition is a set of [Image manipulation functions](https://github.com/raysan5/raylib/blob/develop/src/raylib.h#L673) have been added to crop, resize, colorize, flip, dither and even draw image-to-image or text-to-image. Now a basic image processing can be done before converting the image to texture for usage.
SpriteFonts system has been improved, adding support for AngelCode fonts (.fnt) and TrueType Fonts (using [stb_truetype](https://github.com/nothings/stb/blob/master/stb_truetype.h) helper library). Now raylib can read standard .fnt font data and also generate at loading a SpriteFont from a TTF file.
New [physac](https://github.com/raysan5/raylib/blob/develop/src/physac.h) physics module for basic 2D physics support. Still in development but already functional. Module comes with some usage examples for basic jump and level interaction and also force-based physic movements.
[raymath](https://github.com/raysan5/raylib/blob/develop/src/raymath.h) module has been reviewed; some bugs have been solved and the module has been converted to a header-only file for easier portability, optionally, functions can also be used as inline.
[gestures](https://github.com/raysan5/raylib/blob/develop/src/gestures.c) module has redesigned and simplified, now it can process touch events from any source, including mouse. This way, gestures system can be used on any platform providing an unified way to work with inputs and allowing the user to create multiplatform games with only one source code.
Raspberry Pi input system has been redesigned to better read raw inputs using generic Linux event handlers (keyboard:`stdin`, mouse:`/dev/input/mouse0`, gamepad:`/dev/input/js0`). Gamepad support has also been added (experimental).
Other important improvements are the functional raycast system for 3D picking, including some ray collision-detection functions, and the addition of two simple functions for persistent data storage. Now raylib user can save and load game data in a file (only some platforms supported). A simple [easings](https://github.com/raysan5/raylib/blob/develop/src/easings.h) module has also been added for values animation.
Up to 8 new code examples have been added to show the new raylib features and +10 complete game samples have been provided to learn how to create some classic games like Arkanoid, Asteroids, Missile Commander, Snake or Tetris.
Lots of code changes and lots of hours of hard work have concluded in this amazing new raylib 1.4.
raylib uses on its core module the outstanding [GLFW3](http://www.glfw.org/) library. The best option by far I found for
multiplatform (Windows, Linux, Mac) window/context and input management (clean, focused, great license, well documented, modern, ...).
raylib uses on its [core](https://github.com/raysan5/raylib/blob/master/src/core.c) module the outstanding [GLFW3](http://www.glfw.org/) library, embedded in the form of [rglfw](https://github.com/raysan5/raylib/blob/master/src/rglfw.c) module, to avoid external dependencies.
raylib uses on its [audio](https://github.com/raysan5/raylib/blob/master/src/audio.c) module, [OpenAL Soft](http://kcat.strangesoft.net/openal.html) audio library, in multiple flavours,
to accomodate to Android, Raspberry Pi and HTML5.
raylib uses on its [raudio](https://github.com/raysan5/raylib/blob/master/src/raudio.c) module, the amazing [miniaudio](https://github.com/dr-soft/miniaudio) library to support multiple platforms and multiple audio backends.
On Android, raylib uses `native_app_glue module` (provided on Android NDK) and native Android libraries to manage window/context, inputs and activity cycle.
raylib uses internally multiple single-file header-only libraries to support different fileformats loading and saving, all those libraries are embedded with raylib and available in [src/external](https://github.com/raysan5/raylib/tree/master/src/external) directory. Check [raylib Wiki](https://github.com/raysan5/raylib/wiki/raylib-dependencies) for a detailed list.
On Raspberry Pi, raylib uses Videocore API and EGL for window/context management and raw inputs reading.
*On Android platform, `native_app_glue module` module (provided by Android NDK) and native Android libraries are used to manage window/context, inputs and activity life cycle.*
raylib is licensed under a zlib/libpng license. View [LICENSE](https://github.com/raysan5/raylib/blob/master/LICENSE.md).
*On Raspberry Pi platform (native mode), `Videocore API` and `EGL` libraries are used for window/context management. Inputs are processed using `evdev` Linux libraries*
tools requirements
------------------
build and installation
----------------------
raylib has been developed using exclusively two tools:
Binary releases for Windows, Linux and macOS are available at the [Github Releases page](https://github.com/raysan5/raylib/releases). raylib is also available via multiple package managers on multiple OS distributions. Check [raylib Wiki](https://github.com/raysan5/raylib/wiki) for more info.
If you wish to build raylib yourself, [the raylib Wiki](https://github.com/raysan5/raylib/wiki) also contains detailed instructions on how to approach that.
Those are the tools I recommend to develop with raylib, in fact, those are the tools my students use.
I believe those are the best tools to train spartan-programmers.
raylib has been developed using two tools:
Someone could argue about debugging. raylib is a library intended for learning and I think C it's a clear enough language
to allow writing small-mid size programs with a printf-based debugging. All raylib examples have also been written this way.
Since raylib v1.1, you can download a Windows Installer package for easy installation and configuration. Check [raylib Webpage](http://www.raylib.com/)
building source (generate libraylib.a)
--------------------------------------
Check raylib wiki page: [Building source](https://github.com/raysan5/raylib/wiki/Building-source)
building examples
-----------------
Check raylib wiki page: [Building examples](https://github.com/raysan5/raylib/wiki/Building-examples)
Those are the tools recommended to enjoy raylib development.
If you are using raylib and you enjoy it, please, [let me know][raysan5].
If you are using raylib and you enjoy it, please, join our [Discord server](https://discord.gg/VkzNHUE).
If you feel you can help, then, [helpme!](http://www.raylib.com/helpme.htm)
license
-------
acknowledgements
---------------
The following people have contributed in some way to make raylib project a reality. Big thanks to them!
- [Zopokx](https://github.com/Zopokx) for testing the web.
- [Elendow](http://www.elendow.com) for testing and helping on web development.
- Victor Dual for implementating and testing of 3D shapes functions.
- Marc Palau for implementating and testing of 3D shapes functions and helping on development of camera and getures modules.
- Kevin Gato for improving texture internal formats support and helping on raygui development.
- Daniel Nicolas for improving texture internal formats support and helping on raygui development.
- Marc Agüera for testing and using raylib on a real product ([Koala Seasons](http://www.koalaseasons.com))
- Daniel Moreno for testing and using raylib on a real product ([Koala Seasons](http://www.koalaseasons.com))
- Daniel Gomez for testing and using raylib on a real product ([Koala Seasons](http://www.koalaseasons.com))
- Sergio Martinez for helping on raygui development and tools development.
- Victor Fisac for developing physics raylib module (physac) and implementing light shaders and raycast system... and multiple tools and games.
- Albert Martos for helping on raygui and porting examples and game-templates to Android and HTML5.
- Ian Eito for helping on raygui and porting examples and game-templates to Android and HTML5.
[raysan5]: mailto:raysan5@gmail.com "Ramon Santamaria - Ray San"
raylib is licensed under an unmodified zlib/libpng license, which is an OSI-certified, BSD-like license that allows static linking with closed source software. Check [LICENSE](LICENSE.md) for further details.
Current version of raylib is quite complete and functional but there is still a lot of things to add and improve.
Here it is a wish list of features I would like to add and functions to improve.
Here it is a wish-list with features and ideas to improve the library. Note that features listed here are quite high-level and could be long term additions for the library. Current version of raylib is complete and functional but there is a lot of room for improvement.
Note that around the raylib source code there are multiple TODO points with pending revisions/bugs. Check [GitHub Issues](https://github.com/raysan5/raylib/issues) for further details!
[raylib source code](https://github.com/raysan5/raylib/tree/master/src) has some *TODO* marks around code with pending things to review and improve.
Also, check [GitHub Issues](https://github.com/raysan5/raylib/issues) for further details!
raylib 1.5
**raylib 2.x**
- [ ] rnet: raylib network module
- [ ] rres: raylib resource packer
- [ ] rlvk: raylib Vulkan API support (GRAPHICS_API_VULKAN)
# Android APK building process... some steps required...
# NOTE: typing 'make' will invoke the default target entry called 'all',
all:create_temp_project_dirs \
copy_project_required_libs \
copy_project_resources \
generate_loader_script \
generate_android_manifest \
generate_apk_keystore \
config_project_package \
compile_project_code \
compile_project_class \
compile_project_class_dex \
create_project_apk_package \
sign_project_apk_package \
zipalign_project_apk_package
# Create required temp directories for APK building
create_temp_project_dirs:
if not exist $(PROJECT_BUILD_PATH) mkdir $(PROJECT_BUILD_PATH)
if not exist $(PROJECT_BUILD_PATH)\obj mkdir $(PROJECT_BUILD_PATH)\obj
if not exist $(PROJECT_BUILD_PATH)\src mkdir $(PROJECT_BUILD_PATH)\src
if not exist $(PROJECT_BUILD_PATH)\src\com mkdir $(PROJECT_BUILD_PATH)\src\com
if not exist $(PROJECT_BUILD_PATH)\src\com\$(APP_COMPANY_NAME) mkdir $(PROJECT_BUILD_PATH)\src\com\$(APP_COMPANY_NAME)
if not exist $(PROJECT_BUILD_PATH)\src\com\$(APP_COMPANY_NAME)\$(APP_PRODUCT_NAME) mkdir $(PROJECT_BUILD_PATH)\src\com\$(APP_COMPANY_NAME)\$(APP_PRODUCT_NAME)
if not exist $(PROJECT_BUILD_PATH)\lib mkdir $(PROJECT_BUILD_PATH)\lib
if not exist $(PROJECT_BUILD_PATH)\lib\$(ANDROID_ARCH_NAME) mkdir $(PROJECT_BUILD_PATH)\lib\$(ANDROID_ARCH_NAME)
if not exist $(PROJECT_BUILD_PATH)\bin mkdir $(PROJECT_BUILD_PATH)\bin
if not exist $(PROJECT_BUILD_PATH)\res mkdir $(PROJECT_BUILD_PATH)\res
if not exist $(PROJECT_BUILD_PATH)\res\drawable-ldpi mkdir $(PROJECT_BUILD_PATH)\res\drawable-ldpi
if not exist $(PROJECT_BUILD_PATH)\res\drawable-mdpi mkdir $(PROJECT_BUILD_PATH)\res\drawable-mdpi
if not exist $(PROJECT_BUILD_PATH)\res\drawable-hdpi mkdir $(PROJECT_BUILD_PATH)\res\drawable-hdpi
if not exist $(PROJECT_BUILD_PATH)\res\values mkdir $(PROJECT_BUILD_PATH)\res\values
if not exist $(PROJECT_BUILD_PATH)\assets mkdir $(PROJECT_BUILD_PATH)\assets
if not exist $(PROJECT_BUILD_PATH)\assets\$(PROJECT_RESOURCES_PATH) mkdir $(PROJECT_BUILD_PATH)\assets\$(PROJECT_RESOURCES_PATH)
if not exist $(PROJECT_BUILD_PATH)\obj\screens mkdir $(PROJECT_BUILD_PATH)\obj\screens
@echo public class NativeLoader extends android.app.NativeActivity { >> $(PROJECT_BUILD_PATH)/src/com/$(APP_COMPANY_NAME)/$(APP_PRODUCT_NAME)/NativeLoader.java
Some files were not shown because too many files have changed in this diff
Show More
Reference in New Issue
Block a user
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.