* new shapes example - penrose tile
* stack cleanup
* proper use of strnlen, strncat and strncpy
* typo correction
* update screenshot of shapes_penrose_tile example
* new example for strings management
* Improved structure for text_strings_management
* new shapes example - penrose tile
* stack cleanup
* proper use of strnlen, strncat and strncpy
* typo correction
* update screenshot of shapes_penrose_tile example
* Example for creating balls with simple physics simulation
The goal of this example is to create several colored balls whose movement is simulated and which respond to the action of being grabbed and dragged using the mouse.
* renaming example
renaming example from physics_bouncing_balls to shapes_ball_physics
This redesign stores lines in Update and draws stored lines in Draw, instead of previous approach of drawing directly to framebuffer with no cleaning. This approach allows some interesting features like line draw replay or reversing.
When SDL_GameControllerNameForIndex returns null, the app crashes. This was addressed earlier in PR#4859 though the fix submitted on PR #4859 was only fixing the crashing and not addressing the root cause.
* [examples] reset on folder click
`continue` after clicking a new folder
* [examples] don't make non-directories clickable
`IsPathFile` is not enough to check if it's a directory
since it also takes in char devices.
* rlparser: update raylib_api.* by CI
* Delete tools/rlparser/rlparser
---------
Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>
Co-authored-by: Ray <raysan5@gmail.com>
* use FLAG_* macros where possible
* rename `FLAG_CHECK()` to `FLAG_IS_SET()`
* remove unnecessary equality checks
* fix issues
---------
Co-authored-by: Ray <raysan5@gmail.com>
* consistency tweak
* unified color and depth buffer
* tweaks
* review the storage of clear values + complete get/set depth value
* copy/blit fast path
* better simd read/write
* framebuffer alignment
* fix 'typo'
my french slipped out
* simplified framebuffer management
* convert texture to rgba32
* remove float copy/blit
* adding SIMD framebuffer read/write
This adds SIMD framebuffer read/write, and also texel fetch.
This supports SSE2/SSE41 and SISD fallback (also includes ARM NEON support, conceptually identical but still needs testing).
* consistency
* tweaks
* review of `sw_texture_sample_linear`
* better quad sorting
unrelated to the PR, but at least it's done
* ignore some pipeline state in certains context
* convention tweaks
---------
Co-authored-by: Ray <raysan5@gmail.com>
SDL3 uses ID when dealing with monitors, unlike SDL2 which uses Index
for the same thing. This problem was already fixed in multiple places
by use of preprocessor branches, so I did the very same thing.
Please, notice that this is a pretty bad solution to this problem,
and I only did it to keep it consistent with the rest of the code.
The more about why it's not correct is mentioned here:
https://github.com/raysan5/raylib/issues/5256#issuecomment-3429156919
Hopefully, someone will refactor it someday :)
Fixes: https://github.com/raysan5/raylib/issues/5256
* [examples] Added: `shaders_mandelbrot_set`
* Simplified shader code and added comments
* Comments starting with a capital letter, and some minor fixes to adhere to the convention
Added and example demonstrating reading the contents of a file and rendering them,
utilizing rtext module. The demonstration also handles wrapping of long sentences,
and text scrolling.
Co-authored-by: Ray <raysan5@gmail.com>
* [Examples] Added shapes_particles
* Changes to follow the code conventions. Improved some things.
* Fixed name
* Fixed PNG name
---------
Co-authored-by: Ray <raysan5@gmail.com>
* Added shapes_pie_chart example
* Made the example colorful
* Added some interactivity to the example
* Revert top comment to the standard
* Remove unused MAX_SLICES constant
---------
Co-authored-by: Gideon Serfontein <gse@newspacesystems.com>
Co-authored-by: Ray <raysan5@gmail.com>
The tool can work with other libraries following `raylib.h` structure, keeping the `raylib_parser` name could be missleading. Also added an icon an reviewed Makefile an CI.
* Add core monitor change example
* Add monitor drawing and more information
* Update monitor information every frame
* Show info and window position inside the rectangle
* FIXED: rexm's makefile and default paths
Fixed a windows only backslash in
rexm's makefile causing build errors on macOS and linux
Added unix paths to rexm for better compatibility
* Update rexm.c
Readded the fall-through in OP_CREATE
Added some safety checks to UpdateRequiredFiles() so it plays nicely outside of the raylib.com context (would segfault previously)
* delta example
* clarification
* made it more clear what delta time is
* more explanation
* vector2 positions, removed all warnings
* removed keys, moved global to local, conventions & comments, show target fps
* new png
* remove more periods
* another period
* remove note about conventions, remove period
* add base of rlsw.h
* implement state support
Also replace the triangle rasterization functions with macros that generate specific functions for each state of the rendering system.
Also, add the OpenGL definitions in order to add a binding for rlgl.
* branchless float saturation
* apply perspective correction to colors
* impl line clipping and rasterization
+ tweak function names
* impl face culling
* impl color blending
* fixes and tweaks
* add clear buffer bitmasks
* small optimizations / tweaks
* review ndc to screen projection
* avoid to recalculate MVP when its not needed + tweaks
* review the loading and management of textures
to be closer to the OpenGL API
* texture sampling optimization
* review get pixel functions
+ review unorm/float conversion
* add several buffer format support
Several depth and color formats have been added for the framebuffer.
8-bit, 16-bit, and 24-bit formats are now available for depth.
RGB 8-bit (332), RGB 16-bit (565), and RGB 24-bit (888) formats are now available for color.
Alpha support is no longer present for the framebuffer at the moment, but it can easily be restored by adding the formats and reinterpolating the alpha in the areas that do not perform color blending.
Additionally, this commit brings performance improvements.
* tweaks
* impl line width
* impl points + point size
* fix and improve polygon clipping functions
* impl polygone modes
* add some not planned functions
- `glDepthMask`
- `glColorMask`
* framebuffer resizing + handle init failure
* add quick notes about line clipping algorithms used
* start to impl scissor test + review line clipping
The support for the scissor test has been implemented for clearing as well as for triangle clipping.
The implementation for lines and points is still missing.
I also removed the 2D clipping of lines that used the Cohen-Sutherland algorithm, opting instead to always use the Liang-Barsky algorithm in all cases.
This simplifies the implementation, and the 2D version would have caused issues when interpolating vertices in the future if we want to implement additional features.
* review scissor clear
* review `swScissor`
* impl line scissor clipping
* round screen coordinate (line rasterization)
* impl point scissor clipping
* remove unused defs
* add getter functions
* gl binding
* add `glHint` and `glShadeModel` macros (not implmented)
* binding tweaks
* impl copy framebuffer function + glReadPixels
* review `swCopyFramebuffer`
* update rlgl.h
* update rlgl.h
* texture copy support
* fix typo..
* add get error function
* def sw alloc macros
* reimpl get color buffer func
just in case
* remove normal interpolation
* review texture wrap
* fix ndc projection (viewport/scissor)
* impl framebuffer blit function
* reduce matrix compuations and memory usage
* swBegin tweaks
* preventing a possible division by zero
* remove useless scissor related data
* review color blending system
* greatly improve float saturation
* tweak lerp vertex function
* use opitmized fract function in sw_texture_map
* tweak framebuffer functions for better readability
* optimized copy/blit functions for each dst format
* review framebuffer filling functions
* impl specific quad rendering func
* use of a single global vertex buffer
* fix 'sw_poly_point_render'
* added `SW_RESTRICT` and redesigned `sw_lerp_vertex_PNCTH`
* tweak the pipeline flow regarding the face culling
avoids misprediction, improves vectorization if possible
* new rendering path for axis aligned quads
* oops, translating some comments
* use of `restrict` for blending function parameters
* update rlgl.h
* adding `GRAPHICS_API_OPENGL_11_SOFTWARE` in `DrawMesh`
* add `RL_OPENGL_11_SOFTWARE` enum
* temp tweak
* build fixes
* fix DrawMesh for GL 1.1
* update swClose
* review texture format + fix copy
* set minimum req vertices to 3 (quads)
* check swInit
* review pixelformat
* tweaks
* fix animNormals (DrawMesh)
* fallback color/texcoord (swDrawArrays)
* review swMultMatrixf
* fix texture pool alloc..
* review triangle scanlines
increment all data
* fix `sw_quad_sort_cw`
* impl sdl platform
* rm def
* increase max clipped polygon vertices
* improve triangle rasterization along Y axis
improved robustness against numerical errors
incremental interpolation along Y
simplified function, fewer jumps
* review current vertex data
+ increase max clipped polygon vertices (for extreme cases)
* fix and improve polygon clipping
Sets the vertex count to zero when the polygon is invalid
Stops clipping when the vertex count drops below 3
* fix gradient calculation
* cache texture size minus one + comments
* tweaks
* BGRA copy support
* adding software backend option (cmake)
* update Makefile
* fix face culling
* excluse some exemple with the software backend
* review SW_CLAMP case in sw_texture_map
* review sw_saturate
* review line raster
* fix sw_quad_is_aligned
* review sw_raster_quad_axis_aligned
* tweaks
* codepoint fix (?)
* fix var name...
* rcore_drm software renderering
* cleanup and tweaks
* adding support for `GL_POINT_SIZE` and `GL_LINE_WIDTH` get
* fix sampling issue
* fix swBlendFunc
---------
Co-authored-by: Ray <raysan5@gmail.com>
* adding core_input_actions
action based input API vs direct input, allows remapping of buttons or keys to an action.
* adjusted formatting.
* updates for struct name
and fixed a typo
* gate with OPENGL_11 prototype and definition for rlSetPointSize and rlGetPointSize
* gate with OPENGL_11 prototype and definition for rlSetPointSize and rlGetPointSize
* more coverage for fixing expected texcoords, normals, and colors
* fix guard styling
* fix guard issue, and remove fallback unneccessary else clause (default shader ill work)
* opengl3.3 and es2 need the color array allocated in order to allow for updates later (unlike opengl11)
Currently, scaling doesn't work correctly on macOS (see #5185). This commit
works around this issue by disabling SCALE_FRAMEBUFFER on macOS when
`FLAG_WINDOW_HIGHDPI` is unset.
* fix definition to use SDL3
* [cmake] fix definition to use SDL3
* [build][cmake] prefer USING_VERSION_SDL3 over PLATFORM_DESKTOP_SDL3
* [build][cmake] when libs are added externally, consumer needs to import them too
The following code would crash the previous version when calling MemFree:
// 53 * A
const char maliciousBase64Input[] = "AAAAAAAAAAAAAAAAAAAAAAAA"
"AAAAAAAAAAAAAAAAAAAAAAAAAAAAA";
int decodedSize = 0;
unsigned char *decodedData = DecodeDataBase64(
maliciousBase64Input, &decodedSize);
if (decodedData) {
MemFree(decodedData);
}
The reason is a lack of array bound checks in the decoding loop, which
corrupted here the heap (though this is platform dependent).
Adding the bound checks here prevents the memory corruption.
Tested with encoding random data of sizes 0-1023 and comparing it
with the decoded result.
This example was POSIX only and had some special requirements for web, it made it more difficult to be managed from collection standard examples format.
It will be re-added in the `others` category, that is not processed for web.
* add const qualifier to the first arg of TextJoin
* Update raylib_api.* by CI
* Update raylib.h
---------
Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>
Co-authored-by: Ray <raysan5@gmail.com>
This redesign is a big improvement on font loading time and memory requirements. It only loads glyphs available on font from requested codepoints and only processes those glyphs for packaging. When processing +10K codepoints (CJK), the loading time improves considerably.
Previously stated it was the near plane width in orthographic, in actuality it's the height. The wording has been fixed, with added clarity that it's in world units so no conversion is needed.
* win32 backend
* [rcore][win32] use SwapBuffers instead of wglSwapLayerBuffers
I don't understand OpenGL well enough to know the difference between
SwapBuffers and wglSwapLayerBuffers but the former seems to double
my FPS (from 2000 to about 4000 in core_vr_simulator).
* [rcore][win32] stop lying to the OS about when our window is updated
Instead of calling BeginPaint/EndPaint in WM_PAINT which signals to the
OS that our window content is updated, now when we encounter the WM_PAINT
message instead we return back to the raylib application which will
trigger it to render a new frame. We've replaced the call to BeginPaint
and EndPaint with a call to ValidateRect in SwapBuffers, which, means
we're now correctly telling the OS when our window content is actually
up-to-date.
Note that this doesn't fix the window content not being updated during
a window resize/move beacuse thos have their own message loop which
doesn't return early when it's time to paint.
* [rcore][win32] fallback to finding functions from opengl32.dll
* [rcore][win32] fixes from review/for gcc
* [rcore][win32] incorporate style conventions
* [rcore][win32] workaround unused function error SetupFramebuffer
* [rcore][win32] re-enable sanitize flags check for MSAA_4X
* [rcore][win32] more style changes and remove old DPI cases
Added some more missing spaces after conditional statements. Also
made unsupported MSAA_4X an assert instead of an abort and also
removed dpi-aware cases for older OS's. More changes would be needed
to support those OS versions, namely, removing the dependency
on shcore.
* [rcore][win32] fixes for compling with w64devkit without -DUNICODE
* Update build.zig
* Update build.zig
---------
Co-authored-by: Ray <raysan5@gmail.com>
* debug print the working directory
* trigger it on any branch (temporarily)
* nope, wrong fix
* dummy commit to trigger the workflow
* lets see if this works
* trigger the workflow when updating it
* nice typo
* add missing dollar signs
* debug list the contents of the repository
* dir/s instead of ls
* remove this, no longer needed
* backslashes maybe? windows...
* this should be a forward slash
* remove no longer needed spam
* debug check if examples dir exists
* LOG is disabled apparently
* ...
* temporarily disable this step to save time
* ubuntu maybe
* bash
* install deps
* link libc
* link libm
* now to test the rest
* emsdk is back
* add missing shaders
* Update examples collection
* add indentation
* remove emsdk cache
* ignore emsdk cache
* Update examples collection
* fix errors with the find command
* remove emsdk cache now
* i forgot to actually add it to gitignore
* fix error with git not finding anything to commit
* global config instead of repo specific
* clone raylib.com repo under the same owner as the raylib repo owner
* add proper access token
* reorganize it all
* remove non-existent example
* clone raylib.com before running rexm
* no extra slash
* Update examples collection
* copy updated examples to the right place
* remove unnecessary debug line from rexm.c
* Update examples collection
* Update examples collection
* use hardcoded absolute path to make
* add debug line
* semicolon
* fix wrong handling of make path
* fix wrong cwd
* rebuild raylib for web after installing it
* cleanuo
* conditionally push to repos, never on PR
* build rexm with make for consistency
* remove workflow run results
* add back the examples report files
* pause automatic commits
* revert makefile changes
* readd removed vs2022 project file
---------
Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>
Fixed bad references to shaders_normalmap in the project raylib\projects\VS2022\examples\shaders_normal_map.vcxproj
Changed GUID for shaders_normal_map as it coincided with that for core_3d_fps_controller {6B1A933E-71B8-4C1F-9E79-02D98830E671}
- Add ubuntu-24.04-arm runner for native ARM64 compilation
- Support building both static and shared libraries for ARM64
- Maintain backwards compatibility with existing x86/x64 builds
- Addresses issue #5051 for ARM64 pre-compiled binaries
Expected output: raylib-X.X-linux_arm64.tar.gz in releases
Added CMake support for SDL3.
Now supports including SDL2 or SDL3 as a subdirectory within the project. The system will first check for SDL3, then SDL2. If neither is found, it will attempt find_package(SDL3), followed by find_package(SDL2). If all these checks fail, the process will terminate with an error.
- make sure that src/external/rl_gputex.h uses it's own macros
for printing warnings and allocating memory
- add few additional macros in order to decouple rl_gputex from headers
that are being included by Raylib (e.g. *_MEMSET, *_NULL and so on)
- make sure that rl_gputex uses RL_*ALLOC, TRACELOG and RLAPI macros
when (and only when) being included by src/rtextures.c
- replace LOG() and RL_GPUTEX_SHOW_LOG_INFO macros with: RL_GPUTEX_WARN
and RL_GPUTEX_SHOW_WARN_INFO (this is a breaking change, but it was
broken and unusable anyway, see:
https://github.com/raysan5/raylib/issues/5039#issuecomment-3065732596 )
- fixes issue all issues mentioned in:
https://github.com/raysan5/raylib/issues/5039#issuecomment-3065732596
- remove logging upon successfully saving a file; Raylib does this
anyway and we want rl_gputex to only print WARNings upon failures;
see: https://discord.com/channels/426912293134270465/541710686468702250/1394406734306480352
- add additional condition when saving a file; now checks for both
fwrite() and fclose() failures; before it would warn about both,
but only return result based on fclose()
- add some notes about the current state of compiling rl_gputex
without depending on Raylib (spoiler: it's still broken...)
- bump rl_gputex version to 1.1 since this is a potential breaking
change (only for people attempting to use it without Raylib)
Fixes: https://github.com/raysan5/raylib/issues/5039
Reference: https://discord.com/channels/426912293134270465/541710686468702250/1394403611852931255
I did this with the intention of fixing
https://github.com/raysan5/raylib/issues/5027
but it's hard to tell if it will help in that case or not.
Anyway, bumping the header with mappings should be done once in a while.
I haven't found any Raylib script for doing this, so here's how I did it
step-by-step with CMake rule provided by GLFW (I'm on Linux, but this
should be similar on any other POSIX system):
```sh
$ git clone https://github.com/raysan5/raylib.git
$ cd raylib/src/external/glfw/
$ cmake -B ./build -DGLFW_BUILD_EXAMPLES=OFF -DGLFW_BUILD_TESTS=OFF -DGLFW_BUILD_DOCS=OFF -G "Unix Makefiles"
$ make -C ./build update_mappings
$ rm -fr ./build
```
then I checked, if any mappings were deleted (without updating) with
following shell one-liner:
```sh
# you must be at 'raylib/src/external/glfw/' when executing this
$ for i in $(git diff ./src/mappings.h | sed -n -e 's/^-"\([0-9a-z]*\),.*$/\1/p'); do grep <./src/mappings.h "$i" > /dev/null || echo "$i"; done;
```
which gave me the following IDs:
```txt
0300000066f700000500000000000000
030000000d0f00001600000000007803
03000000efbe0000edfe000000000000
03000000786901006e70000000000000
050000005e040000e002000030110000
03000000790000000600000010010000
030000000d0f00000d00000000010000
030000000d0f0000d800000072056800
03000000c0160000dc27000001010000
030000008916000000fd000024010000
```
I have checked all those IDs with `git log -p` against
https://github.com/mdqinc/SDL_GameControllerDB
and it seems that all of them were deleted by upstream (I was afraid that
maybe some mappings were added manually by a Raylib contributor and then
overwritten by my patch, but they weren't; All good!)
Fixes a regression since 5.5, where `ScanDirectoryFilesRecursively` no
longer does the "recursively" part due to `path` being `static`.
The issue was once already fixed in
5530a3ceb8
but recently made it back it in.
The original implementation created/destroyed framebuffers (FBs) per-frame, leading to kernel overhead and screen tearing. This commit replaces it with a different approach using:
- Asynchronous `drmModePageFlip()` with vblank sync
- Framebuffer caching to reduce repeated FB creation/removal operations
- Proper resource management through BO callbacks and buffer release synchronization
- Added error handling for busy displays, cache overflows, and flip failures
- Event-driven cleanup via page_flip_handler to prevent GPU/scanout conflicts
Co-authored-by: rob-bits
Examining the code shows that the rectangle is drawn winding counterclockwise, starting
with the top left. Therefore the colors used should be in the order: topLeft, bottomLeft,
bottomRight, topRight.
However, the variables actually being used are topLeft, bottomLeft, topRight,
bottomRight. I was confused by this as I was getting striping where I didn't expect any.
Put another way, the last two parameters are misnamed.
This diff swaps the parameter names and their usages. The result is that no runtime
behaviour changes: the same parameter order yields the same visual result both before and
after this change, but the parameter names now correctly reflect what they are actually
used for.
You can actually see this in the implementation of DrawRectangleGradientV, which
(correctly) passes top, bottom, bottom, top to DrawRectangleGradientEx.
build.zig doesn't support the examples for the emscripten OS but it does
support the raylib library. However, the examples panic if emscripten
is configured which prevents it from building the library. I've replaced
this panic with a fail step to fix this.
I believe it makes sense to only do this when there are no known
touch points. I am not even sure if this should be done at all.
See https://github.com/raysan5/raylib/issues/4872 for more information.
Previously, the libc paths file `android-libc.txt` was written to
the folder from which the user ran `zig build`. This caused
problems when using raylib as a dependency in other zig
projects, since raylib is not built in the project root, but the
`android-libc.txt` file was still generated in the project root. The file
should now be generated in .zig-cache, which should fix the isssue (and
leave the project root folder cleaner).
Added an Android target to the zig build script.
This allows a user to easily build with only Android-supported
libraries.
Library paths are automatically inferred as much as possible.
Restore window currently says it sets the window state to:
"not minimized/maximized"
However, if a window is maximized and then minimized, it's typical that
it would restore back to being maximized, which is what seems to happen
from my testing. I've reworded the description to better reflect
this behavior.
It looks like raylib doesn't require rglfw.c if you're using the RGFW
backend. I'm guessing the same is true for SDL but I haven't tested.
Excluding this one file brings the raylib library down from 6.9 MB to
6.3 MB for RGFW.
However, one of the examples requires the symbols from rglfw.c,
to accomodate this I added a function that will check whether raylib has
already included rglfw and if not include it for that one example.
The core_window_flags example automatically restores the window from
being minimized after 3 seconds. However, it only resets the frameCounter
if the window is minimized through the app from inputting KEY_N. This
means if you miminize the window by other means (like pressing the minimize
button) then the example will immediately restore the window because the
frame counter wasn't reset. I've fixed this by setting the frameCounter
back to 0 once it's expired. I also added a note in the UI that the example
automatically restores the window so it's not a surprise.
I think this line was accidently commented out in this commit:
3d1ae3500c731aa37d8f887cd165db480c4890eb
The FPS limit is needed to get the desired wait time for the "hide window"
test, which uses the frame counter to hide the window for 3 seconds. On
my machine without this limit it runs at over 1000 FPS and it appears
like the hide window state is broken.
I also added some text that tells the user that it only hides the window
for 3 seconds so they're not surprised when the window automatically
reappears.
raylib app crashing when started and a gamepad is already connected to the PC (even if the gamepad is not used in the app). I only tested this with a gamepad that has a layout which is not recognized. Using SDL3 as backend.
Removes the second build.zig in the examples directory and incorporates it
into the main build.zig. This gives the zig build system the data needed to
know if the raylib library needs to be rebuilt when running any example.
InitWindow() prints CWD during initialization,
but ChangeDirectory() does not, which is quite confusing when you start
messing with CWD. Now said function should log similar message.
Prevents unnecessary work and division by zero (when segments=0) in DrawCircleSector/DrawCircleSectorLines when startAngle equals endAngle, matching existing behavior in DrawRing/DrawRingLines.
This may not be the correct approach, however this appears to work. The idea is that before modifying `CORE.Window.flags` when first creating the window we keep a copy of the flags in order to call `SetWindowState` after initialization has completed, which should behave as if `MaximizeWindow` or `MinimizeWindow`, or conceptually any other flag modifying function were called after `InitWindow`.
This pull request only performs this for the windows platform, modify as needed in the switch statement at the end for others.
Undefine DEBUG to avoid external redefinition
warnings/conflicts. This is probably a common
definition for many external build systems'
debug configurations.
This ensures raylib will not emit
a warning about the DEBUG definition being
redefined in external build systems.
...so it will always prioritize local version of raylib instead of
system-wide installations, which is a huge problem when testing any
changes done locally to raylib as it might cause silent mismatch issues.
There were only 4 examples affected by this issue which were using
`#include <raylib.h>`. Other examples use proper `#include "raylib.h"`
Fixes: https://github.com/raysan5/raylib/issues/4820
* [rcore] fix crash in InitWindow, due to unchecked result of InitPlatform
Check the result of InitPlatform(), if it isn't 0, report the Error
and return. This prevent crashes and allows for gracefully aborting
or recovering by checking IsWindowReady().
Partially-fixes: https://github.com/raysan5/raylib/issues/4801
* [rcore] style: store the result of InitPlatform() before checking it
Small style change that doesn't impact how the code behaves here.
Variable 'result' is not used anywhere else in this block,
it's just for compliance with Raylib's coding conventions.
Requested in PR: https://github.com/raysan5/raylib/pull/4803#discussion_r1976502788
* [rcore] use LOG_WARNING when InitPlatform() fails
...as this is preferred over LOG_ERROR.
Requested-by: https://github.com/raysan5/raylib/pull/4803#discussion_r1976651724
In the case of a failure within miniaudio on the function: ma_convert_frames, the dynamic memory allocated for the `data` variable will leak on the early return.
Raylib allows for providing custom allocators via macros.
GLFW supports this too, but via function pointers.
Make sure that GLFW uses those Raylib macros, by wrapping them in
function calls and setting them up inside of InitPlatform().
This is possible because of glfwInitAllocator() and GLFWallocator.
Fixes: https://github.com/raysan5/raylib/issues/4776
Relates-to: https://github.com/raysan5/raylib/issues/4751
I was really wondering what is going on here :D I believe this code
tried initially to out-cast 'const' specifier but this is not needed here
at all. Currently, it just confuses whoever reads this so I changed it.
The old code would also trigger -Wcast-qual warning on some compilers.
Currently, a warning about _GNU_SOURCE being redefined is emitted when
compiling rglfw.c
In file included from rglfw.c:99:
external/glfw/src/posix_poll.c:27:9: warning: "_GNU_SOURCE" redefined
27 | #define _GNU_SOURCE
| ^~~~~~~~~~~
<command-line>: note: this is the location of the previous definition
This can be avoided by not defining _GNU_SOURCE on the command line for
this file.
Defining feature test macros in source code is not really good practice
so this should probably reviewed in glfw itself, at least to maybe check
#ifdef _GNU_SOURCE first. But for now this change will suffice.
Fixes#4725
When asking Makefile to create SHARED library for WEB
$ make TARGET_PLATFORM=PLATFORM_WEB RAYLIB_LIBTYPE=SHARED
it would instead silently create STATIC library
thus not fulfilling the request as expected
This commit adds an error in this case and stops further execution.
This is not consistent with Cmake, because Cmake throws the warning and
does not stop, but Cmake can easily recover from this case and people
probably does not even notice it. However, Makefile is something that
you have to handle yourself and you have to recover from any issues so
having an error and aborting with exit code 1 is more expected.
Otherwise people may spend a lot of time debugging Makefile in order to
understand what's even going on.
Fixes: https://github.com/raysan5/raylib/issues/4717
define STBIR_NO_SIMD when __TINYC__ is defined so stb_image_resize2 will
not include *mmintrin which are not supported by all compilers.
There are similar checks for __TINYC__ already elswere in raylib
and they are also mostly there to disable SIMD headers.
Additionally, move similar check for stb_image, to be a little bit
deeper. Before it was defining STBI_NO_SIMD without including stb_image
It was also clashing with note, causing said note to make no sense.
Fixes: https://github.com/raysan5/raylib/discussions/2994
Reference: https://github.com/nothings/stb/issues/1738
* Update examples inconsistencies
* Happy new years, examples!
* Missed one inconsistency
* Update final few examples inconsistencies
---------
Co-authored-by: Anstro Pleuton <anstropleuton@github.com>
This change is replacing the hardcoded "#canvas" element references in
rcore_web to allow using canvas elements that use different names
(which is necessary when using multiple canvas elements on one page).
Also adding a cursor hiding example to mouse example.
The bindings from @EmmaTheMartian were moved to official status, so the link is updated.
The name was normalized to be consistent with other 'vendored' names in other languages.
Lately got some compilation `errors` related, it seems GCC 14 interprets some `const`-missmatch as errors instead of warnings (as previous versions).
But in any case, I don't see why an user won't be able to operate directly over of those returned buffers; `const` adds a restriction (for security reasons?) that in my opinion is useless.
From an expert on compilers (w64devkit creator), here there are some notes I agree with:
```
No const. It serves no practical role in optimization, and I cannot recall an instance where it caught, or would have caught, a mistake. I held out for awhile as prototype documentation, but on reflection I found that good parameter names were sufficient. Dropping const has made me noticeably more productive by reducing cognitive load and eliminating visual clutter. I now believe its inclusion in C was a costly mistake.
(One small exception: I still like it as a hint to place static tables in read-only memory closer to the code. I’ll cast away the const if needed. This is only of minor importance.)
```
Ref: https://nullprogram.com/blog/2023/10/08/
This optimization works in the following ways:
1. Reduces calls to malloc to 1. Instead of needing an extra array, we
can just swap the top half with the bottom half of the one array.
2. Unroll the inner for loop and remove a condition. Unrolling loops
buys some performance wins, but the real goal was to remove the if check
and just set the alpha channel to 255.
On my hidpi arm64 laptop, I saw ~60% improvement in performance in my
debug build (29 FPS vs 47 FPS). When optimized, the gains were roughly
10% (75 FPS vs 83%).
Signed-off-by: K. Adam Christensen <pope@shifteleven.com>
* Add implementation for CORE.Window.eventWaiting on PLATFORM_DESKTOP_SDL
* Optimize GetFrameTime() reset
* Optimize FLAG_WINDOW_ALWAYS_RUN and GetFrameTime() reset for PLATFORM_DESKTOP_GLFW
* Enable FLAG_WINDOW_ALWAYS_RUN by default on PLATFORM_DESKTOP_GLFW
* Revert enabling FLAG_WINDOW_ALWAYS_RUN by default on PLATFORM_DESKTOP_GLFW
* Add implementation for FLAG_WINDOW_ALWAYS_RUN on PLATFORM_DESKTOP_SDL
* Add reset for GetFrameTime()
* Update rmodels.c
resolves segfault with missing bone weights or bone IDs
* Update rmodels.c segfault with animation and missing normals/animnormals
* correct place.
This fixes an incomplete framebuffer issue due to the use of a texture format not supported in ES 3.
This commit also adds more information on how to manage deferred rendering.
- Updating bones only once instead for each mesh.
- Updating only one `model.meshes[].boneMatrices` and then using deep copy for other meshes instead of calculating for each bone in each mesh.
**Other points:**
- Makes it a clean base/template/reference for bone updation functions. Because if using this as template then some calculations done in one mesh can affect bones in other mesh in next iteration(doubles the effect in for next mesh).
Signed-off-by: Kirandeep-Singh-Khehra <kirandeepsinghkhehra@gmail.com>
* updated raylib-lua version
* Updated some bindings
* removed 404 bindings
* adding my bindings project to the list
* Adding a related project
* fixing the license foi ReiLua
* Make sure ShaderUniformDataType matches rlShaderUniformDataType
* Update raylib_api.* by CI
---------
Co-authored-by: github-actions[bot] <github-actions[bot]@users.noreply.github.com>
Co-authored-by: Ray <raysan5@gmail.com>
* basic pbr example
pbr implementation includes rpbr.h and few shader files header only file, which self contain everything needed for pbr rendering. Few textures and one model of the car which is under free licence which is included inside basic_pbr.c example file currently supported shader versions are 120 and 330 , version 100 has small issue which I have to resolve
* Unloading PBRMAterial
I forgot unloading PBRMaterial
* fix small issue with texOffset assigment.
value was Vector4 at first but I found out it would be unclear for and users, so I change to have two Vector2 instead, but forgot to assign offset .
* Changed size of textures and file name changed
Changed size of textures from 2048x2048 to 1024x1024 and file name changed to shaders_basic_pbr.c ,
Added the function PBRModel PBRModelLoadFromMesh(Mesh mesh);
but GenMeshPlane(2, 2.0, 3, 3) culdn't be used because it crash once GenMeshTangents() is used with that plane mesh
* Update to 5.5 version of eexample and fix to work in web
set GLSL_VERSION 100
set precision highp float;
removed in keyword
fix for loop has to use only constant
* Update shader_basic_pbr example to work on web
changed to GLSL_VERSION 100
update glsl100 shader
set float precision to highp
removed keyword in
change for loop tu use constant value gives an error
* Update shader_basic_pbr example to work on web
changed to GLSL_VERSION 100
update glsl100 shader
set float precision to highp
removed keyword in
change for loop tu use constant value gives an error
* removed rpbr.h
removed rpbr.h
* Bindings for c3-lang raylib 5.5 and raylib 5.0
I've created raylib 5.5 binding for c3-Lang https://c3-lang.org
* Improve cmake config file generation
This allows for finding raylib on a non-standard location (eg, not in /usr/lib{,64})
* Only have glfw as private if using internal glfw and not static
* basic pbr example
pbr implementation includes rpbr.h and few shader files header only file, which self contain everything needed for pbr rendering. Few textures and one model of the car which is under free licence which is included inside basic_pbr.c example file currently supported shader versions are 120 and 330 , version 100 has small issue which I have to resolve
* Unloading PBRMAterial
I forgot unloading PBRMaterial
* fix small issue with texOffset assigment.
value was Vector4 at first but I found out it would be unclear for and users, so I change to have two Vector2 instead, but forgot to assign offset .
* Changed size of textures and file name changed
Changed size of textures from 2048x2048 to 1024x1024 and file name changed to shaders_basic_pbr.c ,
Added the function PBRModel PBRModelLoadFromMesh(Mesh mesh);
but GenMeshPlane(2, 2.0, 3, 3) culdn't be used because it crash once GenMeshTangents() is used with that plane mesh
* Update to 5.5 version of eexample and fix to work in web
set GLSL_VERSION 100
set precision highp float;
removed in keyword
fix for loop has to use only constant
* Update shader_basic_pbr example to work on web
changed to GLSL_VERSION 100
update glsl100 shader
set float precision to highp
removed keyword in
change for loop tu use constant value gives an error
* Update shader_basic_pbr example to work on web
changed to GLSL_VERSION 100
update glsl100 shader
set float precision to highp
removed keyword in
change for loop tu use constant value gives an error
* removed rpbr.h
removed rpbr.h
* increased vertex data precision to match blender exports
* modified memory allocation to better fit higher precision data
* now accounting for newline characters during allocation
* now accounting for potentially higher vertex counts
* removed unnecessary final newline
Changed line 118 from, "// For advance camera controls, it's reecommended to compute camera movement manually", to, "// For advanced camera controls, it's recommended to compute camera movement manually".
The nextShapeEnd integer is a pointer in the OBJ data structures.
The faceVertIndex is a vertex index counter for the mesh we are
about to create. Both integers are not compatible, which causes
the code to finish the meshes too early, thus writing the OBJ data
incompletely into the target meshes.
It wasn't noticed because for the last mesh, it process all remaining
data, causing the last mesh to contain all remaining triangles.
This would have been noticed if the OBJ meshes used different textures
for each mesh.
- addRaylib just duplicates what adding raylib as dependency already does
so it do not needs to exist
- move raygui build to standard build process when flag is enabled. this
works correctly when using raylib as dependency and having raygui as
dependency as well. problem with previous approach was that raygui was in
options but it was doing nothing because you had to also use addRaygui for
it to be effective
Signed-off-by: Tomas Slusny <slusnucky@gmail.com>
* [rcore] add 'GetClipboardImage' for windows
* [rcore] GetClipboardImage removed some unneeded defines
* [rcore] PLATFORM_SDL: create a compatility layer for SDL3
* external: add win32_clipboard.h header only lib
* [rcore] using win32_clipboard on platforms rlfw and rgfw
* [rcore] fix warnings in SDL3 compatibility layer
* Makefile: Allow specifying SDL_LIBRARIES to link, this helps with SDL3
* Makefile: examples makefile now compile others/rlgl_standalone only when TARGET_PLATFORM is PLATFORM_DESKTOP_GFLW
* Makefile: examples makefile now compile others/rlgl_standalone only when TARGET_PLATFORM is PLATFORM_DESKTOP_GFLW
* [rcore]: PLATFORM_SDL: improve clipboard data retrieval
* external: remove unused function from win32_clipboard.h
* Makefile: allow for extra flags necessary when compiling for SDL3
* [rcore]: fix string typo
* [rcore]: Properly handle NULL dpi passing. As is allowed in SDL2
* external: fix arch finding on win32_clipboard.h to allow compilation on msvc cmake CI
* [rcore]: PLATFORM_SDL: Treat monitor as an ID in SDL3 as opposed to an index as in SDL2
* [rcore]: typo
When creating a new sphere mesh with high number of slices/rings the top and bottom parts of the generated sphere are removed. This happens because the triangles in those parts, due to high resolution, end up being very small and are removed as part of the 'par_shapes' library's optimization. Adding par_shapes_set_epsilon_degenerate_sphere(0.0); before generating the sphere mesh sets the threshold for removal of small triangles is removed and the sphere is returned to raylib correctly.
* Remove the panorama cubemap layout, it was not implemented.
Left a todo in the code for some aspiring developer to finish.
* Update raylib_api.* by CI
---------
Co-authored-by: github-actions[bot] <github-actions[bot]@users.noreply.github.com>
* Update raylib_api.* by CI
* Add math operators for C++ to raymath
* better #define for disabling C++ operators
---------
Co-authored-by: github-actions[bot] <github-actions[bot]@users.noreply.github.com>
* Updates SetWindowState() and ClearWindowState() to handle FLAG_WINDOW_MAXIMIZED for PLATFORM_WEB
* Update MaximizeWindow() and RestoreWindow() to set/unset the FLAG_WINDOW_MAXIMIZED
Updated the VSCode Makefile to allow compilation of multiple .c files instead of just one (main.c).
- Replaced `SRC` and `OBJS` definitions to dynamically include all .c and .h files in the project.
- This change enables automatic handling of any number of source files specifically in the VSCode setup.
* (rcore_desktop_rgfw.c) fix errors when compiling with mingw
* define WideCharToMultiByte
* update RGFW
* move stdcall def to windows only
* fix raw cursor input
* Make the max VBO match the animation flag.
* re-enable GPU skinning for mac, and fix the max buffer to be correct based on the GPU skinning support flag.
* Update raylib_api.* by CI
* Disable GPU skinning on MacOS
Add GPU skinning example to MSVC Projects.
* Update raylib_api.* by CI
---------
Co-authored-by: github-actions[bot] <github-actions[bot]@users.noreply.github.com>
* Update raylib_api.* by CI
* Add comment that draw pixel uses geometry and may be slow
* Update raylib_api.* by CI
---------
Co-authored-by: github-actions[bot] <github-actions[bot]@users.noreply.github.com>
* Update CMakeLists.txt
Add missing link flags
* Update README.md
Remove unneeded flag because this flag is defined in the updated CMakeList file
* Update CMakeLists.txt
* Added optional GPU skinning
* Added skinned bone matrices support for different file formats.
* Moved new shader locations to end of enum to avoid breaking existing examples. Added gpu skinning on drawing of instanced meshes.
* Added GPU skinning example.
* Removed variable declaration to avoid shadowing warning.
* [BINDINGS.md] Added raylib-bqn, moved rayed-bqn
rayed-bqn has had a lot of progress and I've realized it has diverged too much from raylib, and so I made raylib-bqn to be a simple binding, while rayed-bqn will be a utility wrapper.
* removed accidental newline
* Add filtering folders in ScanDirectoryFiles and ScanDirectoryFilesRecursively
Add define FILTER_FOLDER for that purpose
Fix folder names matching filter being added to result
* Move FILTER_FOLDER define to internals of rcore and document option in comment
* added MixColors function to mix 2 colors together (Line 1428 raylib.h and Line 4995 in rtextures.c)
* renamed MixColors to ColorLerp (https://github.com/raysan5/raylib/pull/4310#issuecomment-2340121038)
* changed ColorLerp to be more like other functions
---------
Co-authored-by: CI <-ci@not-real.com>
* align /usr/local with src Makefile
Align /usr/local with the /src Makefile, where it can be overriden.
* /usr/local: allow override
align /usr/local with the /src Makefile, where it can be overriden
* WindowPosCallback added.
CORE.Window.position is now properly kept in sync with the glfw window position.
* Update rcore_desktop_glfw.c
Comments updated.
* Setting CORE.Window.position correctly in InitPlatform() as well.
This also fixes not centering the window correctly when the high dpi flag was enabled.
* Fixes centering the window in the SetWindowMonitor() function.
Here the render size has to be used again in case the high dpi flag is enabled.
* Update Window Position
Update Window Position right away in ToggleFullscreen() & ToggleBorderlessWindowed() functions
* Update raylib_api.* by CI
* update fullscreen and borderless comments to better describe what they do.
* Update raylib_api.* by CI
---------
Co-authored-by: github-actions[bot] <github-actions[bot]@users.noreply.github.com>
* Added the ability to draw a model as a point cloud
* Added example to demonstrate drawing a model as a point cloud
* polished the demo a bit
* picture for example
* adhere to conventions for example
* update png to match aspect ratio
* minor changes
* address code convention comments
* added point rendering to makefiles
* added point rendering to readme and renumbered examples
* comment formatting
---------
Co-authored-by: Reese Gallagher <re325479@ucf.edu.com>
Co-authored-by: Ray <raysan5@gmail.com>
Currently, when building, the cmake example in projects/CMake gives this
warning, with CMake 3.30.2
CMake Warning (dev) at /usr/share/cmake/Modules/FetchContent.cmake:1953 (message):
Calling FetchContent_Populate(raylib) is deprecated, call
FetchContent_MakeAvailable(raylib) instead. Policy CMP0169 can be set to
OLD to allow FetchContent_Populate(raylib) to be called directly for now,
but the ability to call it with declared details will be removed completely
in a future version.
Call Stack (most recent call first):
CMakeLists.txt:20 (FetchContent_Populate)
This warning is for project developers. Use -Wno-dev to suppress it.
Changing FetchContent_Populate to FetchContent_MakeAvailable didn't
cause any issues I could observe when building. I'm not sure why it
wasn't like that to begin with.
This file seems to not do anything useful. From what I can tell the
OSX_FATLIB option sets CMAKE_OSX_ARCHITECTURES to "x86_64;i386". This
doesn't account for the arm that apple now has, as well as 32 bit
support being completely removed, and I think it's entirely reasonable
to expect users to pass the necessary architectures they want
themselves. It's possible this could break some users who rely on this,
but I sincerely doubt anyone does. The solution is trivial either way
(put -DCMAKE_OSX_ARCHITECTURES="i386;x86_64" on the command line
yourself)
The second part of BuildOptions.cmake claims to set PLATFORM to "Web" if
the emscripten toolchain file is used (if (EMSCRIPTEN)), but it does not
work correctly anyway. Currently, glfw searches for wayland and x11
libraries and fails likeso:
CMake Error at /usr/share/cmake/Modules/FindPkgConfig.cmake:645 (message):
The following required packages were not found:
- wayland-client>=0.2.7
- wayland-cursor>=0.2.7
- wayland-egl>=0.2.7
- xkbcommon>=0.5.0
Call Stack (most recent call first):
/usr/share/cmake/Modules/FindPkgConfig.cmake:873 (_pkg_check_modules_internal)
src/external/glfw/src/CMakeLists.txt:163 (pkg_check_modules)
Considering this code doesn't work as described, it's okay to delete it.
I think a better check should be implemented, but that is for a
different PR.
* Update raylib_api.* by CI
* Add a temp warning about material assignments during OBJ loading if the file has more than one material. To be replaced when the OBJ translation code is fixed.
---------
Co-authored-by: github-actions[bot] <github-actions[bot]@users.noreply.github.com>
void DrawCircleGradient(int centerX, int centerY, float radius, Color color1, Color color2);
void DrawRectangleGradientV(int posX, int posY, int width, int height, Color color1, Color color2);
void DrawRectangleGradientH(int posX, int posY, int width, int height, Color color1, Color color2);
void DrawRectangleGradientEx(Rectangle rec, Color col1, Color col2, Color col3, Color col4);
Have been changed to:
void DrawCircleGradient(int centerX, int centerY, float radius, Color inner, Color outer);
void DrawRectangleGradientV(int posX, int posY, int width, int height, Color top, Color bottom);
void DrawRectangleGradientH(int posX, int posY, int width, int height, Color left, Color right);
void DrawRectangleGradientEx(Rectangle rec, Color topLeft, Color bottomLeft, Color topRight, Color bottomRight);
* Create raymarching.fs
* Update raymarching.fs
* Update raymarching.fs
* Update raymarching.fs
Remove `fragColor` as it is unused
Move the license to the top of the code to improve readability.
* [build.zig] Overridable definitions from config.h
The new Options field "config" holds a string the user can set in the
format "-Dflag_a=1 -Dflag_b=0 ..." to override the values set in
`config.h`.
The file is parsed and the default values are appended to the
compilation flags, if the user doesn't override them.
The user string is appended to the compilation flags.
The "-DEXTERNAL_CONFIG_FLAGS" is added to prevent "config.h" inclusion.
Note: a certain format is assumed for the formatting of config.h
Note: this commit references the closed issue #3516
* [build.zig] Only SUPPORT_* definitions are overridable
Lines from `config.h` which contains "SUPPORT" are added to compilation after being parsed:
- remove whitespace
- format to preprocessor option https://gcc.gnu.org/onlinedocs/gcc/Preprocessor-Options.html
The user supplied flags have priority over the ones read from the file.
NOTE: extension to commit 4da7f82e6f912485351167da3bbc91807371fdee, the logic is simplified
because the SUPPORT flags only have binary values, which makes them easier to parse.
* GLFW AUTO_ICONIFY flag is now set to false per default.
Previously AUTO_ICONIFY was only disabled if the user requested a Fullscreen window from the start. After that it was not possible to change this behavior on the user side anymore, even when changing to a Fullscreen window.
The AUTO_ICONIFY causes problems on macOS. On macOS if the window is minimized because of AUTO_ICONIFY than the only way to restore it is to click on the icon in the dock. In other words when AUTO_ICONIFY is enabled alt/cmd-tabbing through windows does not work correctly. On windows it works even when AUTO_ICONIFY is enabled.
Additionally if a raylib window is in Fullscreen mode on another monitor the AUTO_ICONIFY behavior is a problem because the user might want to window to stay on the monitor even if it loses focus. (problem on all OS's)
AUTO_ICONIFY also restores the monitor hardware resolution if a fullscreen window loses focus.
* Update rcore_desktop_glfw.c
Extra space removed and comments updated with a space at the beginning
* [rcore] fix gamepad axis movement and its automation event recording
This commit fixes 2 issues:
- Automation events aren't recorded for negative axis movements on
gamepads (e.g. stick going left/up)
- 'GetGamepadAxisMovement' drift check isn't working correctly for
triggers. Axis values between [-0.1, 0.1] are clamped to 0.0
Behaviour change:
- 'GetGamepadAxisMovement' returns default value for each axis, even
if gamepad isn't attached.
* [rcore] inline body of 'GetGamepadAxisMovementDefault' and remove it
* Adds log warnings on invalid file data
* Separate error on missing file extension
* Changed LOG_ERROR to LOG_WARNING
---------
Co-authored-by: Jutastre <pukarlindgren@gmail.com>
* Zig Both Linux Desktop Platform Support
* Formating and Default Fix
Made formating fit within raylib standards and changed the default option to support both X11 and wayland on Linux.
* caught one hiding tab
* Update raylib_api.* by CI
* No need to call the color 4 times in a row, it's batched
---------
Co-authored-by: github-actions[bot] <github-actions[bot]@users.noreply.github.com>
If `FLAG_WINDOW_HIGHDPI` is set, `InitPlatform()` will aks GLFW to handle resize window content area based on the monitor content scale using : ` glfwWindowHint(GLFW_SCALE_TO_MONITOR, GLFW_TRUE); `
So `WindowSizeCallback()` does not have to handle it a second time.
* Update raylib_api.* by CI
* Fix MSVC warnings.
Make raymath.h work in C++ in MSVC
* whitespace cleanup
---------
Co-authored-by: github-actions[bot] <github-actions[bot]@users.noreply.github.com>
This could potentially be a breaking change, for consistency, now every possible desktop backend has the proper name assigned: GLFW, SDL, RGFW
raylib build system has been reviewed to fallback to `PLATFORM_DESKTOP_GLFW` by default when `PLATFORM_DESKTOP` defined
* Optimize DrawSphereEx()
Precalculates sin/cos to eliminate unnecessary calls.
* Formatting correction to previous commit
* Bugfix to optimized DrawSphereEx()
OBO error -- added 1 additional precalculated cos/sin value to each array to complete the 360-degree wraparound. Technically the value of these last elements will always be the same as the first element due to 360-degree wraparound, but this is the simplest solution.
* Corrected missing free()
* Formatting correction
* New DrawSphereEx() algorithm
* created ImageFromChannel
Adds the possibility to extract a specific channel from an image
* naming convention
* example window height
* removed threshold
* removed alpha channel
* channel example organization
* updated channel example image
* Update raylib_api.* by CI
* Default to not use HDR, and note that HDR support requires that raylib be built with HDR enabled.
---------
Co-authored-by: github-actions[bot] <github-actions[bot]@users.noreply.github.com>
* rmodels.c, LoadImageFromCgltfImage() : fix base64 padding support
This should fix the issue related to `.gltf` embeded image in base64 format, by ignoring `=` padding and calculating the data size in bytes correctly.
* follow guidelin convention
* try to follow guideline convention as much as possible
* clarify comments
i hope it's clear ennough
* Fix Makefile issues (RGFW) (linux) (macOS)
* Do not use nanosleep on windows at all (PLATFORM_DESKTOP_RGFW)
* remove #define RGFWDEF and make the #undefs only happen for their OS
* Update RGFW.h
* fix to match the RGFW updates
* remove line that shows the cursor for no reason
* Update RGFW, replace long switch with an array, update rgfw platform for RGFW
* update RGFW (fix reported glitch with drag and drop files) (linux)
* remove u16
`@This()` was naively passed to `dependencyFromBuildZig` while inside
a file that is not actually the build file, causing a panic when
actually used. Passing `@import("../build.zig")` fixes this.
It is currently impossible to check a font loaded successfully with
IsFontReady because LoadFontEx will always return a valid font.
DrawTextEx has this check:
if (font.texture.id == 0) font = GetFontDefault(); // Security check in case of not valid font
So anyone relying on the default font as a fallback for fonts failing to
load should still be covered.
* Update raylib_api.* by CI
* Fix warnings when building examples in MSVC 2022
* fix auto-format that sneaked in there.
---------
Co-authored-by: github-actions[bot] <github-actions[bot]@users.noreply.github.com>
* Initial work to correctly handle the node hierarchy in a glTF file.
Static meshes seem to work fine in my tests. Haven't tried anything
animated yet, but it's almost certainly broken.
* Fix variable naming, some comment tweaks
* Only count primitives made up of triangles in glTF meshes
* Update processing of gltf mesh animation data, to match earlier
changes to vertex/normal/tangent data
* Create ParseConfigHeader.cmake
This script parses the config.h file to automate the process of exposing the configuration flags and configuration values found in the latter.
* Update CompileDefinitions.cmake
Makes use of the new functionality found in ParseConfigHeader.cmake to make things consistent.
* Update CMakeOptions.txt
Makes use of the new functionality found in ParseConfigHeader.cmake to make things consistent.
* Update CMakeLists.txt
Changes required to make possible building raylib for web on Windows 10.
* Update LibraryConfigurations.cmake
Removes a warning that linker-only flags were being passed to the compiler, which is in accordance to https://emscripten.org/docs/tools_reference/settings_reference.html.
* Update CMakeOptions.txt
Removed clutter.
* Update CompileDefinitions.cmake
Removed clutter.
* Update CompileDefinitions.cmake
Some applications might check for PLATFORM_WEB instead of __EMSCRIPTEN__.
* Update CompileDefinitions.cmake
Reverting
* Update CMakeLists.txt
USE_AUDIO is redundant in the presence of the already existent and more descriptive SUPPORT_MODULE_RAUDIO.
* Update CompileDefinitions.cmake
USE_AUDIO is redundant in the presence of the already existent and more descriptive SUPPORT_MODULE_RAUDIO.
* Update ParseConfigHeader.cmake
* Revert "Update CMakeLists.txt"
This reverts commit 1785fc06b5b89e65515cea3afd3e3c095f15e350.
* Revert "Update CompileDefinitions.cmake"
This reverts commit 62f9a3a0ea21af7bd0a1ab74d10a305fca2a5695.
* Revert "Update CMakeLists.txt"
This reverts commit 3e7912144edc5c69c53ed5a9515ae21d66937963.
* Revert "Update LibraryConfigurations.cmake"
This reverts commit bcc4310c4960c200c340671caa298983340ea386.
* [rshapes] Fix multisegment Bezier splines.
It seems to me that these functions are wrong, if you step the index by 1 you move to a control point instead of the next segment.
* Fix example shapes/shapes_splines_drawing for bezier splines.
* Draw circles to fill gaps between bezier segments.
When addRaygui is used from an external build, for example in a
bindings project, the build of a generated `raygui.c` fails with
"raylib.h not found" error from the compiler.
I've traced this down to a raylib step not adding its `src/` to the
shared list of include paths using `addIncludePath` but relying on
`addCSourceFiles` `.root` to provide the implicit include path for
raylib proper's own files.
If raygui is later added to the step the compiler won't know where
to look for `raylib.h` and friends and will fail to build.
This change simply adds raylib's `src/` to the include path list.
- The function rlGetMatrixProjectionStereo and rlGetMatrixViewOffsetStereo have RLAPI for the function declaration and cause error when compiling using RLGL_IMPLEMENTATION.
fragPosition was multiplied by mvp*instanceTransform, but it should only be multiplied by instanceTransform. Compare to lighting.vs, there we only use mvp for gl_Position, but matModel for the fragPosition.
* Update raylib_api.* by CI
* make functions that take a pointer to an array take them as const pointers
* Update raylib_api.* by CI
* fix comment alignment.
---------
Co-authored-by: github-actions[bot] <github-actions[bot]@users.noreply.github.com>
Since the flag CUSTOM_CFLAGS should allow users customize things, in particular the optimization level, I figured it should come after other default ones.
Based on: "If you use multiple -O options, with or without level numbers, the last such option is the one that is effective."
Source: https://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html
* Fix Makefile issues (RGFW) (linux) (macOS)
* Do not use nanosleep on windows at all (PLATFORM_DESKTOP_RGFW)
* remove #define RGFWDEF and make the #undefs only happen for their OS
* Update RGFW.h
* fix to match the RGFW updates
* remove line that shows the cursor for no reason
* Fix#4024, cylinder drawing was incorrect due to imprecise angle
stepping (mostly noticeable with semi-transparent cylinders)
* Fix var name and spacing
* rtext: added functions for camel case and snake case
* Update raylib_api.* by CI
* rtext: removed always false comparison
---------
Co-authored-by: github-actions[bot] <github-actions[bot]@users.noreply.github.com>
* Fix for issue #4010
Split the code for Zig's master branch and >= 0.12.0 due to changes in https://github.com/ziglang/zig/pull/19623
* Restore the cache_include path which was removed in error
Accidently removed a couple lines I didn't mean to 🙈
In future, if a dev edits the second arg and miscalulates the corresponding 3rd arg, there will be a buffer overflow or the string (2nd arg) will be cut short. This commit prevents that.
* Update raylib_api.* by CI
* Remove Extern C for raymath, it breaks some cases in mingw-w64 and does not fix any warning issues.
---------
Co-authored-by: github-actions[bot] <github-actions[bot]@users.noreply.github.com>
The parser assumes all lines end in newlines, but sometimes this isn't
true. Check for a null terminator along with '\n' when stripping leading
spaces.
* Update raylib_api.* by CI
* Add an extern C to raymath to prevent warnings in C++
---------
Co-authored-by: github-actions[bot] <github-actions[bot]@users.noreply.github.com>
* Fix Makefile issues (RGFW) (linux) (macOS)
* Do not use nanosleep on windows at all (PLATFORM_DESKTOP_RGFW)
* remove #define RGFWDEF and make the #undefs only happen for their OS
* Fix Makefile issues (RGFW) (linux) (macOS)
* Do not use nanosleep on windows at all (PLATFORM_DESKTOP_RGFW)
---------
Co-authored-by: ColleagueRiley <ColleagueRiley@gmail.com>
* fix minor bugs and errors (x86) for the RGFW platform, update RGFW platform license, update makefile info for RGFW platform
* revert
* (RGFW) (winapi) fix mouse hide bug when cursor changes
* ensure PLATFORM_SHELL is defined (PLATFORM_RGFW)
---------
Co-authored-by: ColleagueRiley <ColleagueRiley@gmail.com>
* Implementing GetMonitorWidth/Height and GetMonitorPhysicalWidth/Height for drm
Added implementation for DRM for functions :
- GetMonitorWidth()
- GetMonitorHeight()
- GetMonitorPhysicalWidth()
- GetMonitorPhysicalHeight()
- GetMonnitorName()
These functions take an argument but only the value 0 is accepted. This is because the DRM platform implementation manages only one screen for now
* Refactor "GetMonitor" properties for DRM Platform
Refactored GetMonitorHeight, GetMonitorWidth, GetMonitorPhysicalHeight,
GetMonitorPhysicalWidth and GetMonitorName to accept only argument "0"
as more than one screen is not supported in DRM platform.
* Rework window placement and dimensions for multi-monitor setups;
- fullscreen apps use primary monitor, exclusively
- non-fullscreen apps come in two variants:
a) pre-determined window size by user
b) use-active-monitor dimensions by user specifying 0x0
Either way, the window shall be centred at the monitor where it was created
This may have been the original intent, yet the primary monitor was used also for the second case, regardless where the window opened.
* Clean up code, handle error, fix integer-overflow for centering windowed fullscreen
They need to be exposed on `rlgl.h` header section (not implementation section) because with some specific use cases (custom config.h, rmodels module enabled), building fails otherwise.
The `RL_CULL_DISTANCE_` definition remains as the initial value
of the variables.
Basic usage can be:
```c
#include <raylib.h>
#include <rlgl.h>
rlSetClipPlanes(RL_CULL_DISTANCE_NEAR, MY_CULL_DISTANCE_FAR);
if (must_reset_clip_planes)
rlSetClipPlanes(RL_CULL_DISTANCE_NEAR, RL_CULL_DISTANCE_FAR);
```
* Fix several non-functional `target_compile_definitions`
* Avoid hardcoding the default vertex attribute locations
* Implement functional `rlNormal3f`
* Add normal definitions for `DrawCube`
* Update the basic lighting example to use `DrawCube` and `DrawPlane`
* Remove support for 0.11.0, and make build script more idiomatic
+ remove all 0.11.0 compatibility functions
+ remove most LazyPath .path variants
+ I didn't touch emscripten, I don't know if its relative or absolute
+ change all absolute paths to use .cwd_relative
+ only use the builder allocator
+ have local dependencies use the package manager
+ make adding raygui more flexible
+ use zig-cache for generated wayland files
* Remove support for 0.11.0 in examples/build.zig
* update examples further and add clarifying comment on addRaygui
* Flip release of buffer;
First it needs to be taken out of the processing chain, then it can be released. The inverse of the initialization.
* Add mutex locks to audio buffer functions; Separate those used from both threads
* Flip release of buffer;
First it needs to be taken out of the processing chain, then it can be released. The inverse of the initialization.
* Remove TODO marker; The buffer is in stopped state and its data won't be accessed
* Add mutex locks to music/stream functions directly operating on buffer
* Secure UpdateMusicStream/PlayMusicStream/UpdateAudioStream;
This change is twofold:
* Add locks to UpdateMusicStream/UpdateAudioStream (second one needed separation)
* Remove unnecessary hack to restart music - inlining the statements resulted in a no-op
Especially the second part made it easier to ensure thread-safety overall
* Remove redundant check; Already checked at beginning of function
For consistency, now _almost_ all `Draw*Lines()` functions use `RL_LINES` mode for drawing. It solves the linked issue but it can have other implications, as mentioned in the WARNING comment in `DrawRectangleLines()`.
Side note: `DrawRectangleRoundedLines()` now should be reviewed for consistency.
The way the current code worked was by calling `GetCurrentMonitor()`,
which would always return the monitor at position (0,0). This isn't the
primary monitor on all platforms, on Linux in particular it isn't the
case.
This isn't the case on the SDL backend, after calling `InitWindow()` the
window would always show up on the primary monitor. Even on the GLFW
backend, if the full screen flag was set it would attempt to put it on
the primary monitor as it would call `glfwGetPrimaryMonitor()` to do it,
so for consistency's sake we should do it on windowed mode too.
The key handling in PLATFORM_DESKTOP_SDL was faulty in two ways, which
led to GetKeyPressed returning incorrect data.
CORE.Input.Keyboard.keyPressedQueue was updated only on SDL_TEXTINPUT,
meaning only text characters were registered as a pressed key, but not
function keys (eg. tab, backspace...). Also on such event, both
CORE.Input.Keyboard.keyPressedQueue and
CORE.Input.Keyboard.charPressedQueue were assigned the key's
corresponding codepoint, when CORE.Input.Keyboard.keyPressedQueue
should get the raylib keycode instead.
CORE.Input.Keyboard.keyPressedQueue is now updated on SDL_KEYDOWN event
instead.
Co-authored-by: Arthur <hi@thenightwat.ch>
The changes brought by #3891 uses `std.process.Child.run` which was
renamed from `std.process.Child.exec` in Zig version 0.11.0. This commit
adds a version check to use the appropriate function names.
Additionally, the `linux_display_backend` configuration option is added
so users can set it when running `zig build` with the `-D` option or
when using raylib as a dependency.
* Updating rcore_drm.c to only use one api for input
* Change RPI log prefix to DRM
* Remove relative checking which is not supported currently
* Loop should continue on invalid event in drm backend
* Fixed and cleaned up PollKeyboardEvents() in drm backend
* Fix GLFW runtime platform detection
* Add libwayland-dev package to workflows
* Add libxkbcommon-dev package to workflows
* Add libwayland-bin package to codeql.yml
* Add libwayland-client0 and libwayland-cursor0 packages to codeql.yml
* Use libwayland-dev in codeql.yml
* Add libxkbcommon-dev to codeql.yml
* Remove libwayland-bin from linux.yml and linux_examples.yml (libwayland-dev includes it as a dependency)
---------
Co-authored-by: Ray <raysan5@gmail.com>
I did some testing and this seems to work okay, but it *is* different to
GLFW. GLFW seems to lose "IsCursorOnScreen" for one frame upon pressing
alt+tab over the window, without a different window covering it. SDL
seems to have a more reasonable behavior for this case. Either way it's
an edge case and I don't know the exact way to fix, likely requires
internal GLFW changes.
* Screen/world-space related functions rename
* Update raylib_api.* by CI
---------
Co-authored-by: github-actions[bot] <github-actions[bot]@users.noreply.github.com>
The fingerId from SDL was used as an index into the CORE.Input.Touch
arrays, but it's an opaque / arbitrary int64, way bigger
than MAX_TOUCH_POINTS, so the first non-simulated touch event would segfault.
* Update GLFW to 3.4 (draft)
* Add _glfwConnectNull() function to rglfw.c
* Update rglfw.c
* Update Makefile
* Makefile: Replace USE_WAYLAND_DISPLAY with DISABLE_WAYLAND
* Revert "Makefile: Replace USE_WAYLAND_DISPLAY with DISABLE_WAYLAND"
This reverts commit 9e79abde786bf797d8133fd95e8a475cf6e2b066.
* GlfwImport.cmake: Replace GLFW_USE_WAYLAND with GLFW_BUILD_WAYLAND
* Update rglfw.c
* Output platform selected by GLFW to TRACELOG
* GLFW has removed Mir support
* Change sanitization check for `ExportDataAsCode`
I opted to use `isalnum` function since it should handle most cases. It
cannot however handle cases of files beginning with numbers.
* Update `ExportDataAsCode` condition
* Reinsert comment on `ExportDataAsCode`
Currently, every example fails linking likeso:
[ 3%] Linking C executable audio_mixed_processor
/usr/bin/ld: ../raylib/libraylib.a(raudio.c.o): undefined reference to symbol 'exp@@GLIBC_2.29'
/usr/bin/ld: /usr/lib/libm.so.6: error adding symbols: DSO missing from command line
collect2: error: ld returned 1 exit status
Apparently, linking libm explicitly is the solution.
* Added gamepad rumble to rcore_desktop.c and rcore_desktop_sdl.c
Still need to add to the rest of the platforms.
* Add SetGamepadVibration warnings to unimplemented platforms.
* Added MAX_GAMEPAD_VIBRATION_TIME
The rumble in SDL2 will continue for MAX_GAMEPAD_VIBRATION_TIME unless the user cancels it with a call to SetGamepadVibration(0.0f,0.0f,0.0f)
* Cast float duration value to Uint 32
* Changed defines from int to float and fixed typo
---------
Co-authored-by: Gideon Serfontein <gse@newspacesystems.com>
Fixed a grammatical error by removing "are" to change `... but some are have multiple purposes ...` to `... but some have multiple purposes ...` in `textures/textures_image_generation`
The purpose of this directory in GLFW is to provide some headers that
"mingw.org" doesn't. Raylib has long been unable to build with mingw.org
due to using certain symbols that aren't exposed in their headers.
(_ftelli64 and _access, among others.). Mingw-w64 already has the
necessary headers included, and doesn't need any of these external
implementations. For some reason, this also causes the following error
when building with Visual Studio's clang:
clang -c rglfw.c -Wall -D_GNU_SOURCE -DPLATFORM_DESKTOP -DGRAPHICS_API_OPENGL_33 -Wno-missing-braces -Werror=pointer-arith -fno-strict-aliasing -std=c99 -O1 -Werror=implicit-function-declaration -I. -Iexternal/glfw/include -Iexternal/glfw/deps/mingw
In file included from rglfw.c:61:
In file included from ./external/glfw/src/init.c:30:
In file included from ./external/glfw/src/internal.h:331:
In file included from ./external/glfw/src/platform.h:31:
In file included from ./external/glfw/src/win32_platform.h:70:
external/glfw/deps/mingw\xinput.h:227:26: error: a parameter list without types is only allowed in a function definition
227 | void WINAPI XInputEnable(WINBOOL);
|
If the last -Iexternal/glfw/deps/mingw is removed, the build works fine.
So, this workaround causes other problems, while not actually helping
raylib.
0bb605cd79/src/CMakeLists.txt (L272-L279)
GLFW's CMakeLists.txt first checks if either dinput.h or xinput.h are
provided by the toolchain, before telling the compiler to search for
headers in that directory. For EVERY compiler that can build raylib,
this is true.
In summary: This directory causes issues when building with some
compilers, and every toolchain that needs this workaround can't build
raylib anyway.
`char *txtData = (char *)RL_CALLOC(waveDataSize * 6 + 2000, sizeof(char));`
assumes every chunk being added to txtData is 6 bytes. This is not always true, sometimes a newline is involved and the data becomes 12 bytes instead, and this can cause a random segfault.
This commit changes `6` to `12`, and explains why in the comment.
* Only restore GL scale back to screen scale if we are returning to a screen, not a render texture.
* blankspace
* reset back to default screen scale when ending a render texture since we are back on the default fbo
* Fix Android keycode translation
* Simplify code a bit
* Rename KEYCODE_MAPPED_NUM to KEYCODE_MAP_SIZE
* Fix KEY_R and KEY_MENU duplicate
* Update raylib_api.* by CI
---------
Co-authored-by: github-actions[bot] <github-actions[bot]@users.noreply.github.com>
Move/Add Feature Test Macros before any includes.
See: [GNU Feature Test Macros](https://www.gnu.org/software/libc/manual/html_node/Feature-Test-Macros.html)
> You should define these macros by using ‘#define’ preprocessor directives at the top of your source code files. These directives must come before any #include of a system header file. It is best to make them the very first thing in the file, preceded only by comments.
Alternative changes to rcore would be to change _POSIX_C_SOURCE to
200809L, which removes the need to define _XOPEN_SOURCE >= 500.
These changes allow for compilation with -std=c* (such as -std=c99)
without adding -D macros to the build step.
Co-authored-by: JayLCypher <jaylcypher@github.com>
* wip: add parse.yml
* Temporarily force run
* Auto commit parse files
* Update raylib_api.* by CI
* Remove temporary setting
* format
---------
Co-authored-by: github-actions[bot] <github-actions[bot]@users.noreply.github.com>
* provide access to the shape texture so that shapes can be extended outside of raylib with the same optimizations as internal raylib functions.
* PR feedback, comply with C standards
* oops
* basic pbr example
pbr implementation includes rpbr.h and few shader files header only file, which self contain everything needed for pbr rendering. Few textures and one model of the car which is under free licence which is included inside basic_pbr.c example file currently supported shader versions are 120 and 330 , version 100 has small issue which I have to resolve
* Unloading PBRMAterial
I forgot unloading PBRMaterial
* fix small issue with texOffset assigment.
value was Vector4 at first but I found out it would be unclear for and users, so I change to have two Vector2 instead, but forgot to assign offset .
* Changed size of textures and file name changed
Changed size of textures from 2048x2048 to 1024x1024 and file name changed to shaders_basic_pbr.c ,
Added the function PBRModel PBRModelLoadFromMesh(Mesh mesh);
but GenMeshPlane(2, 2.0, 3, 3) culdn't be used because it crash once GenMeshTangents() is used with that plane mesh
* Update audio_stream_effects.c
This may slightly improve performance and be more welcoming for new users despite being an more advanced feature.
void * usually throws an error in most compilers and it would be better to just avoid it.
Also added <stdbool.h> because booleans are, sometimes, not defined by <stddef.h>.
* Update audio_stream_effects.c
* Complement SetWindowState() and ClearWindowState() for PLATFORM_WEB
* Add FLAG_WINDOW_RESIZABLE to SetWindowState() and ClearWindowState() for PLATFORM_WEB
* Fix touch gestures for PLATFORM_DESKTOP_SDL
* Complement note and optimization
* Events optimization
* Optimize gesture handling
* Reverts previous commit and fixes GESTURE_DRAG to not trigger GESTURE_SWIPE* when it ends
* Reapply previous gesture handling optimization also fixing GESTURE_DRAG to not trigger GESTURE_SWIPE* when it ends
This is a redesign on font loading, missing glyphs are skipped instead of falling back to font `.notdef` special character (usually "tofu" character).
It is changed because not all fonts support a fallback glyph.
One improvement could be allowing users to define a custom fallback character, for example `?` glyph.
I broke this in PR #3573 by accidentally removing too much
The examples still compiled fine so I didn't notice - my guess is that
cmake was still adding a separate link to glfw manually.
* Added missing textures_image_kernel example in web makefile
* Added missing --preload-file for textures_image_kernel
---------
Co-authored-by: zap <zap@physlab.ru>
RENAMED: `DrawLine<spline_type>()` to `DrawSpline<spline_type>()` for more consistent and clear naming
REVIEWED: Bezier drawing parameters order, more consistent
REVIEWED: Spline-based examples -WIP-
* Add CodeQL Workflow for Code Security Analysis
Add CodeQL Workflow for Code Security Analysis
This pull request introduces a CodeQL workflow to enhance the security analysis of our repository. CodeQL is a powerful static analysis tool that helps identify and mitigate security vulnerabilities in our codebase. By integrating this workflow into our GitHub Actions, we can proactively identify and address potential issues before they become security threats.
We added a new CodeQL workflow file (.github/workflows/codeql.yml) that
- Runs on every push and pull request to the main branch.
- Excludes queries with a high false positive rate or low-severity findings.
- Does not display results for third-party code, focusing only on our own codebase.
Testing:
To validate the functionality of this workflow, we have run several test scans on the codebase and reviewed the results. The workflow successfully compiles the project, identifies issues, and provides actionable insights while reducing noise by excluding certain queries and third-party code.
Deployment:
Once this pull request is merged, the CodeQL workflow will be active and automatically run on every push and pull request to the main branch. To view the results of these code scans, please follow these steps:
1. Under the repository name, click on the Security tab.
2. In the left sidebar, click Code scanning alerts.
Additional Information:
- You can further customize the workflow to adapt to your specific needs by modifying the workflow file.
- For more information on CodeQL and how to interpret its results, refer to the GitHub documentation and the CodeQL documentation.
Signed-off-by: Brian <bayuan@purdue.edu>
* Add CodeQL Workflow for Code Security Analysis
Add CodeQL Workflow for Code Security Analysis
This pull request introduces a CodeQL workflow to enhance the security analysis of our repository. CodeQL is a powerful static analysis tool that helps identify and mitigate security vulnerabilities in our codebase. By integrating this workflow into our GitHub Actions, we can proactively identify and address potential issues before they become security threats.
We added a new CodeQL workflow file (.github/workflows/codeql.yml) that
- Runs on every pull request (functionality to run on every push to main branches is included as a comment for convenience).
- Runs daily.
- Excludes queries with a high false positive rate or low-severity findings.
- Does not display results for git submodules, focusing only on our own codebase.
Testing:
To validate the functionality of this workflow, we have run several test scans on the codebase and reviewed the results. The workflow successfully compiles the project, identifies issues, and provides actionable insights while reducing noise by excluding certain queries and third-party code.
Deployment:
Once this pull request is merged, the CodeQL workflow will be active and automatically run on every push and pull request to the main branch. To view the results of these code scans, please follow these steps:
1. Under the repository name, click on the Security tab.
2. In the left sidebar, click Code scanning alerts.
Additional Information:
- You can further customize the workflow to adapt to your specific needs by modifying the workflow file.
- For more information on CodeQL and how to interpret its results, refer to the GitHub documentation and the CodeQL documentation (https://codeql.github.com/ and https://codeql.github.com/docs/).
Signed-off-by: Brian <bayuan@purdue.edu>
* Add CodeQL Workflow for Code Security Analysis
Add CodeQL Workflow for Code Security Analysis
This pull request introduces a CodeQL workflow to enhance the security analysis of our repository. CodeQL is a powerful static analysis tool that helps identify and mitigate security vulnerabilities in our codebase. By integrating this workflow into our GitHub Actions, we can proactively identify and address potential issues before they become security threats.
We added a new CodeQL workflow file (.github/workflows/codeql.yml) that
- Runs on every pull request (functionality to run on every push to main branches is included as a comment for convenience).
- Runs daily.
- Excludes queries with a high false positive rate or low-severity findings.
- Does not display results for git submodules, focusing only on our own codebase.
Testing:
To validate the functionality of this workflow, we have run several test scans on the codebase and reviewed the results. The workflow successfully compiles the project, identifies issues, and provides actionable insights while reducing noise by excluding certain queries and third-party code.
Deployment:
Once this pull request is merged, the CodeQL workflow will be active and automatically run on every push and pull request to the main branch. To view the results of these code scans, please follow these steps:
1. Under the repository name, click on the Security tab.
2. In the left sidebar, click Code scanning alerts.
Additional Information:
- You can further customize the workflow to adapt to your specific needs by modifying the workflow file.
- For more information on CodeQL and how to interpret its results, refer to the GitHub documentation and the CodeQL documentation (https://codeql.github.com/ and https://codeql.github.com/docs/).
Signed-off-by: Brian <bayuan@purdue.edu>
* Add CodeQL Workflow for Code Security Analysis
Add CodeQL Workflow for Code Security Analysis
This pull request introduces a CodeQL workflow to enhance the security analysis of our repository. CodeQL is a powerful static analysis tool that helps identify and mitigate security vulnerabilities in our codebase. By integrating this workflow into our GitHub Actions, we can proactively identify and address potential issues before they become security threats.
We added a new CodeQL workflow file (.github/workflows/codeql.yml) that
- Runs on every pull request (functionality to run on every push to main branches is included as a comment for convenience).
- Runs daily.
- Excludes queries with a high false positive rate or low-severity findings.
- Does not display results for git submodules, focusing only on our own codebase.
Testing:
To validate the functionality of this workflow, we have run several test scans on the codebase and reviewed the results. The workflow successfully compiles the project, identifies issues, and provides actionable insights while reducing noise by excluding certain queries and third-party code.
Deployment:
Once this pull request is merged, the CodeQL workflow will be active and automatically run on every push and pull request to the main branch. To view the results of these code scans, please follow these steps:
1. Under the repository name, click on the Security tab.
2. In the left sidebar, click Code scanning alerts.
Additional Information:
- You can further customize the workflow to adapt to your specific needs by modifying the workflow file.
- For more information on CodeQL and how to interpret its results, refer to the GitHub documentation and the CodeQL documentation (https://codeql.github.com/ and https://codeql.github.com/docs/).
Signed-off-by: Brian <bayuan@purdue.edu>
* Run CodeQL Analysis weekly + incorporate build script into WF
* remove: fail_on_error.py
* update: codeql.yml
---------
Signed-off-by: Brian <bayuan@purdue.edu>
- Now triangulated meshes are properly supported
- Simplified code to consider issue situation
- Removed mesh split per material, just define separate mesh if multiple materials are required
* Simplify POI selection
* Improve mouse logic
* Add colour cycles to the shader to show finer details. Works well with high iteration numbers
* Testing things...
* Actually fix zoom. Also allow user to reset camera with 'R'
* Reset max iterations
* Tidying & comments
* Revert to original if statement
* Make mouse logic more readable
* Style conventions
* Coding conventions - f postifx on floating points
* Missed a few f postfixes
Additionally added a volume assignment from old to new as currently there is no way to get the volume of a sound and the AudioBuffer struct is not reachable from user code due to opaque definition.
rcore_desktop_sdl.c was not present in the list of prerequisites this
patch changes them to use a wildcard, so any other platforms added in
future will be tracked properly
* Add note and todo to GetWindowScaleDPI
* Complement ToggleFullscreen and change ToggleBorderlessWindowed
* Complement SetWindowState and ClearWindowState
* [core] Add more missing implementations to SDL
Add functions: `SetWindowState`, `ClearWindowState`, `SetWindowIcon`
* Completing `SetWIndowState` and `ClearWindowState`
* Add VSync support for SDL
* Fix `CORE.Window.display` size issue
* Fix getting monitor size
We now get the size of the monitor where the window is located
* Add `ToggleBorderlessWindowed`
* Add `ToggleFullscreen`
* Add `GetMonitorPosition`
* Add `SetWindowMonitor`
NOTE: The function is implemented but incomplete
* Replace `TraceLog` by `TRACELOG`
* Fixed mouse delta issue in relative mode
Fixed a delta retrieval issue with `GetMouseDelta` when the mouse is in relative mode. Solution by @ubkp
* Fix `IsKeyPressed` issue
An issue caused `IsKeyPressed` to continuously return true for most keys when pressed
* Fix `SetGamepadMappings` returning
It feels a little unfinished when you can SetMasterVolume but can't
really Get it. So to finish the symmetry here is the GetMasterVolume
implementation.
Currently doing the following:
```
make
touch rcore_desktop.c
make
```
Will not result in rcore.o getting compiled again, despite that
rcore_desktop.c has changed
This commit resolves that
* Update `PLATFORM_DRM` implementation of `GetGamepadAxisCount`
* Update
* Update `PLATFORM_DRM` implementation of `GetGamepadName`
* Add example to test gamepad info functions
Fix typo
* Update new gamepad info example
* Move axis count update out of GamepadThread - race condition
* Remove pointless if statement
* Start integrating stuff from the mikesinput lib
* Add more logging
* Add semicolon
* Add forgotten static
* More fixes
* Update axisCount to be array
* More debugging
* Add forgotten index to ready check
* Add path logging
* Missing parenthesis
* Add missing slash
* Fix axis count being reset to 0
* Fix missing paren
* Test polling joystick button events
* Major updates
* Fix missing array index
* Fix another missing array index
* Update example
* dumb logging
* Wrong constant for ev.code handling
* More dumb logging
* Remove some logging
* Add FPS to gamepad info example and try for max FPS
* tweak
* Revert example
* Add fps back
* Clean up after merge
* Switch axisCount to be an array
`InitGraphicsDevice()` could be confusing because the function actually initialized many things: window, graphics, inputs, callbacks, timming, storage... restructured it.
* Update `PLATFORM_DRM` implementation of `GetGamepadAxisCount`
* Update
* Update `PLATFORM_DRM` implementation of `GetGamepadName`
* Add example to test gamepad info functions
Fix typo
* Update new gamepad info example
* Move axis count update out of GamepadThread - race condition
* Remove pointless if statement
* Hotfix for Vector2LineAngle(), should probably be reviewed along with the rest of raylib angle functions to determine what coordinate system we want.
* Hotfix for Vector2LineAngle(), should probably be reviewed along with the rest of raylib angle functions to determine what coordinate system we want.
* [raymath] Hotfix for Vector2Angle and corresponding example
* [raymath] Hotfix for Vector2Angle and corresponding example
---------
Co-authored-by: Ray <raysan5@gmail.com>
* update build.zig for zig 0.11.0
* fix build.zig in examples to install executable correctly
* discard build.zig, only use src/build.zig, to avoid annoying zig-out path problem
* update zig version note
* Submodules (#3311)
* Check in current state
* Add submodules to Makefile and clean up some imports
* Start moving InitGraphicsDeivce
* Move android_main and CloseWindow() out of rcore
* Move WindowShouldClose out of rcore
* Move IsWindowHidden out of rcore
* Move IsWindowMinimized out of rcore
* Move IsWindowMaximized, IsWindowFocused and IsWindowResized out of rcore
* Move ToggleFullscreen out of rcore
* Move MaximizeWindow, MinimizeWindow and RestoreWindow out of rcore
* Move 13 functions out of rcore:
ToggleBorderlessWindowed
SetWindowState
ClearWindowState
SetWindowIcon
SetWindowIcons
SetWindowTitle
SetWindowPosition
SetWindowMonitor
SetWindowMinSize
SetWindowMaxSize
SetWindowSize
SetWindowOpacity
SetWindowFocused
* Minor clean up, revert makefile change, include submodules directly in rcore
* Fix makefile comment
* Remove rcore.h from Makefile
* Remove debug include
* Move 18 functions from rcore to submodules
GetWindowHandle
GetMonitorCount
GetCurrentMonitor
GetMonitorPosition
GetMonitorWidth
GetMonitorHeight
GetMonitorPhysicalHeight
GetMonitorRefreshRate
GetWindowPosition
GetWindowScaleDPI
GetMonitorName
SetClipboardText
GetClipboardText
ShowCursor
HideCursor
EnableCursor
DisableCursor
GetTime
* Move TakeScreenshot, OpenURL, GetGamepadName out of rcore into submodules
* remove debugging #defines
* Move GetMonitorPhysicalWidth from rcore to submodule
* Move GetGamepadAxisCount from rcore
* Move SetGamepadMappings out of rcore
* Move GetMouseX, GetMouseY, GetMousePosition out of rcore
* Move SetMousePosition out of rcore
* Move GetMouseWheelMove out of rcore
* Move the last functions out of rcore
* Move shared function defs and some global var to rcore.h
* Clean up rcore.c and rcore.h a little more
* Remove unnecessary #define
---------
Co-authored-by: MichaelFiber <michael@cubeofb.org>
* REVIEWED: `PLATFORM_DESKTOP` Windows building
* Revert "REVIEWED: `PLATFORM_DESKTOP` Windows building"
This reverts commit 71a12171f768eb25053ef908732b4ce8fdf802f7.
* Reviewed Windows building
* [split] Fix compilation for web (and desktop) (#3329)
* Fix compilation for web
* Remove EM_ASM_INT from core_input_gestures_web example
* Fix raymath undefined symbols for desktop and web
* Remove raylib_opengl_interop from examples Makefile
* Revert previous commit (8651c78)
* Fix TraceLog for web and desktop
* [split] `rcore`, `rcore_web` and `rcore_desktop` changes (batch 2) (#3334)
* Fix formatting
* Reapply commit 9d230d7 (#3305) that was missing
* Reapplies commits 719365f (#3309) and 8a1779b (#3312) that were missing
* Reapply commit 5c9cc3f (#3323) that was missing
* Reapply commit a2b3b1e that was missing
* Revert commit cef25c6 to fix macro redefined warning
* Move rcore.h #include to after config.h to fix macro redefinitions warnings
* [split] `rcore`, `web`, `desktop`, `android` changes (batch 3) (#3338)
* First pass to remove unneeded platform macros for web
* Second pass to remove unneeded platform macros for web
* Move GetTouchX, GetTouchY, GetTouchPosition from rcore to web, desktop, android
* Move SetMouseCursor from rcore to android, desktop, web
* [split] `rcore`, `web`, `desktop`, `android` changes (batch 4) (#3343)
* Fix ToggleBorderlessWindowed duplicated glfwSetWindowSize calls
* First pass to remove unneeded platform macros for android
* Second pass to remove unneeded platform macros for android
* Remove unneeded platform macros for desktop
* Relocate GetGamepadName and update SetGamepadMappings on android, desktop, web
* Add missing comment to web
* [split] `rcore`, `web`, `desktop`, `android` changes (batch 5) (#3345)
* Move SetExitKey from core to android, desktop, web
* Move some callbacks from core to desktop and web
* Relocate emscripten callbacks on web
* Relocate android callbacks on android
* Revert "Relocate android callbacks on android"
This reverts commit bbdbecc01ea7f871dae56019724386e73611c69c.
* Updates UnloadVrStereoConfig on rcore
* Update SetClipboardText on android
* Fix screenMin/Max default values for android
* [split] `rcore`, `drm` changes (#3347)
* Tweak makefiles for PLATFORM_DRM and move rcore_drm's dependencies to rcore.h
* Move drm functions to rcore_drm.c
* Fix a typo in rcore.c
* Add SetExitKey to rcore_drm.c
---------
Co-authored-by: MichaelFiber <michael@cubeofb.org>
* Fix compilation for android (#3360)
* Fix android include (#3364)
* Reviewed platform split #3313
- Added file headers info
- Added TRACELOG message for unimplemented functions
- Reviewed code formatting and organization
- Several code tweaks
* REVIEWED: `GetDirectoryPath()`
---------
Co-authored-by: MichaelFiber <42419558+michaelfiber@users.noreply.github.com>
Co-authored-by: MichaelFiber <michael@cubeofb.org>
Co-authored-by: ubkp <118854183+ubkp@users.noreply.github.com>
* reveiwed GetWorldToScreenEx
Used the inputted "width" instead of global CORE.window.
Used Vector3Transform instead of quaternion.
* reverted accidental unrelated change
* reverted Vector3Transform back
* fixed mistyped result
---------
Co-authored-by: Brian-E <brian@intra.fo>
I looked at the linked Factor binding page for Raylib and found that the file [summary.txt](https://github.com/factor/factor/blob/master/extra/raylib/summary.txt) has the following text in it:
```
Bindings for Raylib 4.5
```
The bindings have also been updated within the last week.
This implies that Factor's Raylib bindings are either already up to date with v4.5 or will be soon.
Thus, I have submitted this likely correction to Raylib's bindings table.
(PS: There are other Factor Raylib bindings on the internet that are less up-to-date, so don't confuse those with this.)
* Added macros for EPSILON
This is so the functions can be easily copied and used.
* used `#if !defined()` instead of `#ifndef`
---------
Co-authored-by: Brian-E <brian@intra.fo>
* Prettified a comment
* fixed broken indentation caused by another commit.
the commit renamed a bool to int and broke indentation: 233cf3970c9148c4963cfdea20e49e761104f9de
* Changed 0.001 and 0.00001 to EPSILON
This commit is untested.
I don't know what consequences this has.
Since the commits that added these numbers were before epsilon was added,
I have assumed that epsilon could replace them.
* Prettied up indentation in a few places
* removed spacing around *, standardizing it.
* I may have gotten overboard with indentation
* removed a few useless parenthesis
* Added fortran-raylib
* Fix examples/others/rlgl_standalone.c compilation issue (#3242)
* Update BINDINGS.md
* Ignore unused return value of GetCodepointNext in GetCodepointCount (#3241)
* Ignore unused return value of GetCodepointNext in GetCodepointCount
Removes the last warning from non-external libraries when compiling with
the default build configuration on x64 Linux.
* Remove unnecessary void cast in GetCodepointCount
* Fix#3246
* Revert "Fix #3246"
This reverts commit e4dcbd518091a5854a517ea4cfc3f7e2d29de1a7.
* Fix text_unicode.c example crashing (#3250)
* Fix text_unicode.c example crashing
* Adjust the text_unicode.c example crashing fix
* tweaks
* add build.zig options for individual modules (#3254)
* Add `IsKeyPressedRepeat` (desktop only) (#3245)
Since the key pressed are handle by comparing current vs previous
state (ie frame), a special way is needed to handle key repeats.
* Reviewed `IsKeyPressedRepeat()` #3248
* Update rcore.c (#3255)
* Match CMakeOptions.txt options default values (#3258)
* Fix SetClipboardText for web (#3257)
* [Image] Validate that ImageDrawRectangleRec is drawing entirely inside the image (#3264)
* Add a function to clone a sound and share data with another sound.
* rename items based on feedback
* PR Feedback, use custom unload for sound alias, not variant of normal sound unloading
* sound_multi example
* Validate that image rect drawing is inside the image so we don't overflow a buffer
* remove files that should not have been added.
* remove changes that should not have been
* revert
* adsfasdfsdfsdf
* Add Vector3 Projecting and Rejection to Raymath (#3263)
* Update raymath.h
* formatting
* [Feature] IsKey... safety checks and more (#3256)
* [Feature] Add GetKeyRepeat
* Update rcore.c
* Simpler design, only one repeat per frame
* Update config.h
* Update rcore.c
* Add KEYBOARD_KEYS_MASK
* Update config.h
* reversions
* Update rcore.c
* Update rcore.c
* change docs
* Update rcore.c
* Update rcore.c
* Update rcore.c
* Update rcore.c
* Update rcore.c
* Update raylib.h
* Update rcore.c
* Update rcore.c
* Update rcore.c
* Update rcore.c
* Update rcore.c
* Update rcore.c
* Update rcore.c
* Update rcore.c
* Fix bug where default shaders was not linking. (#3261)
* Formating review
* Add missing cmake options (#3267)
* Fix CMake extraneous -lglfw (#3266)
Closes#3265.
The problem: LIBS_PRIVATE is a list of library names (used by pkg-config), but the shared library of the same name doesn't always exist.
* Fix example/models/models_loading_gltf.c controls (#3268)
* Fix example/models/models_loading_m3d.c controls (#3269)
* Remove e from secondes (#3270)
* Fix example/audio/audio_module_player.c help instructions and small bug (#3272)
* Fix example/audio/audio_module_player.c help instructions and small bug
* Update example/audio/audio_module_player.png screenshot
* Use type name instead of valid specifier
long long --> long long int
* REVIEWED: `GetFileLength()`, added comment #3262
* Update examples/models/models_loading_gltf.png;m3d.png screenshots (#3273)
* Remove a duplicated screenshot and add missing one (#3275)
* Add examples/shaders/shaders_lightmap.c to Makefiles (#3276)
* Fix examples/others/easings_testbed.c help instructions and small tweak (#3277)
* Fix examples/shaders/shaders_texture_outline.c help instructions (#3278)
* Fix examples/shapes/shapes_collision_area.c help instructions (#3279)
* RENAMED: LoadFont*() parameter names for consistency and coherence
* Fix uninitialized thread-locals in stbi #3282 (#3283)
* REVIEWED: Added `SetTextLineSpacing()` to multiline examples
* REVIEWED: Data size type consistency between functions #3168
* Some tweaks
* Use internal default allocators, instead of user-exposed ones
* Added rudimentary SVG support. (#2738)
* Added rudimentary SVG support. Added 2 functions ImageLoadSvg and ImageLoadSvgWithSize.
* Added an example on how to use ImageLoadSvgWithSize and adjusted Makefiles accordingly.
* Added actual correct example file.
* Reviewed the code to keep the raylib coding conventions in mind.
Moved the LoadImageSvg() code into LoadImage() guarded by SUPPORT_FILEFORMAT_SVG.
Renamed LoadImageSvgWithSize() to LoadImageSvg().
Added a LoadImageSvgFromString() function to parse the loaded SVG into an actual image. This does the bulk of the work.
* Fixed typo.
---------
Co-authored-by: Ray <raysan5@gmail.com>
* REVIEWED: `LoadImageSvg()`
* REVIEWED: `LoadImageSvg()`
* Add SUPPORT_FILEFORMAT_SVG to cmake (#3284)
* Fix examples/textures/textures_fog_of_war.c help instructions (#3285)
* Fix examples/textures/textures_image_rotate.c help instructions (#3286)
* Update rtextures.c
* Fix#3247
* Update config.h
* Fix#3293
* Disable UBSAN in zig builds. (#3292)
Zig debug builds automatically enable ubsan.
As the fix for #1891 had to be reverted, debug builds using zig will crash like so:
```
Illegal instruction at address 0x3237d2
raylib/src/rlgl.h:3690:91: 0x3237d2 in rlDrawVertexArrayElements (/home/rcorre/src/raylib-zig-template/raylib/src/rcore.c)
glDrawElements(GL_TRIANGLES, count, GL_UNSIGNED_SHORT, (const unsigned short *)buffer + offset);
```
This disables UBSAN when using zig to build raylib.
* Update README.md (#3290)
specially -> especially
* Update cmake SUPPORT_FILEFORMAT_SVG default value (#3291)
* Mouse offset and scaling must be considered also on web!
* Update rcore.c
* Update Makefile : clean raygui.c & physac.c (#3296)
* Remove PLATFORM_RPI (#3232)
* Remove PLATFORM_RPI
* remove build artifacts
---------
Co-authored-by: MichaelFiber <michael@cubeofb.org>
Co-authored-by: Ray <raysan5@gmail.com>
* Review to avoid UBSAN complaining #1891
* added raylib-raku to bindings (#3299)
* examples: core: adds 2D camera two player split screen (#3298)
* Reviewed examples for consistency
* Update rtext.c
* Some code restructuring for input functions, consistency review
* Remove unneeded #if (#3301)
Co-authored-by: MichaelFiber <michael@cubeofb.org>
* Revert "Disable UBSAN in zig builds. (#3292)" (#3303)
This reverts commit a316f9e7fc7f8e06852a40544e57f89018672ee4.
Issue #1891 was fixed again, so this is no longer needed.
* rtextures: Fix ImageDraw() source clipping when drawing beyond top left (#3306)
* REVIEWED: `TextToPascal()` issue when first char is uppercase
* Implement FLAG_WINDOW_RESIZABLE for web (#3305)
Fixes#3231
* Update BINDINGS.md (#3307)
Fix Kaylib binding. Reroute to a new repository.
Binding renamed.
* Update webassembly.yml
* Add claw-raylib to BINDINGS.md (#3310)
* Add SetWindowMaxSize for desktop and web (#3309)
* Add SetWindowMaxSize for desktop and web
* Remove SizeInt and respective adjustments
* Update rtextures.c
* Reviewed parameters for consistency
* Rename windowM* to screenM* (#3312)
* Update BINDINGS.md (#3317)
Update TurboRaylib bindings
* Update rmodels.c
* Update BINDINGS.md with vaiorabbit/raylib-bindings (#3318)
* fixed spelling mistake
* put back parenthesis
* reverted major allignment changes
* reverted parser output changes
* reverted one more indentation change
---------
Co-authored-by: Brian-E <brian@intra.fo>
Co-authored-by: Ray <raysan5@gmail.com>
Co-authored-by: ubkp <118854183+ubkp@users.noreply.github.com>
Co-authored-by: ashn <60763262+ashn-dot-dev@users.noreply.github.com>
Co-authored-by: actondev (Christos) <chris.actondev@gmail.com>
Co-authored-by: vitopigno <103512727+VitusVeit@users.noreply.github.com>
Co-authored-by: Asdqwe <asdqwe@asdqwe.com>
Co-authored-by: Jeffery Myers <jeffm2501@gmail.com>
Co-authored-by: Ethan Simpson <ethansimpson@xtra.co.nz>
Co-authored-by: Nickolas McDonald <43690021+n77y@users.noreply.github.com>
Co-authored-by: Branimir Ričko <rickobranimir@gmail.com>
Co-authored-by: iacore <74560659+iacore@users.noreply.github.com>
Co-authored-by: Ethan Conneely <Econn50@outlook.com>
Co-authored-by: Johannes Barthelmes <615914+jbarthelmes@users.noreply.github.com>
Co-authored-by: bXi <bluepunk@gmail.com>
Co-authored-by: Ryan Roden-Corrent <ryan@rcorre.net>
Co-authored-by: Ikko Eltociear Ashimine <eltociear@gmail.com>
Co-authored-by: SuperUserNameMan <yoann@terminajones.com>
Co-authored-by: MichaelFiber <42419558+michaelfiber@users.noreply.github.com>
Co-authored-by: MichaelFiber <michael@cubeofb.org>
Co-authored-by: Dan Vu <danvu.hustle@gmail.com>
Co-authored-by: Gabriel dos Santos Sanches <gabrielssanches@gmail.com>
Co-authored-by: Rob Loach <robloach@gmail.com>
Co-authored-by: Peter0x44 <peter0x44@disroot.org>
Co-authored-by: Kenta <106167071+Its-Kenta@users.noreply.github.com>
Co-authored-by: bohonghuang <1281299809@qq.com>
Co-authored-by: turborium <45082001+turborium@users.noreply.github.com>
Co-authored-by: Wilson Silva <wilson.dsigns@gmail.com>
Zig debug builds automatically enable ubsan.
As the fix for #1891 had to be reverted, debug builds using zig will crash like so:
```
Illegal instruction at address 0x3237d2
raylib/src/rlgl.h:3690:91: 0x3237d2 in rlDrawVertexArrayElements (/home/rcorre/src/raylib-zig-template/raylib/src/rcore.c)
glDrawElements(GL_TRIANGLES, count, GL_UNSIGNED_SHORT, (const unsigned short *)buffer + offset);
```
This disables UBSAN when using zig to build raylib.
* Added rudimentary SVG support. Added 2 functions ImageLoadSvg and ImageLoadSvgWithSize.
* Added an example on how to use ImageLoadSvgWithSize and adjusted Makefiles accordingly.
* Added actual correct example file.
* Reviewed the code to keep the raylib coding conventions in mind.
Moved the LoadImageSvg() code into LoadImage() guarded by SUPPORT_FILEFORMAT_SVG.
Renamed LoadImageSvgWithSize() to LoadImageSvg().
Added a LoadImageSvgFromString() function to parse the loaded SVG into an actual image. This does the bulk of the work.
* Fixed typo.
---------
Co-authored-by: Ray <raysan5@gmail.com>
* Add a function to clone a sound and share data with another sound.
* rename items based on feedback
* PR Feedback, use custom unload for sound alias, not variant of normal sound unloading
* sound_multi example
* Validate that image rect drawing is inside the image so we don't overflow a buffer
* remove files that should not have been added.
* remove changes that should not have been
* revert
* adsfasdfsdfsdf
* Ignore unused return value of GetCodepointNext in GetCodepointCount
Removes the last warning from non-external libraries when compiling with
the default build configuration on x64 Linux.
* Remove unnecessary void cast in GetCodepointCount
* Add a function to clone a sound and share data with another sound.
* rename items based on feedback
* PR Feedback, use custom unload for sound alias, not variant of normal sound unloading
* sound_multi example
* Add a function to clone a sound and share data with another sound.
* rename items based on feedback
* PR Feedback, use custom unload for sound alias, not variant of normal sound unloading
* Update raylib.h
Changed SetWindowTitle's description
* Update rcore.c
SetWindowTitle now works on web
* Update rcore.c
InitWindow title now works with web platform too.
- Adds an option -Dplatform_drm when using zig build
- When building for linux, checks whether -Dplatform_drm is present and configures the build accordingly.
Support creating a 3x3 pixels white rectangle at the bottom-right corner of the generated font atlas image, useful for shapes+text drawing in a single draw call!
Working from wsl and compiling for windows this change makes it much easier to compile a static library for windows on arm.
To compile a static library for windows on arm:
```
make PLATFORM=PLATFORM_DESKTOP TARGET_OS=WINDOWS CROSS_CC=/llvm/bin/aarch64-w64-mingw32-gcc CROSS_AR=/llvm/bin/aarch64-w64-mingw32-ar
```
This does not work to compile a shared library yet, only static.
* Add options to zig compile options
Support for compiling with raygui, raymath, and physac.
Also outputs the required headers.
Raygui should be located `../raygui` relative to the repo root
Physac should be located `../physac` relative to the repo root
This behavior matches options in the Makefile
* Move Options struct
* Remove physac, explicit raymath, always copy rlgl.h and raymath.h
* Remove unused options from build.zig
* Add srcdir as include path for raygui.h
* Continuation of support for ES3/WebGL2
* GetTouchPointState()
* Amends to the WebGL2 PR
---------
Co-authored-by: root <root@DESKTOP-GLOV9QV>
Co-authored-by: chemguerra <online@chemaguerra.com>
I Added Analog Stick Support to the rcamera module, However this code only allowed for 4 Directions of Movement, This Changed adds the full range of Movement to the Right Analog Stick.
The color macros don't work properly in C++98, because they require
aggregate initialzation, which is a C++11 feature. So, explicitly state
how to fix this issue, instead of letting the compiler give a more vague
error message like:
main.cpp:8:23: error: expected '(' for function-style cast or type construction
ClearBackground(BLACK);
^~~~~
/opt/homebrew/Cellar/raylib/4.5.0/include/raylib.h:179:35: note: expanded from macro 'BLACK'
#define BLACK CLITERAL(Color){ 0, 0, 0, 255 } // Black
NOTE: Don't use this check with MSVC because by default, it reports
199711L regardless of any C++ version passed on command line
Only passing `/Zc:__cplusplus` will make MSVC set this correctly
see: https://learn.microsoft.com/en-us/cpp/build/reference/zc-cplusplus
* Add GenImageGradientSquare to allow square gradients
* Fix GenImageGradientSquare and add to textures_image_generation example
* Remove params from GenImageGradientSquare
I Noticed While Writing Some code for My Game im Making that there Isn't an Easy way to control the Camera With The Analog Sticks on Controller.
I Added a Couple Lines to the UpdateCamera Function :)
* Revert "Fixed broken build.zig files. Now works with latest stable compiler (as of commit, latest is 0.10.1) (#3045)"
This reverts commit de748dfffefeba1ba9bcf0c90c538d32c9cb2020 so that zig
build script works with master branch of zig.
* Added a note to build.zig files that denotes what version of zig they have been tested with.
* Standardised the note in the build.zig files
* Correction of values used only once in GenMeshCubicmap
The mapWidth and mapHeight values were only used as a limit in the for loop when they could be used throughout the function.
* mapWidth and mapHeight removed from GenMeshCubicmap
mapWidth and mapHeight have been removed from GenMeshCubicmap in favor of using cubicmap.width and cubicmap.height
Checking `<= x + w` causes off-by-one error where `CheckCollisionPointRec` will return true at the same time for two rectangles rendered right next to each, but which don't overlap (e.g. when making a 2D tile editor). This is clearly not what was intended.
* Update raudio.c
Review `raudio.c`: rewritten `ExportWaveAsCode()` to be more like rtextures.c `ExportImageAsCode()'
* no tab november
accidentally inserted a tab somewhere. corrected it.
When `i` starts with `0`, `t` is also `0`, which results in `previous == startPos == current`, this segment is not only redundant, but it also causes division-by-zero since `sqrtf(dx*dx + dy*dy)` is zero.
* Fix GetCodepointNext to return default value with size=0 on invalid input. Modify LoadCodepoints to work when GetCodepointNext returns a size of 0. All internal use of GetCodepointNext and GetCodepointPrev checked. This fix may break external code dealing with invalid input as the old code erroneously never returned a size of 0, external code that doesn't properly check for size=0 may endlessly loop or overflow a buffer on invalid input.
* Change default behaviour of GetCodepointNext to return a size of 1 instead of 0. This matches existing prod behaviour and guarantees size 1..4 is returned. Simplify internal code that uses GetCodepointNext that previously had to account for size=0.
* Simplified progressing through a UTF-8 string in ImageTextEx and MeasureTextEx. This change matches existing precedent in DrawTextEx
* GetCodepointNext: Add 10xxxxxx checks to multibyte encodings.
---------
Co-authored-by: anon <anon>
Basic packing algorithm currently follows this order: Copy pixel data -> Move offsetX for current glyph -> Check remaining space for current glyph...
Since X offset already moved according current glyph, remaining space should be checked for next glyph. Because of this, occasionally, current logic causes glyphs wrapping around texture.
Proposed fix accomplishes that by moving offsetX check to the beginning of the loop.
* Calculate exact image size in GenImageFontAtlas
Calculate exact image size with a method based on total glyph width and glyph row count
Current method seemed a little bit overkill with square root, log and power functions and only approximates image size which can be wonky with some weird fonts like cursive fonts.
Proposed method calculates image size directly with a simpler method and results exact image size needed.
* Update rtext.c
* Update rtext.c
Changed do-while to while loop, and also added an extra step to calculate maximum glyph width and excluding it from image width for extra safety.
The `qoaplay_open()` function expects a `char *`, but we are passing in a `const char *`. While this works just fine, it does issue a compiler warning when strict:
```
src/raudio.c: In function ‘LoadMusicStream’:
src/raudio.c:1290:45: warning: passing argument 1 of ‘qoaplay_open’ discards ‘const’ qualifier from pointer target type [-Wdiscarded-qualifiers]
1290 | qoaplay_desc *ctxQoa = qoaplay_open(fileName);
| ^~~~~~~~
In file included from src/raudio.c:233:
src/external/qoaplay.c:86:34: note: expected ‘char *’ but argument is of type ‘const char *’
86 | qoaplay_desc *qoaplay_open(char *path)
| ~~~~~~^~~~
```
This change casts the argument to a `char *` to fix the warning.
I'm the only maintainer and have been working hard recently to get my library to be as nice to use as possible. I found out about this language list, and getting a new language on it didn't seem so bad. A bonus for my efforts.
* Use RL_QUADS/RL_TRIANGLES for single-pixel drawing
Addresses problem mentioned in
https://github.com/raysan5/raylib/issues/2744#issuecomment-1273568263
(in short: when drawing pixels using DrawPixel{,V} in camera mode,
upscaled pixel becomes a line instead of bigger pixel)
* [rtextures] Fixed scaling down in ImageTextEx
Closes#2755
* Added global audio processor
* Renamed struct member to follow naming conventions
* Added example for AttachAudioMixedProcessor
* core functionality CAMERA_FREE
* fix example
* add remaining camera modes
* add view bobbing
* view bobbing
* catch curser in SetCameraMode
* adjust examples
* fix compilation on linux
* fix example text_draw_3d
* actually fix text_draw_3d
* Updated camera API
* Improve Vector3RotateByAxisAngle() function
* remove camera.mode dependency from low-level functions
* remove camera.mode from struct
* fixes after rebase
* adjust examples for new UpdateCamera function
* adjust example models_loading_m3d
---------
Co-authored-by: Ray <raysan5@gmail.com>
* Fix vertex color import for .m3d
* Only load vertex colors when color map and/or materials are present
* Only execute when color array is present
---------
Co-authored-by: Uneven Prankster <unevenprankster@pm.me>
These IsReady() functions provide a method in order to verify whether or not the object was loaded successfully. They're useful to make sure the assets are there prior to using them.
pilepine=>pipeline
chosing=>choosing
additioanlly=>additionally
attachmment=>attachment
initialize=>inititialize
Binded=>Bound
lattest=>latest
hi @raysan5, I ran rlgl.h into some "typo checking" program(basically a JetBrains IDE), and here are all the things that the program was able to spot and fix. as my English isn't really well I would like it if you could check that I didn't make any mistakes in the typo fixing...
Ran into an issue in raylib-cpp where a user was using raylib 4.5-dev, even though the library currently only targets 4.2. With having RAYLIB_VERSION_MAJOR and RAYLIB_VERSION_MINOR, we will be able to target different versions of raylib in different ways, via C preprocessor conditionals.
For example:
``` c
newColor = ColorTint(BLUE, RED);
TraceLog(LOG_INFO, "The color should be tinted, but this isn't supported in ryalib <= 4.2");
```
There were a few raylib modules that continued to use TraceLog() instead of the TRACELOG() macro. This change ensures that all the internal raylib modules use the TRACELOG() pattern consistently.
Touches became sticky and didn't disappear after using more than 2 fingers, fixed by getting the touch count of how many fingers are on the screen, and only looping through the available/pressed down touch points instead of looping through the maximum touch points.
Tested with more than 10 touch points, and with different MAX points value, working perfectly.
* add GLTF animation support
* use correct index when allocating animVertices and animNormals
* early exit LoadModelAnimationsGLTF if the gtlf file fails to parse
* update models/models_loading_gltf.c to play gltf animation
Updated the .blend file to use weights rather than bone parents so it
fits into the framework. Exported with weights to the .glb file.
* fix order of operations for bone scale in UpdateModelAnimation
* minor doc cleanup and improvements
* fix formatting
* fix float formatting
* fix brace alignment and replace asserts with log messages
WARNING: It could require further review of `GamepadThread()` function where `js_event gamepadEvent.number` detecting current pressed button could generate a missmatch with index 0 (reserved for button unknow). Or maybe `0` could just be `GAMEPAD_BUTTON_NONE`? In that case, consistency with other inputs should be carefully considered...
Use GLVND also when legacy implementations exist for old cmake versions
<= 3.10. This is a breaking change for old cmake versions (prior to
around 2017-10-05) which will now use GLVND rather than defaulting to
libGL.
This fixes the following warning when building:
CMake Warning (dev) at /gnu/store/qv13zgbmyx0vjav8iiqp772kp6rxvwnd-cmake-3.24.2/share/cmake-3.24/Modules/FindOpenGL.cmake:315 (message):
Policy CMP0072 is not set: FindOpenGL prefers GLVND by default when
available. Run "cmake --help-policy CMP0072" for policy details. Use the
cmake_policy command to set the policy and suppress this warning.
FindOpenGL found both a legacy GL library:
OPENGL_gl_LIBRARY: /home/simendsjo/.guix-profile/lib/libGL.so
and GLVND libraries for OpenGL and GLX:
OPENGL_opengl_LIBRARY: /home/simendsjo/.guix-profile/lib/libOpenGL.so
OPENGL_glx_LIBRARY: /home/simendsjo/.guix-profile/lib/libGLX.so
OpenGL_GL_PREFERENCE has not been set to "GLVND" or "LEGACY", so for
compatibility with CMake 3.10 and below the legacy GL library will be used.
Call Stack (most recent call first):
cmake/LibraryConfigurations.cmake:21 (find_package)
src/CMakeLists.txt:46 (include)
This warning is for project developers. Use -Wno-dev to suppress it.
See https://cmake.org/cmake/help/latest/policy/CMP0072.htmlCloses#2825
* Updated rcore.c, renamed 'time' to 'time_nsec'
When PLATFORM_ANDROID, PLATFORM_RPI or PLATFORM_DRM were defined, there is a compilation error to redefinition of the variable 'time', so the second instance of 'time' was changed to 'time_nsec' which both fixes the name collision and more accurately describes what that variable represents.
* Renamed 'time_nsec' to 'nanoSeconds'
* JSON parser: Use array for function params (#2255)
* Parser: follow C convention of type before name
* Update file names in build scripts
* Rename lighting_instanced shader to instancing
Added a comment explaining the range limitations of GetRandomValue.
Added a run-time warning TRACELOG when GetRandomValue is called with an invalid range.
Those two functions have been moved to a new example: `models_draw_cube_texture`. The reasons for this decision:
- Function inflexibility: Many users with the need to draw a textured cube could need to customize the texture applied to every face, that function did not allow that kind of functionality.
- rlgl functionality exposure: The implementation exposed will teach users how to implement custom textured triangles drawing.
Now Raylib-py is a releases-only project.
For now on, code maintenance will happen in a parallel project created to automate the binding generation: RaylibpyCtbg
This function can be easely replicated using `DrawtexturePro()` and actually it was doing some assumptions not transparent to the user. Even the function name was confusing. No example was available for it and actually noone requested one example.
* Improved billboards example, highlighting rotation and draw order
* changes to conform to the raylib conventions
* NOW it conforms
Co-authored-by: nobytesgiven <nobytesgiven@users.noreply.github.com>
* build.zig: let user decide how to set build mode
This should delegate the responsibility of calling `standardReleaseOptions` and setting the build mode of the `*LibExeObjStep` step to the caller, especially since this might not be the process by which one wants to determine the build mode.
Also changes hides `getSrcDir` to enforce usage of `srcdir`, and asserts that the file is in fact inside a directory.
* build.zig: set root_src param to `null`
Supplying the header file as the root source here appears to cause a linker warning of the form:
```
LLD Link... warning(link): unexpected LLD stderr:
ld.lld: warning: {build_root}/zig-cache/o/{hash}/libraylib.a: archive member '{build_root}/zig-cache/o/{hash}/raylib.o' is neither ET_REL nor LLVM bitcode
```
Passing `null` instead fixes it.
* parser: Fail gracefully if a nonexistent file is passed on the command line
Before, if a nonexistent file was passed to LoadFileText(), it would
return NULL, and the parser would happily dereference it.
* parser: Refactor Makefile and update the path to easings.h (now reasings.h)
Before, the `make all` target would simply segfault, see 0a679d79
Now, if a file in the `make all` target doesn't exist, make will write
an error.
Individual API files can be generated likeso, provided the header file
the target depends on exists:
FORMAT=JSON EXTENSION=json make raygui_api.json
In order for the `make all` target to succeed, raygui.h, physac.h and
rmem.h need to be added to the correct directory.
* Use RL_QUADS/RL_TRIANGLES for single-pixel drawing
Addresses problem mentioned in
https://github.com/raysan5/raylib/issues/2744#issuecomment-1273568263
(in short: when drawing pixels using DrawPixel{,V} in camera mode,
upscaled pixel becomes a line instead of bigger pixel)
* [rtextures] Fixed scaling down in ImageTextEx
Closes#2755
- ADDED: `GetCodepointPrevious()`
- RENAMED: `GetCodepoint()` -> `GetCodepointNext()`, actually, reimplemented
- `GetCodepoint()` has been kept for the moment, for compatibility and also because implementation is different
- RENAMED: `TextCodepointsToUTF8()` to `LoadUTF8()`, simpler name and more aligned with raylib conventions (functions loading memory start with Load*()), parameters should be descriptive of functionailty.
- ADDED: `UnloadUTF8()`, aligned with `LoadUTF8()` to avoid allocators issues.
This adds `ImageDrawCircleLines()` and `ImageDrawCircleLinesV()` to draw outlines of circles, and updates `ImageDrawCircle()` draw a filled circle to match the effect of `DrawCircle()` and `DrawCircleLines()`.
Fixes#2683
Remove elements from touch point related arrays when touch up and
similar events are processed. This makes GetTouchPointCount() always
report the actual count of touch points, and all positions returned by
GetTouchPosition() correspond to positions of currently happening
touches.
* [rlgl] Check for extensions before enabling them
* Shift to glad on macOS
* #undef CORE_OPENGL_33
* Remove version hack and fix ASTC compression assumption
* Remove loader from glad
* Use GLAD_MALLOC/FREE instead of malloc/free
* More explicit extension checking
Currently assumes a single gamepad, has no code specific to gamepad
detection (gamepad is "detected" when an event related to gamepad
arrives). Also assumes that all gamepads look roughly like an xbox/ps
controller. Both assumptions are not strictly true, but an
implementation like that probably covers 85% of usecases.
Also it doesn't update previousButtonState so functions
IsGamepadButtonPressed() and IsGamepadButtonReleased() don't work, but
they didn't work previously on Android anyway, and they are flaky on
desktop as they are now, so the mechanism for these two functions
probably should be reworked anyway.
It's certainly an improvement compared to the previous android gamepad
handling code, which put gamepad events into touch related structs.
On android after rebinding context (which happens when you minimize and
navigate back to an app, or when you turn a screen off and back on)
there's a bug that viewport has a wrong scale and part of it is off
screen.
The change fixes it on devices I tried, but the solution feels hacky to
me. However when I attempted instead to call SetupViewport() again which
feels like a more proper solution, it didn't fix it.
Fix display -> screen coordinate conversion for android platform and
move it to the platform event handling code, simplifying
GetTouchPosition() function implementation.
Co-authored-by: Denis Pobedrya <denis.pobedrya@gmail.com>
raylib library tries to avoid `long long` usage. Several SSBO functions have been reviewed (including some renames for consistency) to minimize `long long` type usage.
This simplification will allow the usage of `rshapes` as STANDALONE mode in a future. Only a small set of `rlgl` functions are required and they can be "more" easely replaced if no `rlPushMatrix()`/`rlPopMatrix()` are involved.
More simplification planned for the future, maybe the textures dependencies.
Reasons to NOT define `_GNU_SOURCE`:
- access to lots of nonstandard GNU/Linux extension functions
- access to traditional functions which were omitted from the POSIX standard (often for good reason, such as being replaced with better alternatives, or being tied to particular legacy implementations)
- access to low-level functions that cannot be portable, but that you sometimes need for implementing system utilities like mount, ifconfig, etc.
- broken behavior for lots of POSIX-specified functions, where the GNU folks disagreed with the standards committee on how the functions should behave and decided to do their own thing.
WARNING: This could be a BREAKING CHANGE for some platforms! I'm afraid something could be wrong on `rglfw.c` module.
To be able to compile on Windows I had to modify `glfw/src/platform.c` line 74. I couldn't manage to compile without that change, help is welcome!
* Win32: resolve some symbols re-definition of windows.h in glfw3native.h
This reflects GLFW's fix: https://github.com/glfw/glfw/issues/1348
This enables to build with a external GLFW containing the
following fix:
* 05f6c13d11
Currently, glfw3native.h of the internal GLFW is customized at
2feea87b61
This fix is compatible with the current customized glfw3native.h.
This fix enables us to update it to the latest and remove the
customization.
* Win32: remove unneeded typedef
# If you wish to specify custom queries, you can do so here or in a config file.
# By default, queries listed here will override any specified in a config file.
# Prefix the list here with "+" to use these queries and those in the config file.
# For more details on CodeQL's query packs, refer to: https://docs.github.com/en/code-security/code-scanning/automatically-scanning-your-code-for-vulnerabilities-and-errors/configuring-code-scanning#using-queries-in-ql-packs
# queries: security-extended,security-and-quality
queries:security-and-quality
- name:Build
# Execute the build. You can specify a specific target with "--target <NAME>"
Some people ported raylib to other languages in form of bindings or wrappers to the library. Here is a list with all the ports available. Feel free to send a PR if you know of any binding/wrapper not in this list.
Some people ported raylib to other languages in the form of bindings or wrappers to the library. Here is a list with all the ports available. Feel free to send a PR if you know of any binding/wrapper not in this list.
### Language Bindings
| name | raylib version | language | license | repo |
These are utility wrappers for specific languages, they are not required to use raylib in the language but may adapt the raylib API to be more inline with the language's pardigm.
| name | raylib version | language | license | repo |
These are utility wrappers for specific languages, they are not required to use raylib in the language but may adapt the raylib API to be more inline with the language's paradigm.
enum_option(PLATFORM "Desktop;Web;Android;Raspberry Pi;DRM" "Platform to build for.")
if(EMSCRIPTEN)
# When configuring web builds with "emcmake cmake -B build -S .", set PLATFORM to Web by default
SET(PLATFORM Web CACHE STRING "Platform to build for.")
endif()
enum_option(PLATFORM "Desktop;Web;Android;Raspberry Pi;DRM;SDL;RGFW" "Platform to build for.")
enum_option(OPENGL_VERSION "OFF;4.3;3.3;2.1;1.1;ES 2.0" "Force a specific OpenGL Version?")
enum_option(OPENGL_VERSION "OFF;4.3;3.3;2.1;1.1;ES 2.0;ES 3.0;Software" "Force a specific OpenGL Version?")
# Configuration options
option(BUILD_EXAMPLES "Build the examples." ${RAYLIB_IS_MAIN})
option(BUILD_EXAMPLES "Build the examples." ${PROJECT_IS_TOP_LEVEL})
option(CUSTOMIZE_BUILD "Show options for customizing your Raylib library build." OFF)
option(ENABLE_ASAN "Enable AddressSanitizer (ASAN) for debugging (degrades performance)" OFF)
option(ENABLE_ASAN "Enable AddressSanitizer (ASAN) for debugging (degrades performance)" OFF)
option(ENABLE_UBSAN "Enable UndefinedBehaviorSanitizer (UBSan) for debugging" OFF)
option(ENABLE_MSAN "Enable MemorySanitizer (MSan) for debugging (not recommended to run with ASAN)" OFF)
# Shared library is always PIC. Static library should be PIC too if linked into a shared library
option(WITH_PIC "Compile static library as position-independent code" OFF)
option(BUILD_SHARED_LIBS "Build raylib as a shared library" OFF)
option(MACOS_FATLIB "Build fat library for both i386 and x86_64 on macOS" OFF)
cmake_dependent_option(USE_AUDIO "Build raylib with audio module" ON CUSTOMIZE_BUILD ON)
enum_option(USE_EXTERNAL_GLFW "OFF;IF_POSSIBLE;ON" "Link raylib against system GLFW instead of embedded one")
if(UNIX AND NOT APPLE)
option(USE_WAYLAND "Use Wayland for window creation" OFF)
endif()
option(INCLUDE_EVERYTHING "Include everything disabled by default (for CI usage" OFF)
# GLFW build options
option(GLFW_BUILD_WAYLAND "Build the bundled GLFW with Wayland support" OFF)
option(GLFW_BUILD_X11 "Build the bundled GLFW with X11 support" ON)
option(INCLUDE_EVERYTHING "Include everything disabled by default (for CI usage)" OFF)
set(OFF ${INCLUDE_EVERYTHING} CACHE INTERNAL "Replace any OFF by default with \${OFF} to have it covered by this option")
# raylib modules included
cmake_dependent_option(SUPPORT_MODULE_RSHAPES "Include module: rshapes" ON CUSTOMIZE_BUILD ON)
cmake_dependent_option(SUPPORT_MODULE_RTEXTURES "Include module: rtextures" ON CUSTOMIZE_BUILD ON)
cmake_dependent_option(SUPPORT_MODULE_RTEXT "Include module: rtext" ON CUSTOMIZE_BUILD ON)
cmake_dependent_option(SUPPORT_MODULE_RMODELS "Include module: rmodels" ON CUSTOMIZE_BUILD ON)
cmake_dependent_option(SUPPORT_MODULE_RAUDIO "Include module: raudio" ON CUSTOMIZE_BUILD ON)
include(ParseConfigHeader)
# rcore.c
cmake_dependent_option(SUPPORT_CAMERA_SYSTEM "Provide camera module (rcamera.h) with multiple predefined cameras: free, 1st/3rd person, orbital" ON CUSTOMIZE_BUILD ON)
cmake_dependent_option(SUPPORT_GESTURES_SYSTEM "Gestures module is included (rgestures.h) to support gestures detection: tap, hold, swipe, drag" ON CUSTOMIZE_BUILD ON)
cmake_dependent_option(SUPPORT_MOUSE_GESTURES "Mouse gestures are directly mapped like touches and processed by gestures system" ON CUSTOMIZE_BUILD ON)
cmake_dependent_option(SUPPORT_SSH_KEYBOARD_RPI "Reconfigure standard input to receive key inputs, works with SSH connection" OFF CUSTOMIZE_BUILD OFF)
cmake_dependent_option(SUPPORT_DEFAULT_FONT "Default font is loaded on window initialization to be available for the user to render simple text. If enabled, uses external module functions to load default raylib font (module: text)" ON CUSTOMIZE_BUILD ON)
cmake_dependent_option(SUPPORT_SCREEN_CAPTURE "Allow automatic screen capture of current screen pressing F12, defined in KeyCallback()" ON CUSTOMIZE_BUILD ON)
cmake_dependent_option(SUPPORT_GIF_RECORDING "Allow automatic gif recording of current screen pressing CTRL+F12, defined in KeyCallback()" ON CUSTOMIZE_BUILD ON)
cmake_dependent_option(SUPPORT_BUSY_WAIT_LOOP "Use busy wait loop for timing sync instead of a high-resolution timer" OFF CUSTOMIZE_BUILD OFF)
cmake_dependent_option(SUPPORT_EVENTS_WAITING "Wait for events passively (sleeping while no events) instead of polling them actively every frame" OFF CUSTOMIZE_BUILD OFF)
cmake_dependent_option(SUPPORT_WINMM_HIGHRES_TIMER "Setting a higher resolution can improve the accuracy of time-out intervals in wait functions" OFF CUSTOMIZE_BUILD OFF)
cmake_dependent_option(SUPPORT_COMPRESSION_API "Support for compression API" ON CUSTOMIZE_BUILD ON)
# rshapes.c
cmake_dependent_option(SUPPORT_QUADS_DRAW_MODE "Use QUADS instead of TRIANGLES for drawing when possible. Some lines-based shapes could still use lines" ON CUSTOMIZE_BUILD ON)
# rtextures.c
cmake_dependent_option(SUPPORT_IMAGE_EXPORT "Support image exporting to file" ON CUSTOMIZE_BUILD ON)
cmake_dependent_option(SUPPORT_IMAGE_MANIPULATION "Support multiple image editing functions to scale, adjust colors, flip, draw on images, crop... If not defined only three image editing functions supported: ImageFormat(), ImageAlphaMask(), ImageToPOT()" ON CUSTOMIZE_BUILD ON)
cmake_dependent_option(SUPPORT_FILEFORMAT_PNG "Support loading PNG as textures" ON CUSTOMIZE_BUILD ON)
cmake_dependent_option(SUPPORT_FILEFORMAT_DDS "Support loading DDS as textures" ON CUSTOMIZE_BUILD ON)
cmake_dependent_option(SUPPORT_FILEFORMAT_HDR "Support loading HDR as textures" ON CUSTOMIZE_BUILD ON)
cmake_dependent_option(SUPPORT_FILEFORMAT_KTX "Support loading KTX as textures" ON CUSTOMIZE_BUILD ON)
cmake_dependent_option(SUPPORT_FILEFORMAT_ASTC "Support loading ASTC as textures" ON CUSTOMIZE_BUILD ON)
cmake_dependent_option(SUPPORT_FILEFORMAT_BMP "Support loading BMP as textures" ${OFF} CUSTOMIZE_BUILD OFF)
cmake_dependent_option(SUPPORT_FILEFORMAT_TGA "Support loading TGA as textures" ${OFF} CUSTOMIZE_BUILD OFF)
cmake_dependent_option(SUPPORT_FILEFORMAT_JPG "Support loading JPG as textures" ${OFF} CUSTOMIZE_BUILD OFF)
cmake_dependent_option(SUPPORT_FILEFORMAT_GIF "Support loading GIF as textures" ${OFF} CUSTOMIZE_BUILD OFF)
cmake_dependent_option(SUPPORT_FILEFORMAT_QOI "Support loading QOI as textures" ${OFF} CUSTOMIZE_BUILD OFF)
cmake_dependent_option(SUPPORT_FILEFORMAT_PSD "Support loading PSD as textures" ${OFF} CUSTOMIZE_BUILD OFF)
cmake_dependent_option(SUPPORT_FILEFORMAT_PKM "Support loading PKM as textures" ${OFF} CUSTOMIZE_BUILD OFF)
cmake_dependent_option(SUPPORT_FILEFORMAT_PVR "Support loading PVR as textures" ${OFF} CUSTOMIZE_BUILD OFF)
# rtext.c
cmake_dependent_option(SUPPORT_FILEFORMAT_FNT "Support loading fonts in FNT format" ON CUSTOMIZE_BUILD ON)
cmake_dependent_option(SUPPORT_FILEFORMAT_TTF "Support loading font in TTF/OTF format" ON CUSTOMIZE_BUILD ON)
cmake_dependent_option(SUPPORT_TEXT_MANIPULATION "Support text manipulation functions" ON CUSTOMIZE_BUILD ON)
# rmodels.c
cmake_dependent_option(SUPPORT_MESH_GENERATION "Support procedural mesh generation functions, uses external par_shapes.h library. NOTE: Some generated meshes DO NOT include generated texture coordinates" ON CUSTOMIZE_BUILD ON)
cmake_dependent_option(SUPPORT_FILEFORMAT_OBJ "Support loading OBJ file format" ON CUSTOMIZE_BUILD ON)
cmake_dependent_option(SUPPORT_FILEFORMAT_MTL "Support loading MTL file format" ON CUSTOMIZE_BUILD ON)
cmake_dependent_option(SUPPORT_FILEFORMAT_IQM "Support loading IQM file format" ON CUSTOMIZE_BUILD ON)
cmake_dependent_option(SUPPORT_FILEFORMAT_GLTF "Support loading GLTF file format" ON CUSTOMIZE_BUILD ON)
cmake_dependent_option(SUPPORT_FILEFORMAT_VOX "Support loading VOX file format" ON CUSTOMIZE_BUILD ON)
# raudio.c
cmake_dependent_option(SUPPORT_FILEFORMAT_WAV "Support loading WAV for sound" ON CUSTOMIZE_BUILD ON)
cmake_dependent_option(SUPPORT_FILEFORMAT_OGG "Support loading OGG for sound" ON CUSTOMIZE_BUILD ON)
cmake_dependent_option(SUPPORT_FILEFORMAT_XM "Support loading XM for sound" ON CUSTOMIZE_BUILD ON)
cmake_dependent_option(SUPPORT_FILEFORMAT_MOD "Support loading MOD for sound" ON CUSTOMIZE_BUILD ON)
cmake_dependent_option(SUPPORT_FILEFORMAT_MP3 "Support loading MP3 for sound" ON CUSTOMIZE_BUILD ON)
cmake_dependent_option(SUPPORT_FILEFORMAT_FLAC "Support loading FLAC for sound" ${OFF} CUSTOMIZE_BUILD OFF)
# utils.c
cmake_dependent_option(SUPPORT_STANDARD_FILEIO "Support standard file io library (stdio.h)" ON CUSTOMIZE_BUILD ON)
cmake_dependent_option(SUPPORT_TRACELOG "Show TraceLog() output messages. NOTE: By default LOG_DEBUG traces not shown" ON CUSTOMIZE_BUILD ON)
Operators | value1 + value2 | `int sum = value + 10;`
@ -28,6 +28,10 @@ Some other conventions to follow:
- **ALWAYS** initialize all defined variables.
- **Do not use TABS**, use 4 spaces instead.
- Avoid trailing spaces, please, avoid them
- Comments always start with space + capital letter and never end with a '.', place them **before** the line(s) they refer to
```c
// This is a comment in raylib or raylib examples
```
- Control flow statements always are followed **by a space**:
```c
if (condition) value = 0;
@ -37,6 +41,7 @@ while (!WindowShouldClose())
}
// Always use accumulators as `x++` instead of `++x`
for (int i = 0; i <NUM_VALUES;i++)printf("%i",i);
// Be careful with the switch formatting!
@ -79,7 +84,7 @@ _NOTE: Avoid any space or special character in the files/dir naming!_
- Data files should be organized by context and usage in the game, think about the loading requirements for data and put all the resources that need to be loaded at the same time together.
- Use descriptive names for the files, it would be perfect if just reading the name of the file, it was possible to know what is that file and where fits in the game.
- Here it is an example, note that some resources require to be loaded all at once while other require to be loaded only at initialization (gui, font).
- Here is an example, note that some resources require to be loaded all at once while other require to be loaded only at initialization (gui, font).
@ -39,13 +40,13 @@ Yes, raylib can be used to create any kind of application, not just videogames.
### How can I learn to use raylib? Is there some official documentation or tutorials?
raylib does not provide a "standard" API reference documentation like other libraries, all of the raylib functionality is exposed in a simple [cheatsheet](https://www.raylib.com/cheatsheet/cheatsheet.html). Most of the functions are self-explanatory and the required parameters are very intuitive. It's also highly recommended to take a look to [`raylib.h`](https://github.com/raysan5/raylib/blob/master/src/raylib.h) header file or even the source code, that is very clean and organized, intended for teaching.
raylib does not provide a "standard" API reference documentation like other libraries, all of the raylib functionality is exposed in a simple [cheatsheet](https://www.raylib.com/cheatsheet/cheatsheet.html). Most of the functions are self-explanatory and the required parameters are very intuitive. It's also highly recommended to take a look at [`raylib.h`](https://github.com/raysan5/raylib/blob/master/src/raylib.h) header file or even the source code, that is very clean and organized, intended for teaching.
raylib also provides a big [collection of examples](https://www.raylib.com/examples.html), to showcase the multiple functionality usage (+120 examples). Examples are categorized by the internal module functionality and also define an estimated level of difficulty to guide the users checking them.
There is also a [FAQ on the raylib Wiki](https://github.com/raysan5/raylib/wiki/Frequently-Asked-Questions) with common technical questions.
There are also many tutorials on the internet and YouTube created by the growing raylib community along the years.
There are also many tutorials on the internet and YouTube created by the growing raylib community over the years.
[raylib Discord Community](https://discord.gg/raylib) is also a great place to join and ask questions, the community is very friendly and always ready to help.
@ -55,7 +56,7 @@ raylib is [free and open source](https://github.com/raysan5/raylib). Anyone can
### What is the raylib license?
raylib source code is licensed under an unmodified zlib/libpng license, which is an OSI-certified, BSD-like license that allows static linking with closedsource software. Check [LICENSE](https://github.com/raysan5/raylib/blob/master/LICENSE) for further details.
raylib source code 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](https://github.com/raysan5/raylib/blob/master/LICENSE) for further details.
### What platforms are supported by raylib?
@ -89,25 +90,25 @@ I personally consider raylib a graphics library with some high-level features ra
### What does raylib provide that other engines or libraries don't?
I would say "simplicity" and "enjoyment" at a really low-level of coding but actually is up to the user to discover it, to try it and to see if it fits their needs. raylib is not good for everyone but it's worth a try.
I would say "simplicity" and "enjoyment" at a really low level of coding but actually it is up to the user to discover it, to try it and to see if it fits their needs. raylib is not good for everyone but it's worth a try.
### How does raylib compare to Unity/Unreal/Godot?
Those engines are usually big and complex to use, providing lot of functionality. They require some time to learn and test, they usually abstract many parts of the game development process and they usually provide a set of tools to assist users on their creations (like a GUI editor).
raylib is a simple programming library, with no integrated tools or editors. It gives full control to users at a very low-level to create graphics applications in a more handmade way.
raylib is a simple programming library, with no integrated tools or editors. It gives full control to users at a very lowlevel to create graphics applications in a more handmade way.
### What development tools are required for raylib?
To develop raylib programs you only need a text editor (with recommended code syntax highlighting) and a compiler.
A [raylib Windows Installer](https://raysan5.itch.io/raylib) package is distributed including the Notepad++ editor and MinGW (GCC) compiler pre-configured for Windows for new users as an starter-pack but for more advance configurations with other editors/compilers, [raylib Wiki](https://github.com/raysan5/raylib/wiki) provides plenty of configuration tutorials.
A [raylib Windows Installer](https://raysan5.itch.io/raylib) package is distributed including the Notepad++ editor and MinGW (GCC) compiler pre-configured for Windows for new users as an starter-pack but for more advanced configurations with other editors/compilers, [raylib Wiki](https://github.com/raysan5/raylib/wiki) provides plenty of configuration tutorials.
### What are raylib's external dependencies?
raylib is self-contained, it has no external dependencies to build it. But internally raylib uses several libraries from other developers, mostly used to load specific file-formats.
raylib is self-contained, it has no external dependencies to build it. But internally raylib uses several libraries from other developers, mostly used to load specific fileformats.
A detailed list of raylib dependencies could be found on the [raylib Wiki](https://github.com/raysan5/raylib/wiki/raylib-dependencies).
A detailed list of raylib dependencies can be found on the [raylib Wiki](https://github.com/raysan5/raylib/wiki/raylib-dependencies).
### Can I use raylib with other technologies or libraries?
@ -119,8 +120,8 @@ raylib can load data from multiple standard file formats:
@ -128,10 +129,10 @@ No, raylib is built on top of OpenGL API, and there are currently no plans to su
### What could I expect to see in raylib in the future?
The main focus of the library is simplicity. Most of the efforts are invested in maintainability and bug-fixing. Despite new small features are regularly added, it's not the objective for raylib to become a full-featured engine. Personally I prefer to keep it small and enjoyable.
The main focus of the library is simplicity. Most of the efforts are invested in maintainability and bug-fixing. Despite new small features being regularly added, it's not the objective for raylib to become a full-featured engine. Personally I prefer to keep it small and enjoyable.
### Who are the raylib developers?
The main raylib developer and maintainer is [Ramon Santamaria](https://www.linkedin.com/in/raysan/) but there's 360+ contributors that have helped by adding new features, testing the library and solving issues in the 9+ years life of raylib.
The main raylib developer and maintainer is [Ramon Santamaria](https://www.linkedin.com/in/raysan/) but there are 360+ contributors that have helped by adding new features, testing the library and solving issues in the 9+ years life of raylib.
The full list of raylib contributors can be seen [on GitHub](https://github.com/raysan5/raylib/graphs/contributors).
I started developing videogames in 2006 and some years later I started teaching videogames development to young people with artistic profile, most of students had never written a single line of code.
I started developing videogames in 2006 and some years later I started teaching videogames development to young people with artistic profiles, most of students had never written a single line of code.
I decided to start with C language basis and, after searching for the most simple and easy-to-use library to teach videogames programming, I found [WinBGI](http://www.codecutter.net/tools/winbgim/); it was great and it worked very well with students, in just a couple of weeks, those students that had never written a single line of code were able to program (and understand) a simple PONG game, some of them even a BREAKOUT!
I decided to start with C language basis and, after searching for the most simple and easy-to-use library to teach videogames programming, I found [WinBGI](https://winbgim.codecutter.org/); it was great and it worked very well with students, in just a couple of weeks, those students that had never written a single line of code were able to program (and understand) a simple PONG game, some of them even a BREAKOUT!
But WinBGI was not the clearer and most organized library for my taste. There were lots of things I found confusing and some function names were not clear enough for most of the students; not to mention the lack of transparencies support and no hardware acceleration.
But WinBGI was not the clearest and most organized library for my taste. There were lots of things I found confusing and some function names were not clear enough for most of the students; not to mention the lack of transparencies support and 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.
So, I decided to create my own library, hardware accelerated, clear function names, quite organized, well structured, plain C coding and, most importantly, primarily intended to learn videogames programming.
My previous videogames development experience was mostly in C# and [XNA](https://en.wikipedia.org/wiki/Microsoft_XNA) and I really loved it, so, I decided to use C# language style notation and XNA naming conventions. That way, students were able to move from raylib to XNA, MonoGame or similar libs extremely easily.
@ -20,28 +20,28 @@ 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.
On April 2014, after 6 months of first raylib release, raylib 1.1 was 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.
Some other big changes of this new version have been the support for OGG file 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.
Lots of code changes and a 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/rcore.c) module to support two new platforms: [Android](http://www.android.com/) and [Raspberry Pi](http://www.raspberrypi.org/).
On September 2014, after 5 months 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/rcore.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.
It's been some months of really hard work to accommodate raylib to those new platforms while keeping it easy for the users. On Android, raylib manages internally the activity cycle, 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.
- A new display initialization system has been created to support multiple resolutions, adding black bars if required; the user only defines the 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.
Lots of code changes and a 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/).
@ -50,26 +50,26 @@ 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.
- 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 post-processing 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/rcamera.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).
- A brand new [camera](https://github.com/raysan5/raylib/blob/master/src/rcamera.h) 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/core_3d_camera_free.c) and [core_3d_camera_first_person.c](https://github.com/raysan5/raylib/blob/master/examples/core/core_3d_camera_first_person.c).
- New [gestures](https://github.com/raysan5/raylib/blob/master/src/rgestures.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.
- [raygui](https://github.com/raysan5/raylib/blob/master/examples/shapes/raygui.h), the new immediate-mode GUI module offers a set of functions to create simple user interfaces, primarily intended for tools development. It's still in an 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.
Lots of code changes and a 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.
- First big addition is a set of [Image manipulation functions](https://github.com/raysan5/raylib/blob/master/src/raylib.h#L1331) that have been added to crop, resize, colorize, flip, dither and even draw image-to-image or text-to-image. Now 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.
@ -77,12 +77,12 @@ On February 2016, after 4 months of raylib 1.3 release, it comes raylib 1.4. For
- [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/rgestures.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.
- [gestures](https://github.com/raysan5/raylib/blob/master/src/rgestures.h) module has been redesigned and simplified, now it can process touch events from any source, including the mouse. This way, gestures system can be used on any platform providing a 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.
and the addition of two simple functions for persistent data storage. Now raylib users can save and load game data in a file (only some platforms are supported). A simple [easings](https://github.com/raysan5/raylib/blob/master/examples/shapes/reasings.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.
@ -94,36 +94,36 @@ 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).
- 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 parameters, 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.
- 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 to 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.
- 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 significantly 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.
- Audio chiptunes support and mixing channels: Added support for module audio music (.xm, .mod) loading and playing. Multiple mixing channels are now also supported. All these 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_rcamera.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.
Other additions include a [2D camera system](https://github.com/raysan5/raylib/blob/master/examples/core/core_2d_rcamera.c), render textures for offline render (and most comprehensive [postprocessing](https://github.com/raysan5/raylib/blob/master/examples/shaders/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.
This new version is so massive that is difficult to list all the improvements, most of the raylib modules have been reviewed and [rlgl](https://github.com/raysan5/raylib/blob/master/src/rlgl.h) module has been completely redesigned to accommodate 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.
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/others/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:
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 commemorates 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 anymore!
- 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 completely self-contained, no external libraries are required anymore!
- [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!
- [Physac](https://github.com/victorfisac/Physac) module has been moved to its own repository and it has been improved A LOT, actually, the 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.
@ -131,41 +131,41 @@ On November 2016, only 4 months after raylib 1.5, arrives raylib 1.6. This new v
- 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.
Build system improvement. Added support for raylib dynamic library generation (raylib.dll) for users that prefer dynamic library linking. Also thinking on advanced users, it has been added pre-configured [Visual Studio C++ 2015 solution](https://github.com/raysan5/raylib/tree/master/projects/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:
On May 2017, around 6 months after raylib 1.6, comes another raylib installment, 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!
- 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, functions 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.
- Support of [configuration flags](https://github.com/raysan5/raylib/issues/200) on every raylib module. Advanced users can customize raylib just by choosing desired features, and 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.
- 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 compilation 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.
- New [examples](http://www.raylib.com/examples.html) and [sample games](http://www.raylib.com/games.html) added. All sample material has been reviewed, removing useless examples and adding more comprehensive ones; all material has been ported to the latest raylib version and tested on 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...
- Improved library consistency and organization in general. Functions and parameters have been renamed, some parts of the library have been cleaned and simplified, some functions have 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.
And here 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.
- [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 purposes.
- [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.
- PBR Materials support, a completely redesigned shaders and material system allows advanced 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.
- 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 the 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.
@ -178,37 +178,37 @@ New installer provided, web updated, examples re-builded, documentation reviewed
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**
It's been 9 months since last raylib version was published, a lot of things have changed since then... This new raylib version represents an inflection point in the development of the library and so, we jump to a new major version... Here is the result of almost **5 years and thousands of hours of hard work**... here 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.
- **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-dependent 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!
- **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. Undoubtedly, 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!
- **Support for continuous integration building*** through AppVeyor and Travis CI. Consequently, raylib GitHub develop branch has been removed, simplifying 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!
- **Support for TCC compiler!** Thanks to the lack of external dependencies, raylib can now be easily compiled with a **minimal toolchain**, like the one provided 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!
- 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 fileformats 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!
Probably by now, **raylib 2.0 is the simplest and easiest-to-use library to enjoy (and learn) videogames programming**... but, undoubtedly its development has exceeded any initial objective; raylib has become a simple and easy-to-use truly 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.
After almost one years since latest raylib installment, here 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 is a short recap with the highlight improvements.
- New **window management and file system 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.
- `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 behavior.
- **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.
@ -220,30 +220,30 @@ After almost one years since latest raylib installment, here it is **raylib 2.5*
- 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.
- **Skeletal animation support for 3d models**, this addition implied a redesign of `Model` data structure to accommodate 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.
This is 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.
notes on raylib 3.0
-------------------
After **10 months of intense development**, new raylib version is ready. Despite primary intended as a minor release, the [CHANGELIST](CHANGELOG) has grown so big and the library has changed so much internally that it finally became a major release. Library **internal ABI** has reveived a big redesign and review, targeting portability, integration with other platforms and making it a perfect option for other progamming [language bindings](BINDINGS.md).
After **10 months of intense development**, new raylib version is ready. Despite primary intended as a minor release, the [CHANGELIST](CHANGELOG) has grown so big and the library has changed so much internally that it finally became a major release. Library **internal ABI** has received a big redesign and review, targeting portability, integration with other platforms and making it a perfect option for other programming [language bindings](BINDINGS.md).
- All **global variables** from the multiple raylib modules have been moved to a **global context state**, it has several benefits, first, better code readability with more comprehensive variables naming and categorization (organized by types, i.e. `CORE.Window.display.width`, `CORE.Input.Keyboard.currentKeyState` or `RLGL.State.modelview`). Second, it allows better memory management to load global context state dynamically when required (not at the moment), making it easy to implement a **hot-reloading mechanism** if desired.
- All **global variables** from the multiple raylib modules have been moved to a **global context state**, it has several benefits, first, better code readability with more comprehensive variable naming and categorization (organized by types, i.e. `CORE.Window.display.width`, `CORE.Input.Keyboard.currentKeyState` or `RLGL.State.modelview`). Second, it allows better memory management to load global context state dynamically when required (not at the moment), making it easy to implement a **hot-reloading mechanism** if desired.
- All **memory allocations** on raylib and its dependencies now use `RL_MALLOC`, `RL_FREE` and similar macros. Now users can easely hook their own memory allocations mechanism if desired, having more control over memory allocated internally by the library. Additionally, it makes it easier to port the library to embedded devices where memory control is critical. For more info check raylib issue #1074.
- All **memory allocations** on raylib and its dependencies now use `RL_MALLOC`, `RL_FREE` and similar macros. Now users can easily hook their own memory allocation mechanism if desired, having more control over memory allocated internally by the library. Additionally, it makes it easier to port the library to embedded devices where memory control is critical. For more info check raylib issue #1074.
- All **I/O file accesses** from raylib are being moved to **memory data access**, now all I/O file access is centralized into just four functions: `LoadFileData()`, `SaveFileData()`, `LoadFileText()`, `SaveFileText()`. Users can just update those functions to any I/O file system. This change makes it easier to integrate raylib with **Virtual File Systems** or custom I/O file implementations.
- All **raylib data structures** have been reviewed and optimized for pass-by-value usage. One of raylib distinctive design decisions is that most of its functions receive and return data by value. This design makes raylib really simple for newcomers, avoiding pointers and allowing complete access to all structures data in a simple way. The downside is that data is copied on stack every function call and that copy could be costly so, all raylib data structures have been optimized to **stay under 64 bytes** for fast copy and retrieve.
- All **raylib tracelog messages** have been reviewd and categorized for a more comprehensive output information when developing raylib applications, now all display, input, timer, platform, auxiliar libraries, file-accesses, data loading/unloading issues are properly reported with more detailed and visual messages.
- All **raylib tracelog messages** have been reviewed and categorized for a more comprehensive output information when developing raylib applications, now all display, input, timer, platform, auxiliar libraries, file-accesses, data loading/unloading issues are properly reported with more detailed and visual messages.
- `raudio` module has been internally reviewed to accomodate the new `Music` structure (converted from previous pointer format) and the module has been adapted to the **highly improved** [`miniaudio v0.10`](https://github.com/dr-soft/miniaudio).
- `raudio` module has been internally reviewed to accommodate the new `Music` structure (converted from previous pointer format) and the module has been adapted to the **highly improved** [`miniaudio v0.10`](https://github.com/dr-soft/miniaudio).
- `text` module reviewed to **improve fonts generation** and text management functions, `Font` structure has been redesigned to better accomodate characters data, decoupling individual characters as `Image` glyphs from the font atlas parameters. Several improvements have been made to better support Unicode strings with UTF-8 encoding.
- `text` module reviewed to **improve fonts generation** and text management functions, `Font` structure has been redesigned to better accommodate characters data, decoupling individual characters as `Image` glyphs from the font atlas parameters. Several improvements have been made to better support Unicode strings with UTF-8 encoding.
- **Multiple new examples added** (most of them contributed by raylib users) and all examples reviewed for correct execution on most of the supported platforms, specially Web and Raspberry Pi. A detailed categorized table has been created on github for easy examples navigation and code access.
@ -274,19 +274,19 @@ Here the list with some highlights for `raylib 3.5`.
- NEW **configuration options** exposed: For custom raylib builds, `config.h` now exposes **more than 150 flags and defines** to build raylib with only the desired features, for example, it allows to build a minimal raylib library in just some KB removing all external data filetypes supported, very useful to generate **small executables or embedded devices**.
- NEW **automatic GIF recording** feature: Actually, automatic GIF recording (**CTRL+F12**) for any raylib application has been available for some versions but this feature was really slow and low-performant using an old gif library with many file-accesses. It has been replaced by a **high-performant alternative** (`msf_gif.h`) that operates directly on memory... and actually works very well! Try it out!
- NEW **automatic GIF recording** feature: Actually, automatic GIF recording (**CTRL+F12**) for any raylib application has been available for some versions but this feature was really slow and low-performant using an old gif library with many fileaccesses. It has been replaced by a **high-performant alternative** (`msf_gif.h`) that operates directly on memory... and actually works very well! Try it out!
- NEW **RenderBatch** system: `rlgl` module has been redesigned to support custom **render batches** to allow grouping draw calls as desired, previous implementation just had one default render batch. This feature has not been exposed to raylib API yet but it can be used by advance users dealing with `rlgl` directly. For example, multiple `RenderBatch` can be created for 2D sprites and 3D geometry independently.
- NEW **RenderBatch** system: `rlgl` module has been redesigned to support custom **render batches** to allow grouping draw calls as desired, previous implementation just had one default render batch. This feature has not been exposed to raylib API yet but it can be used by advanced users dealing with `rlgl` directly. For example, multiple `RenderBatch` can be created for 2D sprites and 3D geometry independently.
- NEW **Framebuffer** system: `rlgl` module now exposes an API for custom **Framebuffer attachments** (including cubemaps!). raylib `RenderTexture` is a basic use-case, just allowing color and depth textures, but this new API allows the creation of more advance Framebuffers with multiple attachments, like the **G-Buffers**. `GenTexture*()` functions have been redesigned to use this new API.
- NEW **Framebuffer** system: `rlgl` module now exposes an API for custom **Framebuffer attachments** (including cubemaps!). raylib `RenderTexture` is a basic use-case, just allowing color and depth textures, but this new API allows the creation of more advanced Framebuffers with multiple attachments, like the **G-Buffers**. `GenTexture*()` functions have been redesigned to use this new API.
- Improved **software rendering**: raylib `Image*()` API is intended for software rendering, for those cases when **no GPU or no Window is available**. Those functions operate directly with **multi-format** pixel data on RAM and they have been completely redesigned to be way faster, specially for small resolutions and retro-gaming. Low-end embedded devices like **microcontrollers with custom displays** could benefit of this raylib functionality!
- File **loading from memory**: Multiple functions have been redesigned to load data from memory buffers **instead of directly accessing the files**, now all raylib file loading/saving goes through a couple of functions that load data into memory. This feature allows **custom virtual-file-systems** and it gives more control to the user to access data already loaded in memory (i.e. images, fonts, sounds...).
- NEW **Window states** management system: raylib `core` module has been redesigned to support Window **state check and setup more easily** and also **before/after Window initialization**, `SetConfigFlags()` has been reviewed and `SetWindowState()` has been added to control Window minification, maximization, hidding, focusing, topmost and more.
- NEW **Window states** management system: raylib `core` module has been redesigned to support Window **state check and setup more easily** and also **before/after Window initialization**, `SetConfigFlags()` has been reviewed and `SetWindowState()` has been added to control Window minification, maximization, hiding, focusing, topmost and more.
- NEW **GitHub Actions** CI/CD system: Previous CI implementation has been reviewed and improved a lot to support **multiple build configurations** (platforms, compilers, static/shared build) and also an **automatic deploy system** has been implemented to automatically attach the diferent generated artifacts to every new release. As the system seems to work very good, previous CI platforms (AppVeyor/TravisCI) have been removed.
- NEW **GitHub Actions** CI/CD system: Previous CI implementation has been reviewed and improved a lot to support **multiple build configurations** (platforms, compilers, static/shared build) and also an **automatic deploy system** has been implemented to automatically attach the different generated artifacts to every new release. As the system seems to work very good, previous CI platforms (AppVeyor/TravisCI) have been removed.
A part of those changes, many new functions have been added, some redundant functions removed and many functions have been reviewed for consistency with the full API (function name, parameters name and order, code formatting...). Again, this release represents is a **great improvement for raylib and marks the way forward** for the library. Make sure to check [CHANGELOG](CHANGELOG) for details! Hope you enjoy it!
@ -295,7 +295,7 @@ Happy holidays! :)
notes on raylib 3.7
-------------------
April 2021, it's been about 4 months since last raylib release and here it is already a new one, this time with a bunch of internal redesigns and improvements. Surprisingly, on April the 8th I was awarded for a second time with the [Google Open Source Peer Bonus Award](https://opensource.googleblog.com/2021/04/announcing-first-group-of-google-open-source-peer-bonus-winners.html) for my contribution to open source world with raylib and it seems the library is getting some traction, what a better moment for a new release? Let's see what can be found in this new version:
April 2021, it's been about 4 months since the last raylib release and here is already a new one, this time with a bunch of internal redesigns and improvements. Surprisingly, on April 8th I was awarded for a second time with the [Google Open Source Peer Bonus Award](https://opensource.googleblog.com/2021/04/announcing-first-group-of-google-open-source-peer-bonus-winners.html) for my contribution to open source world with raylib and it seems the library is getting some traction, what a better moment for a new release? Let's see what can be found in this new version:
Let's start with some numbers:
@ -315,18 +315,18 @@ Highlights for `raylib 3.7`:
- **ADDED: glTF animations support**. glTF is the preferred models file format to be used with raylib and along the addition of a models animation API on latest raylib versions, now animations support for glTF format has come to raylib, thanks for this great contribution to [Hristo Stamenov](@object71)
- **ADDED: Music streaming support from memory**. raylib has been adding the `Load*FromMemory()` option to all its supported file formats but **music streaming** was not supported yet... until now. Thanks to this great contribution by [Agnis "NeZvērs" Aldiņš](@nezvers), now raylib supports music streamming from memory data for all supported file formats: WAV, OGG, MP3, FLAC, XM and MOD.
- **ADDED: Music streaming support from memory**. raylib has been adding the `Load*FromMemory()` option to all its supported file formats but **music streaming** was not supported yet... until now. Thanks to this great contribution by [Agnis "NeZvērs" Aldiņš](@nezvers), now raylib supports music streaming from memory data for all supported file formats: WAV, OGG, MP3, FLAC, XM and MOD.
- **RENAMED: enums values for consistency**. Most raylib enums names and values names have been renamed for consistency, now all value names start with the type of data they represent. It increases clarity and readability when using those values and also **improves overall library consistency**.
Beside those key changes, many functions have been reviewed with improvements and bug fixes, many of them contributed by the community! Thanks! And again, this release sets a **new milestone for raylib library**. Make sure to check [CHANGELOG](CHANGELOG) for detailed list of changes! Hope you enjoy this new raylib installment!
Besides those key changes, many functions have been reviewed with improvements and bug fixes, many of them contributed by the community! Thanks! And again, this release sets a **new milestone for raylib library**. Make sure to check [CHANGELOG](CHANGELOG) for detailed list of changes! Hope you enjoy this new raylib installment!
Happy **gamedev/tools/graphics** programming! :)
notes on raylib 4.0 - 8th Anniversary Edition
---------------------------------------------
It's been about 6 months since last raylib release and it's been **8 years since I started with this project**, what an adventure! It's time for a new release: `raylib 4.0`, **the biggest release ever** and an inflexion point for the library. Many hours have been put in this release to make it special, **many library details have been polished**: syntax, naming conventions, code comments, functions descriptions, log outputs... Almost all the issues have been closed (only 3 remain open at the moment of this writing) and some amazing new features have been added. I expect this **`raylib 4.0`** to be a longterm version (LTS), stable and complete enough for any new graphic/game/tool application development.
It's been about 6 months since last raylib release and it's been **8 years since I started with this project**, what an adventure! It's time for a new release: `raylib 4.0`, **the biggest release ever** and an inflection point for the library. Many hours have been put in this release to make it special, **many library details have been polished**: syntax, naming conventions, code comments, functions descriptions, log outputs... Almost all the issues have been closed (only 3 remain open at the moment of this writing) and some amazing new features have been added. I expect this **`raylib 4.0`** to be a long-term version (LTS), stable and complete enough for any new graphic/game/tool application development.
Let's start with some numbers:
@ -339,11 +339,11 @@ Let's start with some numbers:
Highlights for `raylib 4.0`:
- **Naming consistency and coherency**: `raylib` API has been completely reviewed to be consistent on naming conventions for data structures and functions, comments and descriptions have been reviewed, also the syntax of many symbols for consistency; some functions and structs have been renamed (i.e. `struct CharInfo` to `struct GlyphInfo`). Output log messages have been also improved to show more info to the users. Several articles have been writen in this process: [raylib_syntax analysis](https://github.com/raysan5/raylib/wiki/raylib-syntax-analysis) and [raylib API usage analysis](https://gist.github.com/raysan5/7c0c9fff1b6c19af24bb4a51b7383f1e). In general, a big polishment of the library to make it more consistent and coherent.
- **Naming consistency and coherency**: `raylib` API has been completely reviewed to be consistent on naming conventions for data structures and functions, comments and descriptions have been reviewed, also the syntax of many symbols for consistency; some functions and structs have been renamed (i.e. `struct CharInfo` to `struct GlyphInfo`). Output log messages have been also improved to show more info to the users. Several articles have been written in this process: [raylib_syntax analysis](https://github.com/raysan5/raylib/wiki/raylib-syntax-analysis) and [raylib API usage analysis](https://gist.github.com/raysan5/7c0c9fff1b6c19af24bb4a51b7383f1e). In general, a big polishment of the library to make it more consistent and coherent.
- **Event Automation System**: This new _experimental_ feature has been added for future usage, it allows to **record input events and re-play them automatically**. This feature could be very useful to automatize examples testing but also for tutorials with assited game playing, in-game cinematics, speedruns, AI playing and more! Note this feature is still experimental.
- **Event Automation System**: This new _experimental_ feature has been added for future usage, it allows to **record input events and re-play them automatically**. This feature could be very useful to automatize examples testing but also for tutorials with assisted game playing, in-game cinematics, speedruns, AI playing and more! Note this feature is still experimental.
- **Custom game-loop control**: As requested by some advance users, **the game-loop control can be exposed** compiling raylib with the config flag: `SUPPORT_CUSTOM_FRAME_CONTROL`. It's intended for advance users that want to control the events polling and also the timming mechanisms of their games.
- **Custom game-loop control**: As requested by some advanced users, **the game-loop control can be exposed** compiling raylib with the config flag: `SUPPORT_CUSTOM_FRAME_CONTROL`. It's intended for advanced users that want to control the events polling and also the timing mechanisms of their games.
- [**`rlgl 4.0`**](https://github.com/raysan5/raylib/blob/master/src/rlgl.h): This module has been completely **decoupled from platform layer** and raylib, now `rlgl` single-file header-only library only depends on the multiple OpenGL backends supported, even the dependency on `raymath` has been removed. Additionally, **support for OpenGL 4.3** has been added, supporting compute shaders and Shader Storage Buffer Objects (SSBO). Now `rlgl` can be used as a complete standalone portable library to wrap several OpenGL version and providing **a simple and easy-to-use pseudo-OpenGL immediate-mode API**.
@ -361,12 +361,12 @@ Highlights for `raylib 4.0`:
Those are some of the key features for this new release but actually there is way more! **Support for `VOX` ([MagikaVoxel](https://ephtracy.github.io/)) 3d model format** has been added, **new [raylib_game_template](https://github.com/raysan5/raylib-game-template)** repo shared, **new `EncodeDataBase64()` and `DecodeDataBase64()` functions** added, **improved HiDPI support**, new `DrawTextPro()` with support for text rotations, completely **reviewed `glTF` models loading**, added **`SeekMusicStream()` for music seeking**, many new examples and +20 examples reviewed... **hundreds of improvements and bug fixes**! Make sure to check [CHANGELOG](CHANGELOG) for a detailed list of changes!
Undoubtely, **this is the best raylib ever**. Enjoy gamedev/tools/graphics programming! :)
Undoubtedly, **this is the best raylib ever**. Enjoy gamedev/tools/graphics programming! :)
notes on raylib 4.2
-------------------
**New raylib release!** Nine months after latest raylib, here it is a new version. It was supposed to be just a small update but, actually, it's a huge update with lots of changes a improvements. It has been possible thanks to the many contributors that has helped with issues and improvements, it's the **update with more contributors to date** and that's amazing!
**New raylib release!** Nine months after latest raylib, here is a new version. It was supposed to be just a small update but, actually, it's a huge update with lots of changes a improvements. It has been possible thanks to the many contributors that has helped with issues and improvements, it's the **update with more contributors to date** and that's amazing!
Some numbers to start with:
@ -390,8 +390,135 @@ Highlights for `raylib 4.2`:
- **New file system API**: Current API has been redesigned to be more comprehensive and better aligned with raylib naming conventions, two new functions are provided `LoadDirectoryFiles()`/`LoadDirectoryFilesEx()` to load a `FilePathList` for provided path, supporting extension filtering and recursive directory scan. `LoadDroppedFiles()` has been renamed to better reflect its internal functionality. Now, all raylib functions that start with `Load*()` allocate memory internally and a equivalent `Unload*()` function is defined to take care of that memory internally when not required any more!
- **New audio stream processors API** (_experimental_): Now real-time audio stream data processors can be added using callbacks to played Music. It allows users to create custom effects for audio like delays of low-pass-filtering (example provided). The new API uses a callback system and it's still _ highly experimental_, it differs from the usual level of complexity that provides raylib and it is intended for advance users. It could change in the future but, actually, `raudio` module is in the spotlight for future updates; [miniaudio](https://github.com/mackron/miniaudio) implements a new higher-level API that can be useful in the future for raylib.
- **New audio stream processors API** (_experimental_): Now real-time audio stream data processors can be added using callbacks to played Music. It allows users to create custom effects for audio like delays of low-pass-filtering (example provided). The new API uses a callback system and it's still _ highly experimental_, it differs from the usual level of complexity that provides raylib and it is intended for advanced users. It could change in the future but, actually, `raudio` module is in the spotlight for future updates; [miniaudio](https://github.com/mackron/miniaudio) implements a new higher-level API that can be useful in the future for raylib.
As always, there are more improvements than the key features listed, make sure to check raylib [CHANGELOG](CHANGELOG) for the detailed list of changes; for this release a `WARNING` flag has been added to all the changes that could affect bindings or productivity code. **raylib keeps improving one more version** and a special focus on maintainability has been put on the library for the future. Specific/advance functionality will be provided through **raylib-extras** repos and raylib main repo devlelopment will be focused on what made raylib popular: being a simple and easy-to-use library to **enjoy videogames programming**.
**Enjoy gamedev/tools/graphics programming!** :)
notes on raylib 4.5
-------------------
It's been **7 months** since latest raylib release. As usual, **many parts of the library have been reviewed and improved** along those months. Many issues have been closed, staying under 10 open issues at the moment of this writting and also many PRs from contributors have been received, reviewed and merged into raylib library. Some new functions have been added and some others have been removed to improve library coherence and avoid moving too high level, giving the users the tools to implement advance functionality themselfs over raylib. Again, this is a big release with a considerable amount of changes and improvements. Here is a small summary highlighting this new **rayib 4.5**.
Some numbers for this release:
- **+100** closed issues (for a TOTAL of **+1340**!)
- **+350** commits since previous RELEASE (for a TOTAL of **+6350**!)
- **+25** functions ADDED to raylib API (for a TOTAL of **516**!)
- **+40** functions REVIEWED/REDESIGNED
- **+40** new contributors (for a TOTAL of **405**!)
Highlights for `raylib 4.5`:
- **`NEW` Improved ANGLE support on Desktop platforms**: Support for OpenGL ES 2.0 on Desktop platforms (Windows, Linux, macOS) has been reviewed by @wtnbgo GitHub user. Now raylib can be compiled on desktop for OpenGL ES 2.0 and linked against [`ANGLE`](https://github.com/google/angle). This _small_ addition open the door to building raylib for all **ANGLE supported backends: Direct3D 11, Vulkan and Metal**. Please note that this new feature is still experimental and requires further testing!
- **`NEW` Camera module**: A brand new implementation from scratch for `rcamera` module, contributed by @Crydsch GitHub user! **New camera system is simpler, more flexible, more granular and more extendable**. Specific camera math transformations (movement/rotation) have been moved to individual functions, exposing them to users if required. Global state has been removed from the module and standalone usage has been greatly improved; now `rcamera.h` single-file header-only library can be used externally, independently of raylib. A new `UpdateCameraPro()` function has been added to address input-dependency of `UpdateCamera()`, now advanced users have **full control over camera inputs and movement/rotation speeds**!
- **`NEW` Support for M3D models and M3D/GLTF animations**: 3d models animations support has been a limited aspect of raylib for long time, some versions ago IQM animations were supported but raylib 4.5 also adds support for the brand new [M3D file format](https://bztsrc.gitlab.io/model3d/), including animations and the long expected support for **GLTF animations**! The new M3D file format is **simple, portable, feature complete, extensible and open source**. It also provides a complete set of tools to export/visualize M3D models from/to Blender! Now raylib supports up to **3 model file-formats with animations**: `IQM`, `GLTF` and `M3D`.
- **`NEW` Support QOA audio format (import/export)**: Just a couple of months ago the new [QOA file format](https://qoaformat.org/) was published, a very simple, portable and open source quite-ok-audio file format. raylib already supports it, added to `raudio` module and including audio loading from file, loading from memory, streaming from file, streaming from memory and **exporting to QOA** audio format. **Because simplicity really matters to raylib!**
- **`NEW` Module for compressed textures loading**: [`rl_gputex`](https://github.com/raysan5/raylib/blob/master/src/external/rl_gputex.h), a portable single-file header-only small library to load compressed texture file-formats (DDS, PKM, KTX, PVR, ASTC). Provided functionality is not new to raylib but it was part of the raylib `rtextures` module, now it has been moved into a separate self-contained library, **improving portability**. Note that this module is only intended to **load compressed data from files, ready to be uploaded to GPU**, no compression/decompression functionality is provided. This change is a first step towards a better modularization of raylib library.
- **Reviewed `rlgl` module for automatic limits checking**: Again, [`rlgl`](https://github.com/raysan5/raylib/blob/master/src/rlgl.h) has been reviewed to simplify usage. Now users do not need to worry about reaching the internal render-batch limits when they send their triangles to draw 2d/3d, `rlgl` manages it automatically! This change allows a **great simplification for other modules** like `rshapes`, `rtextures` and `rmodels` that do not need to worry about bufffer overflows and can just define as many vertex as desired!
- **Reviewed `rshapes` module to minimize the rlgl dependency**: Now `rshapes` 2d shapes drawing functions **only depend on 6 low-level functions**: `rlBegin()`, `rlEnd()`, `rlVertex3f()`, `rlTexCoord2f()`, `rlNormal3f()`, `rlSetTexture()`. With only those pseudo-OpenGl 1.1 minimal functionality, everything can be drawn! This improvement converts `rshapes` module in a **self-contained, portable shapes-drawing library that can be used independently of raylib**, as far as entry points for those 6 functions are provided by the user. It even allows to be used for software rendering, with the proper backend!
- **Added data structures validation functions**: Multiple functions have been added by @RobLoach GitHub user to ease the validation of raylib data structures: `IsImageReady()`, `IsTextureReady()`, `IsSoundReady()`... Now users have a simple mechanism to **make sure data has been correctly loaded**, instead of checking internal structure values by themselves.
As usual, those are only some highlights but there is much more! New image generators, new color transformation functionality, improved blending support for color/alpha, etc... Make sure to check raylib [CHANGELOG]([CHANGELOG](https://github.com/raysan5/raylib/blob/master/CHANGELOG)) for a detailed list of changes! Please, note that all breaking changes have been flagged with a `WARNING` in the CHANGELOG, specially useful for binding creators!
**raylib keeps improving one more version** with a special focus on maintainability and sustainability. Always working towards making the library more **simple and easy-to-use**.
It's been **7 months** since latest raylib release and **10 years** since raylib 1.0 was officially released... what an adventure! In the last 10 years raylib has improved a lot, new functions have been added, many new features and improvements implemented, up to **500 contributors** have helped to shape the library as it is today. `raylib 5.0` is the final result of all this incredible amount of work and dedication. Here is the summary with the key features and additions of this NEW major version of raylib.
Some numbers for this release:
- **+200** closed issues (for a TOTAL of **+1540**!)
- **+550** commits since previous RELEASE (for a TOTAL of **+6950**!)
- **+35** functions ADDED to raylib API (for a TOTAL of **552**!)
- **+60** functions REVIEWED/REDESIGNED
- **+80** new contributors (for a TOTAL of **+500**!)
Highlights for `raylib 5.0`:
- **`rcore` module platform-split**: Probably the biggest raylib redesign in the last 10 years. raylib started as a library targeting 3 desktop platforms: `Windows`, `Linux` and `macOS` (thanks to `GLFW` underlying library) but with the years support for several new platforms has been added (`Android`, `Web`, `Rapsberry Pi`, `RPI native`...); lot of the platform code was shared so the logic was all together on `rcore.c` module, separated by compilation flags. This approach was very handy but also made it very difficult to support new platforms and specially painful for contributors not familiar with the module, navigating +8000 lines of code in a single file. A big redesign was really needed but the amount of work required was humungous and quite scary for a solo-developer like me, moreover considering that everything was working and the chances to break things were really high. Fortunately, some contributors were ready for the task (@ubkp, @michaelfiber, @Bigfoot71) and thanks to their initiative and super-hard work, the `rcore` [platform split](https://github.com/raysan5/raylib/blob/master/src/platforms) has been possible! This new raylib architecture greatly improves the platforms maintenance but also greatly simplifies the addition of new platforms. A [`platforms/rcore_template.c`](https://github.com/raysan5/raylib/blob/master/src/platforms/rcore_template.c) file is provided with the required structure and functions to be filled for the addition of new platforms, actually it has been simplified to mostly filling some pre-defined functions: `InitPlatform()`, `ClosePlatform`, `PollInputEvents`... Undoubtedly, **this redesign opens the doors to a new era for raylib**, letting the users to plug new platforms as desired.
- **`NEW` Platform backend supported: SDL**: Thanks to the new `rcore` platform-split, the addition of new platforms/backends to raylib has been greatly simplified. As a proof of concept, [`SDL2`](https://libsdl.org/) platform backend has been added to raylib as an alternative for `GLFW` library for desktop builds: [`platforms/rcore_desktop_sdl`](https://github.com/raysan5/raylib/blob/master/src/platforms/rcore_desktop_sdl.c). Lot of work has been put to provide exactly the same features as the other platforms and carefully test the new implementation. Now `SDL2` fans can use this new backend, just providing the required include libraries on compilation and linkage (not included in raylib, like `GLFW`). `SDL` backend support also **eases the process of supporting a wider range of platforms** that already support `SDL`.
- **`NEW` Platform backend supported: Nintendo Switch (closed source)**: The addition of the `SDL` backend was quite a challenge but to really verify the robustness and ease of the new platform plugin system, adding support for a console was a more demanding adventure. Surprisingly, only two days of work were required to add support for `Nintendo Switch` to raylib! Implementation result showed an outstanding level of simplicity, with a **self-contained module** (`rcore_swith.cpp`) supporting graphics and inputs. Unfortunately this module can not be open-sourced due to licensing restrictions.
- **`NEW` Splines drawing and evaluation API**: A complete set of functions has been added to [draw](https://github.com/raysan5/raylib/blob/master/src/raylib.h#L1258) and [evaluate](https://github.com/raysan5/raylib/blob/master/src/raylib.h#L1270) different types of splines: `Linear`, `Basis`, `Catmull-Rom`, `Quadratic Bezier` and `Cubic Bezier`. Splines are extremely useful for game development (describe paths, control NPC movement...) but they can also be very useful on tools development (node-conections, elements-movement, 3d modelling, animations...). This was the missing feature on the raylib [`rshapes`](https://github.com/raysan5/raylib/blob/master/src/rshapes.h) module to make it complete! Note that `rshapes` module can also be used independently of raylib just providing the **only 6 functions required for vertex definition and drawing**.
- **`NEW` Pseudo-random numbers generator: rprand**: After several years of users asking for this missing piece, a brand new pseudo-random generator module has been added to raylib. [`rprand`](https://github.com/raysan5/raylib/blob/master/src/external/rprand.h) implements the `Xoshiro128**` algorithm combined with `SplitMix64`, specially suited for **fast software pseudo-random numbers generation**. The module also implies some useful functions to generate non-repetitive random numbers sequences, functionality exposed by raylib. usage of this module can be controlled by a compilation flag, in case the default libc `rand()` function was preferred.
- **`NEW` Automation Events System API**: This new system was first added in `raylib 4.0` as an experimental feature but it was a bit clumsy and there was no API exposed to users. For the new `raylib 5.0` the system has been redesigned and [proper API](https://github.com/raysan5/raylib/blob/master/src/raylib.h#L1135) added for the users. With this new events automation system, users can **record input events for later replay**, very useful feature for testing automation, tutorials generation, assisted game playing, in-game cinematics, speedruns saving or even AI assited game playing!
- **`NEW` [`raygui 4.0`](https://github.com/raysan5/raygui)**: The **official raylib immediate-mode gui library** designed for tools development has been updated to a new version, aligned with raylib 5.0. This new version is a complete redesign of raygui to unify all controls structure and usage, now all controls have the same function signature!. `raygui` has been battle-tested with the development of +12 published tools in the last few years. The tools can be seen and used for free in the [raylib technologies tools page](https://raylibtech.itch.io/). Worth mentioning that several of those **tools have been open sourced** for anyone to use, compile, contribute or learn how the code works.
- **`NEW` raylib web examples functionality**: Beside the addition of several new examples, the web examples functionality has been improved. Examples have been organized by [complexity level](https://www.raylib.com/examples.html), marked with one star for simple examples and up to 4 stars for more complex ones. A new option has been added to web to allow to **filter examples by function-name** usage, to ease the learning process when looking for an usage example of some function. Finally, **open-graph metadata** information has been added to all examples individual webpages, improving a the visuals and information when sharing those webpages on social networks, sharing the example screenshot and details.
As always, those are only some highlights of the new `raylib 5.0` but there is many more improvements! Support for 16-bit HDR images/textures, SVG loading and scaling support, new OpenGL ES 3.0 graphic backend, new image gradient generators, sound alias loading, improved 3d models loading, multiple optimizations, new bindings, CodeQL integration and much more!
Make sure to check raylib [CHANGELOG]([CHANGELOG](https://github.com/raysan5/raylib/blob/master/CHANGELOG)) for a detailed list of changes!
Undoubtedly, this is the **biggest raylib update in 10 years**. Many new features and improvements with a special focus on maintainability and long-term sustainability. **Undoubtedly, this is the raylib of the future**.
**Enjoy programming!** :)
notes on raylib 5.5
-------------------
One year after raylib 5.0 release, arrives `raylib 5.5`, the next big revision of the library. It's been **11 years** since raylib 1.0 release and in all this time it has never stopped growing and improving. With an outstanding number of new contributors and improvements, it's, again, the biggest raylib release to date.
Some numbers for this release:
- **+270** closed issues (for a TOTAL of **+1810**!)
- **+800** commits since previous RELEASE (for a TOTAL of **+7770**!)
- **+30** functions ADDED to raylib API (for a TOTAL of **580**!)
- **+110** functions REVIEWED with fixes and improvements
- **+140** new contributors (for a TOTAL of **+640**!)
Highlights for `raylib 5.5`:
- **`NEW` raylib pre-configured Windows package**: The new raylib **portable and self-contained Windows package** for `raylib 5.5`, intended for nobel devs that start in programming world, comes with one big addition: support for **C code building for Web platform with one-single-mouse-click!** For the last 10 years, the pre-configured raylib Windows package allowed to edit simple C projects on Notepad++ and easely compile Windows executables with an automatic script; this new release adds the possibility to compile the same C projects for Web platform with a simple mouse click. This new addition **greatly simplifies C to WebAssembly project building for new users**. The `raylib Windows Installer` package can be downloaded for free from [raylib on itch.io](https://raysan5.itch.io/raylib).
- **`NEW` raylib project creator tool**: A brand new tool developed to help raylib users to **setup new projects in a professional way**. `raylib project creator` generates a complete project structure with **multiple build systems ready-to-use** and **GitHub CI/CD actions pre-configured**. It only requires providing some C files and basic project parameters! The tools is [free and open-source](https://raysan5.itch.io/raylib-project-creator), and [it can be used online](https://raysan5.itch.io/raylib-project-creator)!.
- **`NEW` Platform backend supported: RGFW**: Thanks to the `rcore` platform-split implemented in `raylib 5.0`, **adding new platforms backends has been greatly simplified**, new backends can be added using provided template, self-contained in a single C module, completely portable. A new platform backend has been added: [`RGFW`](https://github.com/raysan5/raylib/blob/master/src/platforms/rcore_desktop_rgfw.c). `RGFW` is a **new single-file header-only portable library** ([`RGFW.h`](https://github.com/ColleagueRiley/RGFW)) intended for platform-functionality management (windowing and inputs); in this case for **desktop platforms** (Windows, Linux, macOS) but also for **Web platform**. It adds a new alternative to the already existing `GLFW` and `SDL` platform backends.
- **`NEW` Platform backend version supported: SDL3**: Previous `raylib 5.0` added support for `SDL2` library, and `raylib 5.5` not only improves SDL2 functionality, with several issues reviewed, but also adds support for the recently released big SDL update in years: [`SDL3`](https://wiki.libsdl.org/SDL3/FrontPage). Now users can **select at compile time the desired SDL version to use**, increasing the number of potential platforms supported in the future!
- **`NEW` Retro-console platforms supported: Dreamcast, N64, PSP, PSVita, PS4**: Thanks to the platform-split on `raylib 5.0`, **supporting new platform backends is easier than ever!** Along the raylib `rlgl` module support for the `OpenGL 1.1` graphics API, it opened the door to [**multiple homebrew retro-consoles backend implementations!**](https://github.com/raylib4Consoles) It's amazing to see raylib running on +20 year old consoles like [Dreamcast](https://github.com/raylib4Consoles/raylib4Dreamcast), [PSP](https://github.com/raylib4Consoles/raylib4Psp) or [PSVita](https://github.com/psp2dev/raylib4Vita), considering the hardware constraints of those platforms and proves **raylib outstanding versability!** Those additional platforms can be found in separate repositories and have been created by the amazing programmer Antonio Jose Ramos Marquez (@psxdev).
- **`NEW` GPU Skinning support**: After lots of requests for this feature, it has been finally added to raylib thanks to the contributor Daniel Holden (@orangeduck), probably the developer that has further pushed models animations with raylib, developing two amazing tools to visualize and test animations: [GenoView](https://github.com/orangeduck/GenoView) and [BVHView](https://github.com/orangeduck/BVHView). Adding GPU skinning was a tricky feature, considering it had to be **available for all raylib supported platforms**, including limited ones like Raspberry Pi with OpenGL ES 2.0, where some advance OpenGL features are not available (UBO, SSBO, Transform Feedback) but a multi-platform solution was found to make it possible. A new example, [`models_gpu_skinning`](https://github.com/raysan5/raylib/blob/master/examples/models/models_gpu_skinning.c) has been added to illustrate this new functionality. As an extra, previous existing CPU animation system has been greatly improved, multiplying performance by a factor (simplifiying required maths).
- **`NEW` [`raymath`](https://github.com/raysan5/raylib/blob/master/src/raymath.h) C++ operators**: After several requested for this feature, C++ math operators for `Vector2`, `Vector3`, `Vector4`, `Quaternion` and `Matrix` has been added to `raymath` as an extension to current implementation. Despite being only available for C++ because C does not support it, these operators **simplify C++ code when doing math operations**.
Beside those new big features, `raylib 5.5` comes with MANY other improvements:
- Normals support on batching system
- Clipboard images reading support
- CRC32/MD5/SHA1 hash computation
- Gamepad vibration support
- Improved font loading (no GPU required) with BDF fonts support
- Time-based camera movement
- Improved GLTF animations loading
...and [much much more](https://github.com/raysan5/raylib/blob/master/CHANGELOG), including **many functions reviews and new functions added!**
Make sure to check raylib [CHANGELOG](https://github.com/raysan5/raylib/blob/master/CHANGELOG) for a detailed list of changes!
To end with, I want to **thank all the contributors (+640!**) that along the years have **greatly improved raylib** and pushed it further and better day after day. Thanks to all of them, raylib is the amazing library it is today.
Last but not least, I want to thank **raylib sponsors and all the raylib community** for their support and continuous engagement with the library, creating and sharing amazing raylib projects on a daily basis. **Thanks for making raylib a great platform to enjoy games/tools/graphic programming!**
**After 11 years of development, `raylib 5.5` is the best raylib ever.**
**raylib is a simple and easy-to-use library to enjoy 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 and it's especially well suited for prototyping, tooling, graphical applications, embedded systems and education.
*NOTE for ADVENTURERS: raylib is a programming library to enjoy videogames programming; no fancy interface, no visual helpers, no debug button... just coding in the most pure spartan-programmers way.*
@ -12,53 +12,50 @@ Ready to learn? Jump to [code examples!](https://www.raylib.com/examples.html)
[](https://github.com/raysan5/raylib/commits/master)
[](https://github.com/raysan5/raylib/commits/master)
- Shaders support, including model shaders and **postprocessing** shaders
- **Powerful math module** for Vector, Matrix and Quaternion operations: [raymath](https://github.com/raysan5/raylib/blob/master/src/raymath.h)
- Audio loading and playing with streaming support (WAV, OGG, MP3, FLAC, XM, MOD)
- Audio loading and playing with streaming support (WAV, QOA, OGG, MP3, FLAC, XM, MOD)
- **VR stereo rendering** support with configurable HMD device parameters
- Huge examples collection with [+120 code examples](https://github.com/raysan5/raylib/tree/master/examples)!
- Bindings to [+50 programming languages](https://github.com/raysan5/raylib/blob/master/BINDINGS.md)!
- **Free and open source**.
- Huge examples collection with [+140 code examples](https://github.com/raysan5/raylib/tree/master/examples)!
- Bindings to [+70 programming languages](https://github.com/raysan5/raylib/blob/master/BINDINGS.md)!
- **Free and open source**
basic example
--------------
This is a basic raylib example, it creates a window and it draws the text `"Congrats! You created your first window!"` in the middle of the screen. Check this example [running live on web here](https://www.raylib.com/examples/core/loader.html?name=core_basic_window).
This is a basic raylib example, it creates a window and draws the text `"Congrats! You created your first window!"` in the middle of the screen. Check this example [running live on web here](https://www.raylib.com/examples/core/loader.html?name=core_basic_window).
```c
#include "raylib.h"
@ -85,7 +82,7 @@ build and installation
raylib binary releases for Windows, Linux, macOS, Android and HTML5 are available at the [Github Releases page](https://github.com/raysan5/raylib/releases).
raylib is also available via multiple [package managers](https://github.com/raysan5/raylib/issues/613) on multiple OS distributions.
raylib is also available via multiple package managers on multiple OS distributions.
#### Installing and building raylib on multiple platforms
@ -116,7 +113,7 @@ learning and docs
raylib is designed to be learned using [the examples](https://github.com/raysan5/raylib/tree/master/examples) as the main reference. There is no standard API documentation but there is a [**cheatsheet**](https://www.raylib.com/cheatsheet/cheatsheet.html) containing all the functions available on the library a short description of each one of them, input parameters and result value names should be intuitive enough to understand how each function works.
Some additional documentation about raylib design can be found in raylib GitHub Wiki. Here are the relevant links:
Some additional documentation about raylib design can be found in [raylib GitHub Wiki](https://github.com/raysan5/raylib/wiki). Here are the relevant links:
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) for further details.
raylib uses internally some libraries for window/graphics/inputs management and also to support different file formats loading, all those libraries are embedded with and are available in [src/external](https://github.com/raysan5/raylib/tree/master/src/external) directory. Check [raylib dependencies LICENSES](https://github.com/raysan5/raylib/wiki/raylib-dependencies) on raylib Wiki for details.
raylib uses internally some libraries for window/graphics/inputs management and also to support different file formats loading, all those libraries are embedded with and are available in [src/external](https://github.com/raysan5/raylib/tree/master/src/external) directory. Check [raylib dependencies LICENSES](https://github.com/raysan5/raylib/wiki/raylib-dependencies) on [raylib Wiki](https://github.com/raysan5/raylib/wiki) for details.
Here it is a wishlist with features and ideas to improve the library. Note that features listed here are usually long term improvements or just describe a route to follow for the library. There are also some additional places to look for raylib improvements and ideas:
Here is a wishlist with features and ideas to improve the library. Note that features listed here are usually long term improvements or just describe a route to follow for the library. There are also some additional places to look for raylib improvements and ideas:
- [GitHub Issues](https://github.com/raysan5/raylib/issues) has several open issues for possible improvements or bugs to fix.
- [GitHub PRs](https://github.com/raysan5/raylib/pulls) open with improvements to be reviewed.
- [raylib source code](https://github.com/raysan5/raylib/tree/master/src) has multiple *TODO* comments around code with pending things to review or improve.
- raylib wishlists discussions (https://github.com/raysan5/raylib/discussions/1502, https://github.com/raysan5/raylib/discussions/2272) are open to everyone to ask for improvements, feel free to check and comment.
- raylib wishlists discussions are open to everyone to ask for improvements, feel free to check and comment:
Examples using raylib textures functionality, including image/textures loading/generation and drawing, provided by raylib [textures](../src/textures.c) module.
Examples using raylib textures functionality, including image/textures loading/generation and drawing, provided by raylib [textures](../src/rtextures.c) module.
| ## | example | image | difficulty<br>level | version<br>created | last version<br>updated | original<br>developer |
Examples using raylib text functionality, including sprite fonts loading/generation and text drawing, provided by raylib [text](../src/text.c) module.
Examples using raylib text functionality, including sprite fonts loading/generation and text drawing, provided by raylib [text](../src/rtext.c) module.
| ## | example | image | difficulty<br>level | version<br>created | last version<br>updated | original<br>developer |
Examples using raylib shaders functionality, including shaders loading, parameters configuration and drawing using them (model shaders and postprocessing shaders). This functionality is directly provided by raylib [rlgl](../src/rlgl.c) module.
| ## | example | image | difficulty<br>level | version<br>created | last version<br>updated | original<br>developer |
Examples using raylib audio functionality, including sound/music loading and playing. This functionality is provided by raylib [raudio](../src/raudio.c) module. Note this module can be used standalone independently of raylib, check [raudio_standalone](others/raudio_standalone.c) example.
Examples using raylib audio functionality, including sound/music loading and playing. This functionality is provided by raylib [raudio](../src/raudio.c) module. Note this module can be used standalone independently of raylib.
| ## | example | image | difficulty<br>level | version<br>created | last version<br>updated | original<br>developer |
Examples showing raylib misc functionality that does not fit in other categories, like standalone modules usage or examples integrating external libraries.
| ## | example | image | difficulty<br>level | version<br>created | last version<br>updated | original<br>developer |
#ifdef PLATFORM_WEB // NOTE: On web platform for some reason the PollInputEvents only works after the inputs check, so just call it after check all your inputs (on web)
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.