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
When file extension is longer or equal length compared to buffer holding lowercased string, strncpy does not null terminate the string.
Increased buffer size by 1 to ensure it will always be null-terminated, so that following strcmp does not read out of buffer bounds.
This truncation causes text that spans the zero coord boundary to round differently left or zero vs. right of zero, in turn causing letters to appear squished together. If you actually need the position to be an integer, you should instead `floorf()` the float, rather than doing an integer truncation, but I don't see any reason to convert it to an integer in the first place. Everything else in the equation is a float.
GetMusicTimePlayed() was calculated using buffered frames, not played frames.
For example: calling LoadMusicStream->UpdateMusicStream->GetMusicTimePlayed would return non-zero value, even though no music was playing.
This file requires manual maintenance and continuous review, it also changes from day to day moving sponsors from present-to-past and sometimes the other way round.
GitHub already lists the sponsors on the user profile, in a better an more visual way.
I also have doubts this should be a document distributed with raylib sources...
This PR fixes a bug when music.looping is set to false but the music continues looping.
Also using proper functions to seek to start of an audio file.
Removed old comment.
ISSUE: Front buffer and backbuffer have different clear colors, if no `ClearBackground()` is called by user, there is screen flickering on buffers swap.
It's up to the user to call `ClearBackground()` if desired
Just reviewed font atlas size estimation, now it considers `fontSize` instead of `chars[i].image.height`, increasing considerably the atlas size estimation.
Reviewed some camera functionality:
- Reviewed camera swinging (up-down movement)
- Reviewed camera tilting (left-right movement)
- Make movement independent of frame-rate
- removed unneeded variables
NOTE: Camera rotation has some speed issues on first person when fixed 60 fps are used: it moves too fast. Independent framerate movement is not properly implemented.
* test if clang supports multiple targets
* didnt work, so trying lipo to join separate targets together
* add CUSTOM_LDFLAGS to try to fix arm64 mac dynamic build
* fix sym links
* try again to fix sym links
* auto extract raylib version numbers from makefile
* fix macos missing gnu grep
* dont use custom name for raylib dlls
Those functions were platform dependent and user has no control over the file created. They have been removed from raylib and just moved to `core_storage_values` example.
REDESIGNED: `LoadDirectoryFiles()`
ADDED: `LoadDirectoryFilesEx()`
REDESIGNED: `LoadDroppedFiles()`
ADDED: `IsPathFile()`
This BIG BREAKING change simplifies the functions and gives more control to the user:
- A new `struct FilePathList` has been added to avoid exposing complex pointers.
- User is responsible of memory loading/unloading
- Filepaths loading support recursive directories and file extension filters
* Fix parser function description detection
Some functions in easings.h are defined on a single line and include a
division which was mistaken for the start of the description.
* Fix parser detection of macros including spaces
* Add support for self-referencing structs to parser
* Fix parser code style
* Fix parser handling of multiple fields on one line
* Increase parser MAX_STRUCT_FIELDS
For internal rlglData State struct (internal structs are still not
supported but this makes it less wrong).
* Add description helper to parser
* Regenerate parser output
* Add cakkbacks to parser
* Regenerate parser output
* Refactor funcLines to be an array of line numbers
It used to be an array of pointers into the text buffer but was changed
to be an array of pointers to the lines. Now it is an array of line
numbers like the others.
* Fix code style
* Move array size from name to type
* Regenerate parser output
* Augment raymath.h with useful functions
* Rename Vector2ClampMagnitude and Vector3ClampMagnitude to Vector2ClampValue and Vector3ClampValue
* Remove Vector3{Up,Down,Left,Right,Forward,Backward}
WARNING: This addition is based on a PR and it's still under review, not sure if it will be maintained in the future. In general, raylib tries to avoid callbacks usage mechanisms.
This is a tiny change that makes code in src/rtextures.c "fold"
correctly in editors/IDE's by matching the number of opening
parenthesis to closing parenthesis. One of those editors is Emacs ;-)
As prior commit, but complete fix for XBox controller and trigger
buttons too.
> The joystick range is a float from -1 through +1. Casting this to int
> yields only three possible values: -1, 0, and 1. This gives a
> misleading joystick placement in the demo.
>
> By casting to int after the multiplication to get pixel values, the
> demo reveals the analog feel of the joystick.
The joystick range is a float from -1 through +1. Casting this to int
yields only three possible values: -1, 0, and 1. This gives a
misleading joystick placement in the demo.
By casting to int after the multiplication, the demo reveals the
analog feel of the joystick.
* Fixed an issue when using raygui and physac on unix systems
hash "#" is single-line comment character in bash so echo ignores #include and #define
* tab fix
We can figure out the source file location based on the location of the
build.zig file. No need to require the library user to specify where
raylib is stored.
GNU make on Windows first tries to find sh.exe on the path,
and will execute build rules using it if it is present.
The make clean target uses the builtin cmd.exe command del, which
won't work under sh.exe
The reason this is not done for the entire Makefile is because it would
break cross-compilation of raylib.
- Adds a new OS clause to build.zig for the BSDs
- Tested on my FreeBSD box using https://github.com/Not-Nik/raylib-zig
- All demos build and render just fine. Nice !
* added defines to parser
* added value and description for defines in parser
* parser: fixed lua defines output, fixed makefile for raygui, added LONG type for defines
* parser defines: remove postfix for LONG/FLOAT, support for hexadecimal consts, convert hex ints to decimal for JSON output
* removed defines from raylib_apis
This fixes compilation and linking errors when CUSTOMIZE_BUILD is
ON. Any option wasn't actually applied if it wasn't in this list.
I also added a message which makes it a bit easier to confirm you have
successfully enabled an option.
This fixes compilation and linking errors when CUSTOMIZE_BUILD is
ON. Any option wasn't actually applied if it wasn't in this list.
I also added a message which makes it a bit easier to confirm you have
successfully enabled an option.
* Start 2d lights example.
* finish example
* update image.
* Cleanup render textures
* Fixes to handle shadows on edges that are near to the light better.
* tabs
* move to shapes
Co-authored-by: Jeffery Myers <JefMyers@blizzard.com>
* Add panning to raudio and update audio_raw_stream example.
* remove pan smoothing, code formatting changes following pull request comments
Co-authored-by: Ray <raysan5@gmail.com>
* Fix formating problems with GetApplicationDir.
Don't ever return an empty string
* always return a valid path even if it's ./
* remove the need for the dll and just use the normal GetModuleFileName function
* Fixed Compiling Raylib for android Using cmake
* improved the cmake config for android so it don't conflict
* improved the cmake config for android so it don't conflict
The previous implementation somewhat break the expected behaviour for games and examples when pressing the `Fullscreen` button in the provided `shell.html`.
Just reverted for the moment for further investigation.
Justification: original comment said the following
"TODO: Add other platforms. Remove sudo requirement, i.e. add USER mode."
For the other platforms part, installing is included on unix-like
systems, so for example Windows doesn't have a path where to install
libraries.
Removing the requirement for sudo is also quite contradictory since
we're writing files to directories which require root. Not sure what the
original commiter meant by USER mode.
* Parse enum descriptions and value descriptions
* Put braces on newline
* Properly escape strings
* Realise that XML doesn't actually need backslash escapes
* Replace FPrintfEscapes with EscapeBackslashes
* Remove #include <stdarg.h>
* Update EscapeBackslashes description
Allow to choose which modules are compiled with raylib, if some modules are excluded from compilation, required functionality is not available but smaller builds are possible.
- All variables are initialized on declaration, some arrays were not properly initialized
- Static array buffers require memset() for re-initialization on every function call
* new models_magicavoxel_loading example
* Portable header-only file "magicavoxel_loader.h" for MagicaVoxel loader example.
* models_magicavoxel_loading example added to CMakeLists.txt and Makefile
* fix models_magicavoxel_loading example for linux.
* * vox_loader into "src/external/vox_loader.h"
* vox file support for "models.c"
* updated example "models/models_magicavoxel_loading.c"
* * Fix Vox_FreeArrays (removed memory leak)
* * removed magicavoxel_loader.h
* * Revert vs2019 solution
* * vox_loader.h -> Support custom memory allocators
* vox_loader.h -> Reverse Y<>Z for left to right handed system
* models/models_magicavoxel_loading.c -> fix model center
* * vox_loader.h -> Removed Raylib dependencies
* * Changed Vox_LoadFileName to Vox_LoadFromMemory
* VS2019 models_mesh_magicavoxel_loading.vcxproj added
* vs2019 project rename models_loading_vox
* Add zig buildfile for examples.
- `zig build` to compile all examples
- `zig build [module]` to compile all examples for a module (e.g. `zig build core`)
- `zig build [example]` to compile _and run_ a particular example (e.g. `zig build core_basic_window`)
You can use `-Dtarget=` to compile for a non-native platform, such as
`zig build -Dtarget=x86_64-windows-gnu` to compile from Linux to
Windows.
* Skip pthread example on Windows.
* Select appropriate lib file based on target.
* Add DrawCylinderEx and DrawCylinderWiresEx
* Modify examples/models/models_geometric_shapes.c to show the
usage of DrawCylinder(Wires)Ex
* Simplified DrawCylinder and DrawCylinderWires to use the -Ex versions.
* This reverts commits f49b2598dd and
4542b32e4e.
* Fixed formatting.
Renamed base_angle to baseAngle.
Remove most of the raymath.h calls.
* Added check for empty cylinder.
* Added check for empty cylinder.
* Fix bug.
Co-authored-by: Horrowind <you@example.com>
* Add DrawCylinderEx and DrawCylinderWiresEx
* Modify examples/models/models_geometric_shapes.c to show the
usage of DrawCylinder(Wires)Ex
* Simplified DrawCylinder and DrawCylinderWires to use the -Ex versions.
* This reverts commits f49b2598dd and
4542b32e4e.
* Fixed formatting.
Renamed base_angle to baseAngle.
Remove most of the raymath.h calls.
Co-authored-by: Horrowind <you@example.com>
raylib was using `stb_perlin.h` library to generate perlin noise, it seems that recently this library has been flagged as it could be infringing some algorythm patent. For security, it has been removed from raylib.
`RLGL.State.vertexCounter` is a generic counter and it's reused for all `rlRenderBatch`, actually, once render batch is filled, required vertex count is provided through the draw calls, so, the total accumulated count of vertices is not directly registered inside the rlRenderBatch.
`RLGL.State.vertexCounter` keeps that count but one possible improvement(?) could be moving the `vertexCounter` inside `rlRenderBatch` to always keep a register of the total accumulated vertices in that batch (despite that info is provided by the accumulated `draws[i].vertexCount`.
Simplifying, `RLGL.State.vertexCounter = SUM(draws[i].vertexCount)`
The decision to move the counter out of `rlVertexBuffer` is to keep only the data that I think should belong to `rlVertexBuffer` and make it more generic, aligned with raylib `Mesh` structure.
The decision to not add it to `rlRenderBatch` is because it could contain multiple `rlVertexBuffer` and it would be confusing (because it would only register the count of the last filled one).
Instead of registering vertex texcoords and colors on every call, we keep the last defined value and we record everything on `glVertex*()`. Actually that behavior is aligned with OpenGL 1.1 standard.
* [rcore] fix rpi4 Failed to get DRM resources
card1 is not always the the correct card to use on rpi4
rpi os finds the correct card and links it to /dev/dri/by-path/platform-gpu-card during boot.
this fix makes sure that we always point to the correct card on rpi4
* Update rcore.c
* Match build-windows.bat changes
The location for manual setting of the vcvarsall.bat location moved to line 38 in the latest change.
* Update flags for clean x64/x86 building
std:c11 is required for initialization features used in raylib. UTF-8 for consistency in contemporary systems. /W3 gets rid of puzzling slack byte and linker in-lining warnings. /sdl for some insecure library usages in the user code that beginners should learn about early.
* 2021-10-01 core_basic_windows.c adjustment
1. The press F6 message and the placement of the compiled executable statement are incorrect for the scripts case.
2. <raylib.h> because "raylib.h" is meaningful only when compiling inside raylib/src/ folder.
3. main(void) to get rid of a novice-confusing warning.
* Supress most warnings on rmodels.c
NOTE: unused symbols have been deleted and the following report will show in what location they were previously.
Unused symbols:
- ArrayInt - vox_loader.h: line 84
- initArrayInt - vox_loader.h: line 168
- insertArrayInt - vox_loader.h: line 175
- freeArrayInt - vox_loader.h: line 186
- offsetX, offsetY, offsetZ - vox_loader.h: line 610
- chunkTotalChildSize - vox_loader.h: line 623
Other warnings:
- initialization discards 'const' qualifier - vox_loader.h: line 572
- incompatible types for VoxVector3 and Vector3 - rmodels.c: line 5748
- incompatible types for VoxColor and Color - rmodels: line 5749
* Remove ToVector3 and ToColor functions and assign values directly
CONVENTIONS:
- Functions are always self-contained, no function use another raymath function inside, required code is directly re-implemented inside
- Functions input parameters are always received by value
- Functions use always a "result" variable for return
- Functions are always defined inline
- Angles are always in radians (DEG2RAD/RAD2DEG macros provided for convenience)
* Match build-windows.bat changes
The location for manual setting of the vcvarsall.bat location moved to line 38 in the latest change.
* Update flags for clean x64/x86 building
std:c11 is required for initialization features used in raylib. UTF-8 for consistency in contemporary systems. /W3 gets rid of puzzling slack byte and linker in-lining warnings. /sdl for some insecure library usages in the user code that beginners should learn about early.
* Fixed gltf missing transforms on load
mend
* extracted Matrix calculation in to static method and added skinning check
* fixed formatting
* Fixed write to access to nullptr when animation has no normals
* Refactored UpdateModelAnimation to only update changed vertices when needed (allows for multi animation playing)
* add check for models that were missed during BindGLTFPrimitiveToBones to not segfault the program
* fixed id mismatch between animation and model
* draft on fixing the mesh to skin mapping
* dont look at this
* removing debug info
LoadModelAnimations takes an `int` for the animation count parameter.
The animation count should never be negative, so it makes sense to
specify it as unsigned in the API. This matches the API for
UnloadModelAnimations, which expects an unsigned int. Both GLTF and IQMM
also store the animation count internally as unsigned, and we were
casting to a signed int for no reason.
GLTF actually uses `size_t` internally, so we're technically risking
overflow, but having 2^32 animations seems unlikely.
raylib modules have been slightly renamed to add some identity and note that they are independent modules that can be used as standalone separate parts of raylib if required.
The renamed modules are:
- `core` -> `rcore`
- `shapes` -> `rshapes`
- `textures` -> `rtextures`
- `text` -> `rtext`
- `models` -> `rmodels`
- `camera` -> `rcamera`
- `gestures` -> `rgestures`
- `core` -> `rcore`
All the build systems has been adapted to this change.
Specifying a fixed seed for the random number generator is often
used in games for various reasons.
By adding an api function for seeding the random number generator
we solve two different problems regarding the seeding:
1) The underlying RNG implementation does not leak to client code
(as would be the case if we called srand directly from the
client code)
2) Seeding the RNG would be simple from other programming languages
(especially in cases where calling libc functions is non-trivial)
* new models_magicavoxel_loading example
* Portable header-only file "magicavoxel_loader.h" for MagicaVoxel loader example.
* models_magicavoxel_loading example added to CMakeLists.txt and Makefile
* fix models_magicavoxel_loading example for linux.
* * vox_loader into "src/external/vox_loader.h"
* vox file support for "models.c"
* updated example "models/models_magicavoxel_loading.c"
* * Fix Vox_FreeArrays (removed memory leak)
* * removed magicavoxel_loader.h
* * Revert vs2019 solution
* * vox_loader.h -> Support custom memory allocators
* vox_loader.h -> Reverse Y<>Z for left to right handed system
* models/models_magicavoxel_loading.c -> fix model center
* * vox_loader.h -> Removed Raylib dependencies
* * Changed Vox_LoadFileName to Vox_LoadFromMemory
* new models_magicavoxel_loading example
* Portable header-only file "magicavoxel_loader.h" for MagicaVoxel loader example.
* models_magicavoxel_loading example added to CMakeLists.txt and Makefile
* fix models_magicavoxel_loading example for linux.
* * vox_loader into "src/external/vox_loader.h"
* vox file support for "models.c"
* updated example "models/models_magicavoxel_loading.c"
* * Fix Vox_FreeArrays (removed memory leak)
* * removed magicavoxel_loader.h
* * Revert vs2019 solution
* Fix tcc not finding emmintrin.h
This allows to compile raylib with tcc with no errors.
* Remove __TINYC__ check from stb_image.h
This will be placed under textures.c
* Move tcc check to textures.c
Avoiding to change stb_image.h
This is a big change for optimization and a more professional understanding of audio. Instead of dealing with samples, now we deal with frames, like miniaudio does, so, avoiding continuous conversions from samples to frames.
Note that `extern "C"` calling convention only affects objects that need to be seen by the linker, in our case only functions... but it would also be required by global variables exposed, if any.
This commit introduces some breaking changes for library consistency, hopefully not too dramatic... Here the full list:
- RENAMED: struct `CharInfo` to `GlyphInfo`, actually that's the correct naming for the data contained. It contains the character glyph metrics and the glyph image; in the past it also contained rectangle within the font atlas but that data has been moved to `Font` struct directly, so, `GlyphInfo` is a more correct name.
- RENAMED: `CodepointToUtf8()` to `CodepointToUTF8()`, capitalization of UTF-8 is the correct form, it would also require de hyphen but it can be omitted in this case.
- RENAMED: `TextToUtf8()` to `TextCodepointsToUTF8` for consistency and more detail on the functionality.
- ADDED: `GetGlyphInfo()` to get glyph info for a specific codepoint
- ADDED: `GetGlyphAtlasRec()` to get glyph rectangle within the generated font atlas
- Some additional tweaks for consistency
- DrawTextRec() and DrawTextRecEx() have been moved to example, those functions could be very specific depending on user needs so it's better to give the user the full source in case of special requirements instead of allowing a function with +10 input parameters.
When building a shared Raylib library on Linux, the build process
produces 3 files: libraylib.so (symlink), libraylib.so.381 (symlink)
and libraylib.so.3.8.1 (the library).
Only the first one of these (.so) is currently ignored by Git.
Adding *.so.* to .gitinore makes Git ignore the rest of them as
well.
I think it is useful to know what the empty behavior is in cases where
you are enumerating key presses (e.g. implementing "press any key to
continue").
* Fix Makefile to build WASM examples.
- Add --preload-file flag before specifying the resource dir
- Add empty resource dir to `shapes/` (otherwise wasm-ld will fail)
- Add wasm outputs to .gitigore
* Delete .gitignore
Co-authored-by: Ray <raysan5@gmail.com>
Now rlgl uses the `Matrix` type, just make sure it has been previously defined somewhere... I don't like this approach but it's probably the easier one for the users... still looking for a better solution... maybe using something like
`#define MATRIX_TYPE`, so it can be checked in other modules.
rlgl has been redesigned to avoid any dependency to `raylib` or `raymath`, all functions using some of those libs have been reviewed.
- REMOVED: `Texture2D`, `Shader` structs dependency
- REMOVED: `Vector3`, `Matrix` structs dependency
- REMOVED: raymath functions dependency, all required math is implemented in rlgl
- ADDED: `rlMatrix` custom rlgl type
- ADDED: `utils.c`: `rlMatrixFromMatrix()` and `rlMatrixToMatrix()` for a safe conversion between raylib<->rlgl matrix types
- ADDED: `rl` prefix to all `rlgl` structs
- Other small tweaks here and there
* Implemented remaining 7/8 of ImageDrawLine
The existing code was correct for one octant, it now works for all 8
Added two internal functions, _ImageDrawLineHorizontal and _ImageDrawLineVertical, whithout which it would've been 4 times as much code.
* ImageDrawLine: Replaced 3 functions with 1
Removed both freshly added internal functions
Crammed it all into one
* ImageDrawLine shortened significantly using maths
Substituted X and Y, then wrote one abstract loop instead of 4 specific loops.
Lots of comments to explain what I'm doing for future maintainers.
* Now conforms with style conventions
Also reworded a comment to sound more... fomal.
After lot of investigation, I'm afraid I'm removing official UWP support from raylib, I'll keep the current implementation in a separate branch (UWP), just in case. It seems Microsoft is trying to replace UWP in the long term, they announced lack of support for the new WinUI 3 and they seem to be moving to Windows App SDK.
Also, on current implementation, the code is divided between raylib and the example, requiring multiple callback hooks, making it difficult to follow and maintain.
And realistically speaking, raylib is probably not the best option for anyone willing to target UWP, neither Xbox consoles.
* Added my own model and license to Raylib exclusively created by me and provided for use in the examples (and other projects if anyone decides to)
* Use animation vertices on initial load if possible.
* Added girl model to model example
* Revamped GLTF model loading as it was wrong by default. Also updated some comments.
GLTF models were loaded only by mesh but they should be loaded recursively by hierarchical nodes because tehre are some static node transformations that are to be applied to the vertices. It also resulted in more meshes being included in some models.
It is the correct way of loading GLTF and what is suggested in the official examples.
Currenlty limiting to only one scene but more can be included later.
* Refactored the new names and structure of extracted functions.
* Safer and easier read value.
* Made reading easier for accessor->bufferView->buffer in GLTF.
Now there is no need to check for supported types or anything.
* Correct inclusion of limits.h in the cases of MSVC based compilers vs the world
* Removed weird example file
- the shader.locs now match the LoadShader function
Without this change, the lighting sample looks incorrect when
using LoadShaderFromMemory
Co-authored-by: Ruminant <psp5150+git@gmail.com>
RENAMED: GetCodepoints() -> LoadCodepoints(), now codepoint array data is loaded dynamically instead of reusing a limited static buffer.
ADDED: UnloadCodepoints() to safely free loaded codepoints
RENAMED: GetNextCodepoint() -> GetCodepoint()
* core: added `GetMouseDelta()`
Thanks to previousPosition added by raysan it is now possible to create the GetMouseDelta() function.
Returns a Vector2 with the difference between the current and previous position of the mouse in a frame.
Useful for creating camera scrolling, among others.
* Added changes noted by raysan
Added missing null terminator when adding characters to the string, otherwise garbage values are read (often zeros which are equal to '\0', but not every time).
This error results in random characters appearing in the text box every one in a while:
```
asdfg??? ll??
```
It is corrected with the proposed fix.
This problem was observed by my student, Gonzalo Rivera Lazo.
output->framePoses[frame] is over-allocated.
framePoses is a 2D array:
- first dimension: frames (allocated l. 4717)
- second dimension: nodes (allocated l. 4731)
Second dimension should be allocated of nodes_count transformations only.
* Hotfix for glitchy camera
Super small fix that was causing the camera to glitch every x amount of seconds/pixels. Works much better now, 3/4 lines changed.
* fixed dumb visual studio formatting problems
* Typo fix
Changed "bsasic" to "basic" in the comments.
* Added pixel-perfect camera example
Added pixel-perfect camera example, both the .c file and the cover .png image. The example works with any resolution you want, as long as the ratio stays the same
(ex. 16:9, 4:3) ecc.
* Fixed Typecasts
Fixed compiler errors (implicit conversions)
* Precomputed rectangles, time-based movement and whitespace fix
Moved the source and destination rectangles for the renderTexture into their own variables, modified the animation to be time-based instead of frame-based, fixed the bug with whitespaces.
* Fixed spacing and added more consistency with sinf() and cosf()
* Fixed *= operator spacing
Updated to fix versioning and linking issues.
Old version would cause examples to not be linked on fresh raylib install or linked with an old library version on updated raylib install.
On PLATFORM_ANDROID, PLATFORM_RPI, PLATFORM_DRM and PLATFORM_UWP glfwGetProcAddress() is not defines, actually those platforms use egl platform windowing system.
* Added an example for raylib OpenGL interop.
* Removed C99 variable-length array to fix MSVC errors
* Moved the opengl interop example from shaders to others.
- Found testing core_input_gamepad. The last axis was not drawn.
- GLFW_GAMEPAD_AXIS_LAST is defined to the last axis which is 5
not the total number which is 6.
After some investigation, I came to the conclusion it's impossible to get a solution that works for all situations. Fullscreen mode on web depends on the browser, the canvas and also the desired scaling strategy of the user. Just choose a solution that fits me needs for now and let the user manage the canvas on their webs (hopefully not requiring ToggleFullscreen() call).
Also removed several useless related callbacks.
* CheckCollisionPointTriangle
* New feature proposal to existing collision detection routines.
It checks if point [point] belongs to line created between two points [p1] and [p2] with defined margin in pixels[threshold].
1693
* adds DrawTexturedPoly with example
* the actual example ... ahem
* moved DrawTexturePoly to textures function and example
NB function name changed to fit with other DrawTextureXXX functions
(no "d" )
Co-authored-by: codifies <you@example.com>
- The vertices did not map to where I expected causing rotation to be
off by 90 degrees. I reorganized the vertices making it easier to
reason about which fixes this.
- The order for drawing is now topLeft, bottomLeft, bottomRight,
topRight.
The Raylib root Makefile for PLATFORM=PLATFORM_WEB is assumed to
run in Windows environments, which makes it incorrectly set the
PATH variable, so Linux (and possibly other) environments are not
able to find binaries from EMSDK_PATH.
Fix this by checking which PLATFORM_OS and configure PATH
accordingly.
- Many functions renamed to follow rl*() convention
- Some internal functions exposed in the API
- Some functionality moved to other modules
- Reorganized all functions by categories
- Make sure it keeps working with OpenGL 1.1 and 2.1
* Add loop functions for music files.
Tell xm tracker to loop tracker when loop state changes.
Don't let looped xm tracker streams restart, they are infinite
Use modulo to make time tracker for xm looped streams work correctly.
* Remove loop functions, set XM loop in update based on flag.
Formatting cleanups.
Co-authored-by: Jeffery Myers <JefMyers@blizzard.com>
* Init MinAudio to a sample rate of 0 to let the device pick the rate.
Read the rate from the device after it starts up.
Convert AUDIO_DEVICE_SAMPLE_RATE from a #def into an int, that is set from the device's rate
Set all sample systems to use the AUDIO_DEVICE_SAMPLE_RATE as the target rate to minimize resampling.
* use device sample rate instead of separate var
let config define a device sample rate if it wants to, but let the default be 0 for native rate.
* Don't use fixed sample rates for tracker files.
Remove config default audio buffer size and replace with a function that computes one for a reasonable frame rate at the output sample rate.
Vr simulator has been moved to core module and completely redesigned. Now user is in charge of stereo-render fbo and also in full control of distortion shader. Code is a bit more complex but better aligned with other raylib examples.
* Optimize DrawTexturePro and DrawRectanglePro transformations
- Add check so rotation is only applied if rotation != 0.0f.
- Replace matrix usage by calculating the vertex data directly.
* Fix error with windows build and trim whitespace
* Implement a load values from accessor function.
Added some more value types for the different GLTF attributes.
Fixed crash when loading animated triangle.
* Split GLTF model loading into separate functions for readability.
* Fixed the already working models that I broke when introducing GLTFReadValue.
Improved the example for gltf models to be able to switch between a few models.
* Removed license from screen. It is pu inside a license file anyway.
* Small improvements on the naming of functions
Removed (*model). and replaced it with model->
Some enums values have been renamed to be more consistent and also provide a more detailed description:
- ShaderLocationIndex: LOC_VERTEX_POSITION -> SHADER_SHADER_LOC_VERTEX_POSITION
- ShaderUniformDataType: UNIFORM_VEC2 -> SHADER_UNIFORM_VEC2
- MaterialMapType: MAP_ALBEDO -> MATERIAL_MAP_ALBEDO
- PixelFormat: UNCOMPRESSED_GRAYSCALE -> PIXELFORMAT_UNCOMPRESSED_GRAYSCALE
* Added bone binding to whole mesh and not only set vertices.
+ Also added missed setting of the animation count.
+ Removed double ; on one line
* Added more of the gltf sample models
https://github.com/KhronosGroup/glTF-Sample-Models
We need to make it working for all of them.
* Binding to initial bind pose added.
* Fix cube disappearing bug because lerpPercent could be Inf.
* Fixed for rigged figure also
* Always try to set vsync.
Use the internal monitor function to correctly get the display for windows.
* Modified how fullscreen gets toggled.
- Removed the unsetting and setting of the resize callback function. Instead of that I moved the fullscreen flag setting into a more correct place before setting the fullscreen so that this flag can be used in the callback.
- In the resize callback now window size is only set when it is not fullscreen resulting in preserving the window size.
- When going fullscreen the larges resolution is used so that there are no problems of the type when you minimize the window you cannot use anything else in your desktop because the resolution might be too low. If a low res effect is desired one should use render texture (this is the approach all game engines use).
* Set correct return to window in case of fail to get monitor.
* Set the refresh rate on the mode.
* Made changes based on review from @raysan5
Co-authored-by: Jeffery Myers <JeffM2501@gmail.com>
* Add support for u8 bone indicies when loading glTF
* Fix segfault for glTF animations not keyframed at 0
When loading glTF animations we lerp between keyframes, and previously
assume that if the frame we are considering has a later keyframe, there
must be a previous keyframe. This is not true if the animation's first
keyframe is some time into the animation. In this case we now
effectively clamp to that first keyframe for any time prior to it.
* Respect parent bones tranform when loading glTF animations
We previously assumed that when loading glTF animations, the bones were
ordered with those higher up the skeleton tree (i.e. closer to the root)
came first in the list of nodes. This may not be true, so now we
repeatedly loop, preparing each level of the skeleton tree one after the
other, starting at the root level. This ensures that any parent
transforms are applied before transforming any child bones.
We also ensure that we have forced the loading of animation data before
attempting to interpolate to generate the animation frames for use
later, without this no animations are applied.
Finally we remove the check that assumed the first node in the nodes
list is the root, and use an invalid index value as the sentinal value
for when a node has no parent. Previously this was 0, which made
distinguishing between root nodes and children of the first node
impossible.
Actually, it seems more logical that rlgl takes care of OpenGL data than the models module...
Also, models module loaded vertex data is unloaded by models module.
hey!
Ive made a Raylib Binding for my Programming language ReCT! Its still a fairly small language (~30 users) but it would be really cool to be featured here, tho I'd completely understand if only relevant languages are allowed on the list
* Fixing typecast warnings generated by visual studio 2019 in examples.
* Changes to fixes based on feedback
Co-authored-by: Jeffery Myers <JefMyers@blizzard.com>
Mostly typecasts, and some int to unsigned short changes, and including the windsock 2 library in the examples.
Co-authored-by: Jeffery Myers <JefMyers@blizzard.com>
While it is JavaScript, I'd rather this be named raylib-duktape since there are different implementations of javascript available. Like QuickJS, V7, or Node.js.
* Add MUSIC_AUDIO_NONE to MusicContextType and format fixes
- Useful to check the context type to see if the format is recognized. Defaulting to wav causes issues where formats are assumed to
be wav.
* Fix memory issues with LoadMusicStream and UnloadMusicStream
- Set ctxType and ctxData even if the format fails to load.
- Set ctxData to NULL if it fails and check for null inside UnloadMusicStream.
- Change RL_MALLOC when loading formats to RL_CALLOC to prevent undefined behavior.
- Add NULL check when unloading xm file.
* Disabling WindowSizeCallback around fullscreen toggle.
#1294 fixed the issue that toggle fullscreen changes the screen size because of the WindowSizeCallback. The proposed edit by @raysan5 was to comment out WindowSizeCallback which I essentially simplified to disable the callback around the set window monitor functions.
The developers using the ToggleFullscreen function should be aware that they need to size the screen correctly on that same frame. Otherwise they should check if fullscreen and size properly using the GetMonitorWidth and GetMonitorHeight functions.
* Update core.c
Fix issue from merge
This solves issue #1322 which in my opinion was prematurely closed. As the monitor resolution is expected to be the maximum that the monitor supports. My change is that as per GLFW documentation you can get all current video modes sorted by max resolution. When you toggle fullscreen the first video mode returned would be the current screen resolution setup but that doesn't help if you want to know the maximum supported.
* Added example for gltf animation and split some functions for loading model animations into IQM and GLTF similar to how models are being loaded.
* Removed wrongly duplicated function
* Bone loading for gltf model (not working at this point)
* Loading info about vertex to joint connection but animation is still not working
* Skeleton and pose is correctly loaded. Need to communicate about interpolation in GLTF
* The model almost looks like a real person on animation.
* Fixed model loading with bones.
Also updated license info on the model.
* Cleaned up some code and updated examples.
* Fix identation issues
* Fix identation issues
* Fix identation issues
* Documenting the compiler flags
* Moved some android compiler flags and added documentation on them too.
* Some more restructuring.
Removed unnecessary comments that were self described by the code.
Added some more explanations around certain parts of CMake and especially around compiler flags.
CMake relied on this file for configurations and also was interfering in the regular config.h by having a separate definition if building with CMake. This was not entirely correct so instead we will define compile time definitions separately through CMake (CompileDefinitions.cmake) and also will use the provided EXTERNAL_CONFIG_FLAGS that I found that will not use config.h in through the build process.
I also introduced a new compiler option (CUSTOMIZE_BUILD) that when OFF will use the default config.h and when ON will show other options for redefining your own options.
Fixed an error in rlgl.h where if you have both RLGL_STANDALONE and SUPPORT_VR_SIMULATOR you get a compile time error.
This test file is just testing compilation with the library works correctly but is no longer needed because:
- it is not cross platform
- it taps into the CTest system which is better suited for real unit/integration tests
- it can be incorporated into the pipeline of github actions instead in the future
* Added a windows and linux simple compile with cmake
Will expand on the file but it will be nice to know if they are some extremely breaking changes in the future. cmake.yml will run two task one for linux build and one for windows build essentially checking that both are working. We can add all platforms later.
* Renaming the task to "CMake Builds" and removing the test step.
Commented out the test step as I don't yet know what the two bash files are doing but they are failing the build.
As described in the official documentation https://cmake.org/cmake/help/v3.0/variable/BUILD_SHARED_LIBS.html this flag is global by default and controls if the library will be built as a shared or a static library allowing us to define only one call to the add_library function (without specifying its type). It is also added as an option to be visible in CMake GUI applications.
* Better ignore support for idea projects.
Added a wildcard at the end because different configurations would have a diffeerent build directory.
* Removed external from being a relative include directory for target raylib.
Fixes#1533
* Delete emscripten.cmake
This file is not needed at this point. EMSDK provides a toolchain file that has a lot more things in it and is better supported. Project currently works fine with the documentation provided in Emscripten SDK on how to build projects.
* First pass file separation.
The main two files are cleaner now. Only important things can be seen. Major changes include:
- raylib_static is now the alias instead of raylib
- Repeating segments are removed and pulled into separate files into <root>/cmake
- File is reordered to make more sense
- Installs are better structured
- Library is build into an output directory "raylib" instead of "src"
- All public header files are now set as a public header file
- Source files need to be listed (it is a bad practice to capture them using wildcards and file globs)
- CMakeLists are better commented
* Second pass on the example dirs.
They are quite complex so I'm more hesitant to do major changes. Also it works pretty well. Noticed that I forgot one of the seperated files and added it into src/CMakeLists.txt.
* Returned the header copy as it was convenient to have the public headers copied.
* A better description to the variable RAYLIB_IS_MAIN
Co-authored-by: Rob Loach <robloach@gmail.com>
* Remove debug message
Co-authored-by: Rob Loach <robloach@gmail.com>
* Improvements based on review.
* Simplify the install condition to not be platform specific as it was before.
Co-authored-by: Alexander Neumann <30894796+Neumann-A@users.noreply.github.com>
* Remove some CMAKE variables as they don't affect the build in any way
Co-authored-by: Alexander Neumann <30894796+Neumann-A@users.noreply.github.com>
Co-authored-by: Rob Loach <robloach@gmail.com>
Co-authored-by: Alexander Neumann <30894796+Neumann-A@users.noreply.github.com>
* simple_game: Configure Make and makefile for Linux environments
* simple_game: Fix build issues on Android plaform with Linux HOST
The Makefile.Android.linux file was out of date with the rest of the
project, so this commit updates the paths, as well as leaving some as
optional, if it is already configured as an environment variable.
In addition, it corrects the build error related to static raylib:
the makefile was trying to generate libmain.so using the path of the
NDK libraries, instead of using those of the Android system, which
resulted in crashes in the generated apk.
* Don't create an ortho matrix when the viewport is 0 in any axis.
Not all compilers divide by 0 and return inf, some segfault.
The matrix is not used by anything when minimized, so it just needs to not be called.
* Better fix that always ensures the rlgl matrix is always valid
* Better fix that always ensures the rlgl matrix is always valid
* Added a new utility function to get the current monitor.
Some of the other functions rely on passing on a monitor id but we only have a function for querying the count of monitors available.
* Updated the comment to correctly reflect the function action
This monitor should even probably be passed as an id instead to make it more consistent with the rest of the API but this would break existing applications so I am hesitant to change the function signature directly.
* Add a function to know if two lines intersect each other and if yes, get the intersection point
* Remove indents
* Rework the declaration of the 'Vector2LineIntersect' function, and add the 'Vector2SegmentIntersect' function
* Remove bad indents
* Fix compilation issues
* Fix compilation error
* Fix compilation error
* Replace keyword '_Bool' by 'bool'
Pefixing/Suffixing some data type identifier in the variables is not a convention used in raylib, just reviewed it for consistency...
Still, I kept the *Rec suffix in some functions.
Previous implementation did not consider any padding while drawing the characters on screen (despite being available on the font atlas), so, only minimum character area was drawn.
If some text effect shader was required (shadow, glow, outline...), there was no space in the drawn quad to draw that pixels effect.
This commit corrects that issue.
This is a BREAKING CHANGE!
To address the linked issue, several functions have been renamed and couterpart functions have been created to free loaded memory:
- RENAMED: GetImageData() -> LoadImageColors()
- RENAMED: GetImagePalette() -> LoadImagePalette()
- RENAMED: GetWaveData() -> LoadWaveSamples()
- ADDED: UnloadImageColors()
- ADDED: UnloadImagePalette()
- ADDED: UnloadWaveSamples()
Previous GetKeyPressed() method was actually returning unicode codepoints equivalent values instead of the key-code of the pressed key. So, it has been replaced by GetCharPressed(), returning unicode codepoints and GetKeyPressed() now returns key-codes.
* Changed extension for web from .bc to .a
I did this to support vcpkg expectation. When using the library from vcpkg for web you would install it using vcpkg install raylib:wasm32-emscripten but also vcpkg expects the output lib to be with .a extension instead of .bc
Doesn't make a difference for standalone builds or when raylib is used as a subdirectory dependency.
* Added headers to install targets to fix vcpkg usage
Currently vcpkg works by installing the cmake target into its packages directory. The problem is that install only copies the public header at this point so we need to add the others to the install targets.
I did this to support vcpkg expectation. When using the library from vcpkg for web you would install it using vcpkg install raylib:wasm32-emscripten but also vcpkg expects the output lib to be with .a extension instead of .bc
Doesn't make a difference for standalone builds or when raylib is used as a subdirectory dependency.
This change only modifies the default value. In cmake you can have raylib as a subdirectory (dependency) and when you have it as dependency you wouldn't probably want to use the example by default. You can still use the option to enable them though.
* Fixed the build for web using CMake.
I found that the build for me was failing and I added some if defined checks in the core.c file where the glfwSetWindowAttrib was used. (error: implicit declaration of function 'glfwSetWindowAttrib' is invalid in C99 [-Werror,-Wimplicit-function-declaration])
I also changed some values in the toolchain file so that it correctly uses the .bat files when on windows.
* Cleaned up the additional variables (they are not important)
* Added more improvements to cmakelists
Added the option to use the system provided Emscripten toolchain to be more uniform with other libraries.
Fixed and issue which prevented example being built from cmake and also building with html extensions properly.
* Fixed ENUM to STRING because of a missed warning
* Fixed#1455
Fixed writing out of array bounds
Adjusted FPS comment to match value
Deleted unused function at the end, which has never been in use in the history of this file
* Fixed#1455
Readded the function
1) use the latest windows SDK not a specific one.
2) use the project dir as the root for the include dir for raylib, to help if the project is ever included in some other solution.
Without GLFW_OPENGL_FORWARD_COMPAT, running this as a standalone will yield the error:
```
NSGL: The targeted version of macOS only supports forward-compatible core profile contexts for OpenGL 3.2 and above
```
Stumbled on this example and I love this! Adding instructions that work for me on MacOS.. Note that glfw3 will need to be statically built locally and copied to this external/libs directory on mac. I can upload my static version, but it probably makes sense to do this only if there's some general naming convention for adding platform specific folders. Like "external_osx/lib" or "external/lib_osx". Then I'll drop my static libs in there.
WARNING: Several functions removed, replaced by SetWindowState() / ClearWindowState() equivalents, only for advance users.
ADDED: ClearWindowState() to reset window state
REMOVED: HideWindow() / UnhideWindow()
REMOVED: DecorateWindow() / UndecorateWindow()
There were some problems about frameCount vs sampleCount that could cause some breaks.
raylib audio structs stores sampleCount = frameCount*channels.
Most libraries return framesCount instead of sampleCount.
stb_vorbis seems to refer to framesCount as samples.
All required functions have been reviewed.
There is no zero-check, so window upscales to nothing.
SetupFramebuffer() is kinda wrong, it uses not its params, but global variables. I won't touch it, maybe it has purpose
Vector3Reflect exists but not Vector2Reflect. The code is pretty much the same.
I'm not sure what RMDEF does, but I added it to match other function definitions (haven't done much C programming, maybe I'm missing something). Can someone explain to me what it does?
Raylib-forever: 3.1-dev
It generates the c-to-nim bindings straight from the source.
nim-raylib: 3.1-dev
It uses Raylib-forever.
raylib-php: 3.0
Tested it using the provided binaries.
raylib-java: 2.0
Tested it using the provided binaries.
* updated README.md
* fixed CMakeLists.txt to allow building and debugging with Visual Studio Code and CMAKE Tools extension
* added PLATFORM_DRM
contains mouse pointer code from https://github.com/chriscamacho
* removed redundant cleanup in InitGraphicsDevice
* fixed DRM connector mode selection
* added choosen DRM connected mode to log output
* added respecting TargetFPS on DRM mode selection, default to 60
* added support for GetMonitorRefreshRate
* changed SUPPORT_MOUSE_CURSOR_RPI to SUPPORT_MOUSE_CURSOR_NATIVE
* changed avoidProgressive to allowInterlaced
* cleanup, function extraction and improved mode selection
* README reverted to original for PR
* line endings fixed for core.c
* removed old code
* mouse pointer reverted to small square
* replaced SetGraphicDeviceName() by DEFAULT_GRAPHIC_DEVICE_DRM
Co-authored-by: kernelkinetic <kernelkinetic@outlook.com>
Function has been reviewed to avoid any direct OpenGL call and use rlgl functionality, also, GenDrawCube() has been replaced by the internal batch system with DrawCube().
WARNING: rlEnableTexture() call must be issued after enabling the current framebuffer when using batch mechanism because it includes a set of security checks to avoid batch overflow and push/pop matrix operations.
* fixed wrong error message for input device
* error message without errnofor input device on RPI
to prevent from including additional header
Co-authored-by: kkl <klingenberger@bfmc.de>
This redesign allows more flexibility when creating RenderTexture and a simplification (and hopefully removal) of `GenTexture*()` functions, that should not belong to this model but the user code, due to the use of custom shaders.
Also, this new API opens the door for a possible GBuffers type and advance rendering possibilities...
Some functions of the API have been also simplified or even removed.
rlgl module can be used as an standalone library, so, a version for the library has been added: v3.1.0, matching current raylib version.
Before deleting certain objects, they must be detached from their parents. That's the case for shader objects after linkage to shader program and also for the texture/cubemaps/renderbuffers attached to framebuffers. If objects are deleted before detached, they are kept in memory to avoid accessing deleted data.
rlBlendMode() has been added to rlgl to be used on BLEND_CUSTOM. This functionality is exposed to advance users.
In any case, new blending modes could be added if required.
When using USE_PTHREADS=1 on libraylib.bc compilation, program requires --shared-memory passed to the linker and despite it compiles, it fails on execution (at least for me).
We use @CMAKE_INSTALL_PREFIX@ in the pkg-config template, but the way we
use it breaks when used with a path containing a space. Use quote to fix
this. This now means, we probably can't have quotes, but that's of
lesser concern.
There are no *.lib files that could overwrite each other when building
both static and shared versions of raylib at once. So just use the
normal library name without _static suffix.
When you install emsdk out of the box, the directory is no longer `$(EMSDK_PATH)/python/33.7.4_64bit` but rather `$(EMSDK_PATH)/python/3.7.4-pywin32_64bit` noting the `3.7.4-pywin32_64bit` change on the last file.
Thus, without adjusting this in the raylib Makefile it will throw an error:
```
PS C:\raylib\raylib\src> make PLATFORM=PLATFORM_WEB -B emcc -c core.c -Wall -D_DEFAULT_SOURCE -Wno-missing-braces -Werror=pointer-arith -fno-strict-aliasing -std=gnu99 -Os -s USE_GLFW=3 -I. -Iexternal/glfw/include -Iexternal/glfw/deps/mingw -DPLATFORM_WEB -DGRAPHICS_API_OPENGL_ES2 '"python"' is not recognized as an internal or external command, operable program or batch file.
```
However, changing this line in the Makefile compiles raylib for web as expected
`"raylib library generated (libraylib.bc)!"`
Reason for removal: This function forces a specific Image data format, it copies data internally (it could be confusing and lead to memory leaks), it's redundant, there is a simpler alternative and raylib promotes using structures directly
It seems some internals change recently due to web security reasons and some emscripten HTML5 funtionalities like pointerLock or fullscreen modes behave very weird or just don't work as expected
Despite all the effort put on function optimization, dealing with alpha blending is complex, considering src and dst could have different pixel format...
Some resources used in examples have not a clear license, so, I'm replacing some of them for clearly licensed versions or resources created by me under CC0. License file to be added.
Several functions used to load external files have been reviewed to just load the full file with LoadFileData() and load data from memory from there. This way all file access functionality is centralized in utils module.
Functions reviewed: LoadDDS(), LoadPKM(), LoadKTX(), LoadPVR(), LoadASTC(), SaveKTX()
* Adding Norm and Remap functions
// Normalize input value within input range
// Remap input value within input range to output range
* Rename Norm to Normalize
To make it uniforms with Raylib's functions
* Calculate Remap without other functions
Current looping system was broken, `loopCount` has been converted to `bool looping` and user can enable/disable with `music.looping = false`. `SetMusicLoopCount()` has been removed.
Most warning were related to types conversion (casting required) and unsigned/signed types comparisons.
Added preprocessor directives (_CRT_SECURE_NO_DEPRECATE; _CRT_NONSTDC_NO_DEPRECATE) to avoid warnings about unsafe functions, those functions are safe while used properly and recommended alternatives are MS only.
Some external libraries still generate warnings.
Created RenderBatch type and related functions to allow rlgl users creating custom and separate render batches and not only rely on one internal render batch.
This feature has not been exposed on raylib yet because it implies some breaking changes. Right now a custom RenderBatch is just used internally in rlgl.
There are multiple #define values around raylib, usually not exposed for redefinition, just reviewed all of them to allow users redefining them on compile time if required.
Also, multiple #define have been renamed and commented.
* First draft of UWP rework.
* Read desc
- Moved UWP specific functions to uwp_events.h
- Removed BaseApp.
- Implemented example UWP lifecycle.
* Added GIF recording and screenshot support.
* Character inputs and filesystem stuff
* Fix game closing on Xbox when B is pressed.
* Fix the gamepad binding hack
* Add as many keys as I believe are possible.
* Implemented mouse locking of a sort.
* Remove rogue todo, the rest are for a game dev using this example.
* Implemented touch how I "think" it should work. I cant test this.
* Review.
Optimizations of allocators.
Renamed 'Stack' to 'Arena'.
Replaced certain define constants with an anonymous enum.
Refactored MemPool to no longer require active or deferred defragging.
Move raylib games to another repo. It will reduce repo size for new clones.
I considered also removing the related history with [`git filter-repo`](https://github.com/newren/git-filter-repo) (the current sane alternative to the deprecated `filter-branch`) but it has some implications: It would had made a new repository with distinct history and checksums. If the repo was previously published,
the history of the new one won't have been compatible with the history others have pulled.
Actually this function is useless and potentially dangerous, internally, a shallow copy of data was done. Same could be accomplished accesing image.data directly.
Now it's blazing fast. It modifies image.data directly.
Previous version could take up to 3-4 seconds to draw a line... now it takes some nanoseconds...
As noted in #539, the symlink check was to support compiling raylib on
VirtualBox vboxfs as no symlinks are supported there.
With me using Linux as daily driver outside VirtualBox now, this 'feature'
is most likely unused by anyone, but still annoys other users (#791).
Just revert it and be done with it. If there are really others building
raylib on vboxfs or a similarly crippled file system under Linux, they
should now step forward when their build breaks.
This reverts commit b8ca51fd01.
- Added NULL return if the replacement string (`by`) is empty
- Reordered sanity checks since there's no need to initialize variables if the strings are invalid.
Errores fixes:
models.c,2843 Either the condition 'fileData!=NULL' is redundant or there is possible null pointer dereference: fileData.
raudio.c,805, 806, 807, 808, %d in format string (no. 2) requires 'int' but the argument type is 'unsigned int'.
* [cppcheck] Improvements in SaveStorageValue() in core.c
in file core.c cppcheck shows errors only in function SaveStorageValue():
* Common realloc mistake: 'fileData' nulled but not freed upon failure
* Memory pointed to by 'fileData' is freed twice.
Validation:
* Tested examples/core/core_storage_values.c
* Launched Unit Test for this function
* Rerun CPPCHECK afer fix
* [cppcheck] Change functions header to accept only positive position in files
Changes:
* Functions SaveStorageValue(), LoadStorageValue() (core.c)
* Functions LoadFileData(), SaveFileData() (utils.c)
* Headers in raylib.h
Validation:
* Tested examples/core/core_storage_values.c
* Launched Unit Test for these functions
* Rerun CPPCHECK afer fix
* Update compilation warning flags
Removed the -Wall flag that allow many warnings and added manually all the warning flags that don't generate warnings in the src/external folder.
Specifically, these are some of the flags reporting errors in src/external:
-Wmissing-prototypes
-Wunused-variable
-Wunused-value
-Wunused-parameter
-Wunused-function
* Uptade compilation flags in examples with missing -std=c99
* Android: Better track touch input returned from IsMouse*()
Switch to actually tracking touch input to use for "mouse" input rather
than the gestures system. The gesture system as an abstraction ontop of
raw touch input loses some information needed to map to "mouse"
input.
Before,
- IsMouseButtonReleased() triggers immediately after the initial touch
(because GESTURE_TAP activates immediately on touch) instead of waiting for the
touch to be released.
- IsMouseButtonUp() returns false, when it should just be the opposite
of IsMouseButtonDown().
- IsMouseButtonDown() returns true only after GESTURE_HOLD (which
activates after some period of time after GESTURE_TAP), when instead it
should just be true whenever there is touch input i.e. gesture !=
GESTURE_NONE or alternatively when any input is received on the screen.
After this PR, touches map closer to mouse input.
- IsMouseButtonReleased() triggers when touch is released (last frame
was touched, this frame not touched).
- IsMouseButtonUp() returns the opposite of IsMouseButtonDown()
- IsMouseButtonDown() is true when
(AMOTION_EVENT_ACTION_DOWN || AMOTION_EVENT_ACTION_MOVE) and false when
(AMOTION_EVENT_ACTION_UP)
* RPI: Include index check for RPI in GetTouchPosition()
We build the library as debug with AppVeyor and package it this way,
which is unfortunate, because on Windows it's linked against debug
variants of the C runtime. Fix this by build RelWithDebInfo instead
Fixes#1128.
We might want to customize this in feature for multi-config builds (e.g.
a Visual studio build with both Debug and Release configurations).
Output the variable value for user awareness.
head can't think of any improvement I could use on the shaders for
version 120
This has been tested on Linux (Desktop) requires testing on a Rpi
Co-authored-by: codifies <nospam@antispam.com>
This was working in 2.6 but no longer does in current git tree.
It appears touch position is only tracked on
AMOTION_EVENT_ACTION_[DOWN|UP], which only registers the initial touch
on the screen. Subsequent movement is not tracked into CORE.
Touch position and the Gesture System appears to be updated twice in
AndroidInputCallback in what looks like perhaps a copy paste error (code
is identical) with the exception of tracking AMOTION_EVENT_ACTION_UP in
the 2nd copy of the code (but this is not necessary to track).
If you need to track the first touch or release touch position, you can
do so with checking IsMouseButton[Pressed|Released] on the same frame.
This patch makes it so the touch position is always updated, and merges the
duplicated code into 1 singular code path.
NOTE: This functionality has an important issue, line space is fixed to 1.5 font.baseSize pixels, depending on the font and how it has been generated that spacing could be too wide or too narrow...
In `InitGraphicsDevice(...)`, the Android section has a screen security check
like other platforms- but CORE.display.width, CORE.display.height are
not set yet, so the security check sets it to 0. So ensure we query the
device's screen width and height before the screen size security check.
This also gives you the ability to run a proper full-screen application
on Android without any scaling and guess work on the target device by
setting screen width and height to 0 in `InitWindow(...)` and using
`GetScreen[Width|Height]()` to get the actual values.
We didn't use the latest version, but a compatible version, which is established by raylib-config-version.cmake.
It's ok to have a minimal version, so revert b7c0d5b6dd.
* Update GLTF support to include loading color for albdeo (saved in the color value of the materialmap), support occlussion and emmission maps.. as well as some quality of life updates.
* clean up to use single image
There could be some cases where we need to define the internal audio buffer size, now it's possible.
RENAMED: InitAudioBuffer() to LoadAudioBuffer()
RENAMED: CloseAudioBuffer() to UnloadAudioBuffer()
Renamed some defines and reviewed some comments.
Just for clarification, no plans to remove libc dependency, just did some code analysis to see how much raylib depend on stardard C library. My conclusions:
- stdlib.h: primary dependency is for malloc() and free()
- stdio.h: primary dependency is for FILE access, maybe it could go through a custom ABI?
- string.h: just around 8 functions required
- math.h: just around 8 functions required
- others: 1-2 functions required for some other headers
* Update to miniaudio 0.10
This replaces the old ma_pcm_converter with ma_data_converter.
At this time of this commit, miniaudio 0.10 is still in the testing
phase. To make it easier to update miniaudio.h during this period, I've
temporarily moved the @raysan5 Win32 customizations to raudio.c because
there may be quite a few updates to miniaudio.h during this time.
* Use miniaudio's built-in volume control.
* Create makefile for building android app on osx
This makefile can work on macos to build android app
* Update and rename Makefile.macos.android to Makefile.Android.macos
Rename the makefile for android macos.
* Update Makefile.Android.macos
replace the user specific folder with env var $HOME
Short non-looping sounds can sometimes think they need to keep playing and will output their first few frames again. This helps to break out of all the loops instead of just this one.
NOTE: When building for 64bit in raylib static mode, CloseWindow() symbol collides with user32.lib symbol. No solution for that at the moment, just compile raylib as shared library (raylib.dll), actually it can be chosen on project configurations.
* We get the video mode from the target monitor and use that to set, therefore
keeping windowed-fullscreen
* Added a GLFW_AUTO_ICONIFY 0 hint so that glfw does not minimize the window
when changing focus from a windowed fullscreen window. This is more expected
behavior for windowed full screen, when a user alt-tabs or clicks on a window in
the other monitor, they expect their windowed-fullscreen window to remaining up.
We were doing this before, but it was deleted during the
last GLFW update. Readd it to fix the associated macOS CI failure.
Fixes: ea5cd42e6 ("Update GLFW to version 3.4")
If press/release events for a mouse button come too fast, then using
`IsMouseButtonReleased()` does not work. This has been noticed when
using a touchpad on Linux when tapping with two fingers two emulate
right mouse button click.
The situation looks like this:
```
BeginDrawing <-- current==released, previous==released
Pressed <-- current=pressed
Released <-- current=released
IsMouseButtonReleased <-- returns false because current==previous
EndDrawing <-- previous=released
```
The fix is to update the previous mouse button state in addition to
current mouse button state when `MouseButtonCallback()` is called by
glfw. Now the situation is as follows:
```
BeginDrawing <-- current==released, previous==released
Pressed <-- current=pressed, previous=released
Released <-- current=released, previous=pressed
IsMouseButtonReleased <-- returns true because current!=previous
EndDrawing <-- previous=released
```
At least on Linux, CMake seems to add automatically
the '-rdynamic' flag. As a result, Emscripten
generates a fat HTML file that does not work.
Removing it allows HTML+JS+WASM generation.
* new linux makefile for Android portages
* Revert "projects: CMake: bump up minimal raylib version (#983)"
This reverts commit 82306af111.
* new PR for upstream
* for Raysan
* Removed Unused Uniforms
uniform vec3 viewUp;
uniform float deltaTime;
* Removed Unused uniforms
uniform vec3 viewUp;
uniform float deltaTime;
* Updated Source
Added - #define PLATFORM_DESKTOP line for desktop users.
This now will correctly find the proper glsl version for the raymarching.fs file.
Removed - Uniforms --> deltaTime and viewUp. Including the code that was setting them.
They were never used and they were triggering a log warning.
Removed - The const from both screenWidth and screenHeight.
Now they can be used to update the shader resolution when screen is resized.
NOTE : This is a quick fix and probably not the best idea.
Added - IsWindowResized() to check if screen is resized.
If window is resized then width, height and shader resolution are updated.
Changed - MIT tag at bottom right color value to BLACK. Now it's easier to see.
* Closer Match to original code
* Removed the PLATFORM_DESKTOP Define
* Initial commit of addition for GLTF materials.. should support loading more than just albedo map.
* Clean up
* fixed seg faults and leaks
* temp don't overwrite defuse colour when rendering
* undid something dumb!
* correctly mixed diffuse map color when rendering to preserve not overwrite it
When adding alpha mask to GRAYSCALE image, if using ImageFormat(), it could change pixel values, now we avoid that, mask is just added as an extra channel
...moved to internal AudioBuffer structure as totalFramesProcessed, now time measure works again... but there is some problem with looping...
Also note some inconsistencies between frames and samples, it seems those concepts are not considered correctly in the code.
I'm not sure why the clean command is so complex (especially given that find -type f -executable | xargs rm -fv works!)
but I fixed the version as is, to support x-pie-executable which was preventing it deleting anything on my system...
raylib logo animation has been removed. That funtionality was very restrictive, not configurable at all and hardly ever used, also, it added a coupling dependency of `core` module with `shapes` and `text` modules.
By removing the equal sign, if the 2 rects a right next to each other and not overlapping, there will be no collision detection. This is what a majority of other game libraries do and would make it easier to implement collisions for tile based games.
Replaced '__RemoveNode' as it was causing invalid memory accesses with regular doubly linked list deletion algorithm.
Replaced double pointer iterator in 'MemPoolAlloc' with single pointer iterator.
Fixed undefined variables errors in 'MemPoolFree' for the freelist bucket.
- Mesh, Shader, Material structs have been reviewed to minimize size when passed by value, all required code has been reviewed.
- GetCollisionRayModel() reviewed to avoid pointer, not required because model is not modified inside the function
- UnloadMesh() reviewed, pointer not required
- CheckCollisionRay*() parameters name reviewed
* Fix loading multiple animations from .iqm file
* Fix memory leak in models_animation example
* Added export instructions to the animation example
* use raylib free
* include <stdlib.h> to appease the travis CI gods
* replace tabs with spaces
Added in a check for x86 and x86_64 branches of android
Added in $(OS) checks to see if we're running on windows or *nix
Added a default location for android ndks and sdks at /usr/lib/android
Object Pool Changes:
-- changed 'size' member name of 'union ObjInfo' to 'index' to better name its purpose.
Memory Pool Changes:
-- Added memory node buckets to store and allocate smaller, more frequent byte sizes.
-- Replaced 'memset' call to deinitialize free list data with NULL and 0 assignments.
-- Removed some no-longer-needed commented-out code.
-- Changed insertion sort code to put the largest size at the tail rather than the head.
-- Made certain pointer variables as constant pointers.
* Patched potential bug when defragging.
Patched a potential bug concerning the '__RemoveNode' function as, when removing certain nodes that are either at the head or tail, it can yield a free list node of size 0 bug as the previous node was removed and its size was set to 0 but not fully removed from the other nodes.
* A few more potential bug patches.
Changes:
- Font structure has been redesigned, CharInfo structure contained character rectangle within font texture, it has not much sense, considering that it was an information relative to the font atlas generated and not the character itself, so character rectangles have been moved out from CharInfo to Font.
- CharInfo included a data parameters to contain character pixel data (usually grayscale), generated on TTF font generation. It was inconsistent with other fonts types, so, now CharInfo includes directly an Image of the glyph.
- REDESIGNED: GenImageFontAtlas(), additional recs parameter added, loaded and filled inside the function to export atlas characters rectangles, instead of silently modify the input CharInfo data.
- REVIEWED: ImageTextEx(), funtion retrieved the font atlas image from the GPU, that was slow and problematic in several platforms. Now it uses directly the CharInfo image. Support for unicode codepoints has also been added.
- REDESIGNED: ImageDraw(), now it includes an additional parameter, the color tint, not only it could be useful for several situations but also function signature is more consistent with similar functions.
- ADDED: ImageFromImage() to generate a new image from a piece of another image.
- REVIEWED: GetNextCodepoint(), renamed parameters to be more clear.
Also all examples and games that were affected by those changes have been reviewed.
Fixes#899, which made apparent three issues with how static libraries
are handled in raylib-config.cmake:
- XPREFIX is set before pkg_check_modules, which causes a duplicate
STATIC in variables, e.g. PC_RAYLIB_STATIC_STATIC_.*
- raylib_static is searched for, but no library exists with that name
- raylib_LDFLAGS isn't populated properly
This commit fixes these.
This module has been completely reviewed, old structures still contained OpenAL useless data, a full module revision. Some of the changes:
- Redesigned internal MusicData structure
- Exposed MusicStream structure data
- Reviewed AudioStream structure
- Redesigned Sound structure
Still some work to do...
L235 - Increased the memory threshold size so that we can further reduce fragmentation by allocating memory blocks that is close to the requested size by 16 bytes.
* Submitting rmem memory and object pool module
* changed 'restrict' to '__restrict' so it can compile for MSVC
Added `const` to parameters for `MemPool_Realloc`
* Update and rename mempool README.txt to mempool_README.md
* Update mempool_README.md
* Update mempool_README.md
* Update and rename objpool README.txt to objpool_README.md
* implementing changes
* updating header for changes.
* forgot to change _RemoveNode to __RemoveNode
* removing l
* removing l
* Updating documentation on MemPool_CleanUp function
* Updating documentation on ObjPool_CleanUp function
* changed *_CleanUp function parameter
Replaced `void*` pointer to pointer param to `void**` so it's more explicit.
* Updating header to reflect changes to the *_CleanUp functions
* A single change for the mempool and a patch for the objpool.
Object Pool Patch: if you deplete the object pool to 0 free blocks and then free back one block, the last given block will be rejected because it was exactly at the memory holding the entire pool.
Mempool change: switched memory aligning the size from the constructor to when allocating.
* added multi channel sound replay to raudio
added -fPIC to Makefile for Linux
added simple lighting and audio multi channel to examples Makefile
* not properly reporting audio buffer pool size...
With v2.5.0 out, increment API_VERSION, so binaries dynamically linked
against the released raylib aren't accidentally paired with a development
or later released raylib that may be incompatible.
When using FormatText() several times in same function, returned string is static and so, the same is returned, resulting in failures on shader loading.
Now dividing by the zoom instead of multiplying (in the shader), so zoom works as expected. Also zoom increase/decrease is now scaled depending on the current zoom.
extra-cmake-modules 5.38.0a is no longer hosted at the specified
kernel.org link. Use the occasion to move on to 5.58.
Because newer ECM debian packages have the control.tar file
xz-compressed, we need to update dpkg as well on trusty.
For more information, see
https://bugs.launchpad.net/ubuntu/+source/dpkg/+bug/1730627
Note that building examples for web as they are (no code adaptation for web avoiding while loop) implies using the emterpreter... and that's very slow!
Square root calls are computationally expensive. In this case, they can be avoided. Instead of checking distance<RadA+RadB, check distance squared against (RadA+RadB) squared. The dot product of Vector3Subtract(B,A) with itself gives distance squared, so I used this code instead of an element-by-element computation of distance squared. The only downside is that your geometric code is very readable, whereas this is less so.
They not only result in discrepancies between different compiler,
but trigger undefined behavior. Avoid them by having them break
the CMake build and CI.
CI is failing because we still test with GLFW 3.2, while
the internal GLFW is 3.3. To avoid such breakages in future,
build and install our own GLFW instead of relying on an external
Debian package.
We were doing this before, but it was deleted during the
last GLFW update. Readd it to fix the associated macOS CI failure.
Fixes: cd934c9f6 ("Update GLFW to 3.3.1")
The example requires pthreads and now C11 <stdatomic.h>, thus skip it
if either isn't available.
This also fixes the current Travis CI build failure for the
Windows configuration.
A plain variable is insuffecient for inter-thread communication. Both the
compiler and the processor may reorder accesses. The compiler could even
cache dataLoaded with the result that STATE_FINISHED becomes unreachable.
Fix this by using C11 atomic_bool, which guarantees sequential consistency.
This fixes#827.
Added guards to not redefine it if the user is using it with raylib.h
also added an 'f' at the end of the define to keep compliant with raylib's PI define
This change could break things. So, I created SUPPORT_HIGH_DPI flag to enable it (disabled by default).
Basically, it detects HighDPI display and scales all drawing (and mouse input) appropiately to match the equivalent "standardDPI" screen size on highDPI. It uses screenScaling matrix to do that.
This scaling comes with some undesired effects, like aliasing on default font text (keep in mind that font is pixel-perfect, not intended for any non-rounded scale factor).
The only solution for this aliasing would be some AA postpro filter or implementing the highDPI scaling in a different way: rendering to a texture and scaling it with FILTER_BILINEAR, check `core_window_scale_letterbox.c` example for reference.
Use at your own risk.
Two functions have been renamed for coherence; previous naming was confusing for several users:
- DrawPolyEx() ---> DrawTriangleFan()
- DrawPolyExLines() ---> DrawLineStrip()
* Working build
* Fix build again, stop deleting files
* Hotfix crash, needs investigating
* Remove VS2015.UWP, I cannot update the project
* Lots of UWP work, added keyboard and mouse press support. Still need to finish scroll wheel, mouse position and cursor hiding, plus other stuff that I haven't seen yet.
* Implemented a ton more things, added BaseApp.h to provide common code to UWP apps.
* Remove constant window dimensions
* Enable and Disable cursor support.
* Actually use mouse delta
* Gamepad Support
* Cleaning and small tweaks
* Restore original example.
* Update comment
* Use 'Messages' to handle the cursor functions so code is more portable.
* Comment
* Comment unused message fields and use vector for mouse pos instead.
* Move messages to utils.h and use messages for everything. No more plat-specific code in raylib.h
* Working build
* Fix build again, stop deleting files
* Hotfix crash, needs investigating
* Remove VS2015.UWP, I cannot update the project
* Lots of UWP work, added keyboard and mouse press support. Still need to finish scroll wheel, mouse position and cursor hiding, plus other stuff that I haven't seen yet.
* Implemented a ton more things, added BaseApp.h to provide common code to UWP apps.
* Remove constant window dimensions
* Enable and Disable cursor support.
* Actually use mouse delta
* Gamepad Support
* Cleaning and small tweaks
* Restore original example.
* Update comment
* Use 'Messages' to handle the cursor functions so code is more portable.
* Comment
* Comment unused message fields and use vector for mouse pos instead.
* Move messages to utils.h and use messages for everything. No more plat-specific code in raylib.h
* Tested some desktop stuff and added projection matrix updates for window resizing.
* Fixed big bad mouse bug
* Fix alt buttons and add hack to combat flickery key presses (far from perfect)
* Remove debug code
* Final commit
* Well, so I thought
* Wow, i am bad
* Remove packages folder
* Remove useless include
* Apply requested changes and fix linux build
* Try to stop packages folder
* Have we fixed the formatting properly?
* Third time's the charm?
* Where did this come from?
* Re-fix
* Autoformat is gonna kill
* Fixed XBOX ONE Support
* Fix tabs
Found some issues when building for web using latest emscripten 1.38.30, traced the error and found that eglGetProcAdress does not return function pointers for VAO functionality, supported by extension.
It requires more investigation but now it works (avoiding VAO usage)
Users can define their custom memory management macros.
NOTE: Most external libraries support custom macros in the same way, raylib should redefine those macros to raylib ones, to unify custom memory loading. That redefinition is only implemented as example for stb_image.h in [textures] module.
Issue was related to vertex tangent attibutes not uploaded to GPU, a quick solution was implemented for new vertex attributes loading for already existing meshes... I don't like it specially but it will work for now.
This is quite a big change, Model struct has been redesigned to support multiple meshes and multiple materials, most 3d fileformats contain multiple meshes and reference multiple materials.
Consequently, multiple functions have been reviewed.
LoadOBJ(), LoadIQM(), LoadGLFT() now return a Model.
Current LoadOBJ() is not valid anymore, actually, tinyobj_loader_c library is considered for replacement.
If we have no data to update/draw, we avoid update/draw. On `DrawBuffersDefault()` if no vertes data is available nothing is drawn but some globals: vertexData, projection, modelview, draws... are reseted.
There shouldn't be any problem if we don't touch those globals in case no vertex have been processed but, just in case, I warn about it.
Based on pull request from user "DarkElvenAngel", better integrated with the current event system and enhanced with buffer to help with fast typing at low framerates.
When drawing LINES or TRIANGLES, vertex are accumulated in same buffer as QUADS and new draw calls are registered but QUADS drawing uses an index buffer for optimization, so, when adding LINES/TRIANGLES vertices we need to make sure next draw calls for QUADS keep aligned with indices buffer.
To get that we just add some alignment vertex at the end of the LINES/TRIANGLES draw calls, to make them multiple of 4 vertex.
The idea is supporting additional raygui and physac modules building with raylib but those modules are distributed as header-only libraries and it makes a bit dificult to build them inside raylib...
raudio AudioBuffer internal struct collides on macOS with CoreAudio same name struct. In this case struct has been renamed because is internal to raudio... but probably all system should be redesigned.
Getting the following strict error....
```
src/text.c:117:105: error: constant expression evaluates to 2398692640 which
cannot be narrowed to type 'int' [-Wc++11-narrowing]
...0x00000000, 0x00000000, 0x00200020, 0x0001b000, 0x00000000, 0x00000000, 0x8ef92520, 0x00020a00...
^~~~~~~~~~
```
Switching it to an unsigned int fixes it.
clang was complaining about the type conversions. For example...
```
node_modules/raylib-src/src/core.c:1888:15: error: cannot initialize a variable of type 'char *' with an
rvalue of type 'void *'
char *cmd = calloc(strlen(url) + 10, sizeof(char));
^ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
```
No examples built for the Web platform functioned properly due to lack
of resources in the virtual file system provided by emscripten.
This patch addresses this problem by adding
'--preload-file local_path/resources@resources' emcc option to link
flags whenever necessary.
The default memory limit for emscripten applications is 16 mergabytes,
which might be to little for some examples, especially given that the
resources are also included in that limit.
Normally, using this option disables some asm.js optimizations, but
there's no such cost for WebAssembly.
$prefix/lib isn't in pc_path on Fedora 28:
[root@fedora-28 ~]# pkg-config --variable=pc_path pkg-config
/usr/lib64/pkgconfig:/usr/share/pkgconfig
This has the effect that the pkg-config file is written to the
correct location but pkg-config --libs raylib doesn't output
the correct library path. This fixes this problem by substituting
the directory names into the .pc, same as we do with the CMakeLists.txt
since #518.
This issue popped up during the automated test of the Perl bindings:
https://github.com/athreef/Alien-raylib/issues/3
When capturing framebuffer, if some element with transparency has been drawn, it retrieves that data... it could be a bit annoying in some situations because we could expect color compositing with background color... It depends on the situation and our needs... but most of the time we don't want that transparency on screenshots.
This specific change could be very annoying for people already using FLAG_MSAA_4X_HINT, their programs will compile correctly but window won't be shown...
Planning to promote raudio module as a simple and easy-to-use front-end for the amazing mini_al library, so the name change.
Name comes from raylib-audio but in spanish it also remembers to word "raudo", meaning "very fast", an analogy that fits perfectly to the usefulness and performance of the library!
Consequently, raylib version has been bumped to 2.4-dev.
glfw/glfw@5595fa3ae6 implements a proper fix for the macOS Mojave
problem of OpenGL windows not being rendered until moved or manually
updated.
Pull in the current master and rebase the three patches we have on top:
- two commits we have for reuse of the GLFW CMake build system for Wayland
It hasn't yet to be acknowledged upstream.
- one commit removing #include <windows.h> in glfw3native.h to avoid
duplicate declarations.
Fixes#655 and #665.
Specific textures generation code is quite redundant and not flexible for the user, I'm trying to figure out some easy way to allow raylib users to do the same without needing those functions (very specific and shader dependant). RenderTexture loading and Cubemap textures support must be improved.
CMake defaults to generating a Visual Studio build on Windows,
which doesn't involve make. Thus use cmake --build to abstract
that detail away. We already do that in the appveyor.yml.
The install line is a bit hacky: cmake might not be in the search
path when using sudo, thus use "$(which cmake)" to get the path,
sudo doesn't seem to be available on the Travis CI windows
environment, so use $(which sudo) without quotes to expand to
nothing if that's the case...
Decided to allow user to provide values directly instead of requiring a Vector2 struct, probably more confortable to use.
- SetMousePosition()
- SetMouseOffset()
- SetMouseScale()
funopen is only needed on Android, so declare it
only there. This fixes following MinGW build failure:
utils.c:50:7: error: conflicting types for ‘funopen’
FILE *funopen(const void *cookie, int (*readfn)(void *, char *, int),
^~~~~~~
In file included from utils.c:45:0:
/usr/include/stdio.h:586:7: note: previous declaration of ‘funopen’ was here
FILE *funopen (const void *__cookie,
^~~~~~~
Added a bunch of useful text management functions.
Consequently, some already available functions like `FormatText()` and `SubText()` has been renamed for consistency. Created temporal fallbacks for old names.
raylib version bumped to 2.3.
Problem aligning provided vertex data to multiples of four, because main buffer is intended to bu used with indexed quads... but also shared with triangles and lines.
Changed parameters order for consistency with LoadFontData() and other functions when an array is passed by parameter and array size is the following parameter.
This commit implements a big update of rlgl module, intended to optimize some parts. This change could break some code bases... hopefully not, but it could.
The BIG changes to the module are:
- Replaced LINES-TRIANGLES-QUADS buffers by a single one, now all vertex data is accumulated on a single buffer and managed with registered draw calls. LINES-TRIANGLES-QUADS could be used the same way as before, rlgl will manage them carefully. That's a big improvement of the system.
- Support multi-buffering if required. Just define MAX_BATCH_BUFFERING desired size (currently set to 1 batch). Should be enough for most of the situations.
- Removed temporal accumulative buffers for matrix transformations, now transformations are directly applied to vertex when on rlVertex3f()
- Reviewed rlPushMatrix()/rlPopMatrix() to be consistent with OpenGL 1.1, probably I should remove that ancient behaviour but... well, it was not consistent and now it is.
- Minor tweaks: LoadText(), I broke it in last update... also multiple comments reviewed.
- TODO: MAX_BATCH_ELEMENTS checking should probably be reviewed... done some tests and it works but...
raylib resource data file for Windows platform (containing raylib icon and metadata for executable file) has been renamed to a more consistent name: raylib.rc.data
Also required to work with tcc compiler.
Now `BeginTextureMode()` does not clean buffers automatically, that behaviour has been changed because there could be some case (i.e. painting software) where texture buffer does not ned to be cleared; user is responsible of clearing buffers using `ClearBackground()`
When doing a8dffc63fb I was not aware that
printing a warning and not executing the code would be an option. I only
learned that through 618f220851.
So I propose that we allow all URLs except if the string contains a `'`.
Which could end the URL and call another command via `system()`.
Related to https://github.com/raysan5/raylib/issues/686
Calling just `xdg-open` is not right. One needs to pack the URL in `'`.
If we don't do this then some special characters (like ampersand) will
be executed.
Maybe this is true for Windows and Apple case too, but I don't own any
such system. So please merge this, and if it's true for more cases let's
use `sprintf()` in the other cases too.
OpenURL() is a function that most games probably will never need.
Wasting 512 bytes to store of a static char to store an the URL is not
wise.
I propose to have it dynamic building the string on the fly.
Some projects need the buffer to not be empited when drawing to the render texture. I would suggest making maybe a variation of the function if you'd like to keep backwards compatibility, maybe like: BeginTextureModeNoClear() ?
By default, internal white texture was used to draw most of the shapes; some time ago, support for white font character from default internal font was added. That way, all basic drawing (shapes, text) could be performed without a texture change and in a single drawing pass.
Now, we move a step further and we allow configuring the texture (and rectangle) used to do the shapes drawing.
On Linux systems the length of the path is defined in linux/limits.h as
PATH_MAX.
Lets use that for MAX_FILEPATH_LENGTH, which is a define that we can
find in some comments in the code that is actually never used. Instead
often we see 256 handwritten.
So lets have MAX_FILEPATH_LENGTH as a proper define, being set to
PATH_MAX on Linux and to 256 on Windows systems.
- Added a function to get the last write time of a file. I used this so I can reload files or resources if the time since they were last loaded changes.
The prototype of GenImageFontAtlas() in the main raylib.h header has a set of swapped parameter names.
Going through the usage of the function within raylib itself, it appears as if the correct order is:
1) charsCount
2) fontSize
However, it's exposed to the world as the other way around, which may cause some major confusion.
* changed bitwise & to logical &&
* removed redundant state check
* moved a strcpy inside a NULL check to prevent a crash.
NOTE: nothing sensible will happen as a result, but no crash at least.
Generating the projects using CMake, targeting VS2017, results in an error when compiling.
This is due to physac.h trying to make a 'vertices' array of size 'int count', making it const does not work, either.
This changes the static declaration to a malloc/free combo.
Tested using the physics-demo.
This implementation is a bit limited, does not support wide characters directories but it's a temporal solution...
This solution uses "io.h" (like MinGW provided one) while other modern solutions use the "windows.h", that result in duplicate symbols issues... need to review it carefully.
REVIEW: Reorganized global variables for consistency
ADDED: GetWindowHandle() to get native window handle
ADDED: GetDirectoryFiles() to get files list for a DIR
Apple ought to fix their OpenGL implementation, but with OpenGL now
deprecated this might not happen.
This has been reported upstream in GLFW in glfw/glfw#1334.
The workaround comes from kovidgoyal/kitty@b82e74f99
This also fixes the HiDPI (Retina) scaling issues reported in #497,
so the workaround is enabled anywhere __APPLE__ is defined.
Previously, if <raylib.h> was #included prior to another header that
defined bool, the compilation would fail.
This is e.g. the case for <perl.h> and <objc/objc.h> which both fall
back to the <stdbool.h> if C99 is available.
The following commit includes <objc/objc.h> in src/core.c, which causes
the same problem.
Avoid this by checking for C99 bool like we already do for C++'s.
- Added PLATFORM_DESKTOP check for Monitor functions to try to fix issue on android.
- Not sure what return types should be when not on desktop. Added rough guess for now.
Useful for bitmaps pixelated fonts where anti-aliasing is not desired!
Change also enables additional font generation mechanisms in a future (cleartype, hinting...).
This requires the user to explicitly specify the path to their raylib folder. We need a better way around this (something like what we do for windows would help).
With the CI system, release directory has not much sense, actually,
every new commit it gets outdated and latest stable release is already
available in GitHub Release tab.
strprbrk() does not follow raylib function name convention but as it is
very similar to the standard strpbrk(), we'll keep the naming... also,
don't like to mix static functions with API functions but as strprbrk()
is just used in the two functions below, it's ok to be there... maybe it
could be refactored in a future or even move the logic inside the
required functions...
When a batch reach its vertex limit, a draw call is issued and batch restarted for refilling but if the draw call was issued for vertex data accumulated inside rlPushMatrix/rlPopMatrix, draw call was issued before the rlPopMatrix, consequently modelview matrix was not properly recovered before the draw call... obviously, it only happened the following draw calls, not the first one...
Now it works ok but this system needs to reviewed, noticed and important frames drop when processing around 20 dynamic batch draw calls, it means filling MAX_QUADS_BATCH (8192) quads of data 20 times per frame, including data updating and sending for draw processing.
Doing some maths, it means:
Vertex data (float) -----> 8192 quads * 4 vertex * 3 comp * 4 byte = 393216 bytes
Texcoords data (float) -> 8192 quads * 4 vertex * 2 comp * 4 byte = 262144 bytes
Color data (uchar) -----> 8192 quads * 4 vertex * 4 comp * 1 byte = 131072 bytes
Thats a total of 786432 bytes (0.75MB) sent to GPU 20 times per frame for processing... I'm testing in an Intel HD Graphics integrated, I imagine is too much data to be sent and and it causes stalls, so the frames drop...
CheckCollisionRecs() returns true on edge-collision what means that the
snake eats the fruit when colliding with it but also when sliding by one
unit above or below the fruit.
Added support form vertical and horizontal 3-patches.
Corrected the distortion caused when destRec size is smaller than 4x4. Now even 1x10 or 0x0 sizes are drawn correctly.
Added support form vertical and horizontal 3-patches.
Corrected the distortion caused when destRec size is smaller than 4x4. Now even 1x10 or 0x0 sizes are drawn correctly.
The GLFW tree distributed with raylib has two modifications:
- GLFW_PKG_{DEPS,LIBS} are exported to PARENT_SCOPE, so we can use them
in our pkg-config file
- An intermediary glfw_objlib target is added, so we can reexport GLFW
symbols from libraylib.a
rglfw can fix the second point, but for Wayland usage, we would have to
replicate protocol generation, so we just leverage GLFW's existing
support instead.
To make maintenance easier, I have submitted a pull request for
including these modifications to upstream GLFW.
And to make that one easier, this patch dog-foods the modifications,
so raylib users can help find regressions. :-)
glfw/glfw#1307
With the recent CMake cleanup, getting raylib's dependencies for use
when building rlgl_standalone is quite straight forward, so lets enable
it again.
Fixes#508, just properly this time. :)
Homebrew doesn't ship 32-bit libraries anymore, so using both
-DUSE_EXTERNAL_GLFW and -DMACOS_FATLIB with a Homebrew GLFW would fail.
With -DUSE_EXTERNAL_GLFW=OFF, this is not a problem, but I think keeping
it off by default makes more sense. If someone wants universal
libraries, they can just toggle it.
PLATFORM_WEB is not the only platform that doesn't define
GLFW_TRANSPARENT_FRAMEBUFFER, it's also recent enough that it's not
included in the most recent GLFW 3.2.1 release, so this error can creep
up when using USE_EXTERNAL_GLFW.
Remove that link_libraries_to_executable() hack and defines a proper
raylib target that can be used with target_link_libraries.
The same target is also available for external (user) code by using
find_package(raylib).
This results in:
- Remove hardcoded build directories from examples and games CMakeLists.txt
- Allow rlgl_standalone and other special examples to be built easily
- Allow CMake projects to find_package(raylib instead of fiddling with pkg-config
- Makes code a little more maintainable
- Fixes#471, #606.
- Makes code less confusing by removing the double use of PLATFORM (#584).
Note that this is still not _The Right Way_(TM), because normally
raylib-config.cmake (or its includes) would be automatically generated.
I didn't manage to get that to work though, so I went the easier route
of just wrapping pkg_check_modules for consumption by find_package.
also makes one configuration shared-only
dr_flac is not built on i386, because GCC 4.8 complains about asm("cpuid"
clobbering ebx, as it's using ebx for PIC.
Instead of downloading a newer GCC (and multilib),
disable FLAC for that one configuration...
It would be good to have a way to continue execution even when loading a stream didn't work.
Free music and set it to NULL in case something went wrong, so that users can check for it.
1. Always synthesize a complete frame of audio, using a second buffer (this prevents gaps in playback)
2. Sine is computed correctly, with an adjustable frequency
3. User can modulate frequency in real-time with mouse
4. Entire audio buffer data is shown, visually demonstrating how sine changes in wavelength
Examples can be compiled for web with no code change at all! Usually
examples need to be refactored for web... using emscripten code
interpreter (emterpreter), it can manage synchronous while() loops
internally... as a downside, execution is very slow...
This change allows rlgl.h usage as independent single-file header-only module... still some tweaks required, like removing GLAD dependency... required extensions could be manually loaded!
Also removed shader_distortion.h, embedded in rlgl.h
if (${PLATFORM} MATCHES "Desktop")
target_link_libraries(${RAYLIB}_shared glfw ${GLFW_LIBRARIES})
was never true because PLATFORM STREQUAL "PLATFORM_DESKTOP"...
This fixes#551 and makes the changes suggested in #552 (commited as 965cc8ab)
unnecessary.
From 2019 64bit support will be mandatory to publish an Android app.
Google plans to require that new apps target Oreo (API level 26) in
August of 2018.
This reverts commit 2d6fb5c628,
and adds a fix for Alien::raylib's test failures.
The tests failed because the resulting static library didn't reexport
GLFW symbols. As a fix, we now have GLFW create a CMake "object library"
target that we can link with both the static and shared raylib.
This is arguably ugly... Proper fix would probably be a GLFW upstream
object library target.
Closes#536.
Currently, if:
* GCC doesn't supports -no-pie: Build error
* GCC supports -no-pie
* GCC is not configured with --enable-default-pie: No-op
* GCC is configured with --enable-default-pie:
Slightly worse performance because we still generate -fpie code
(-pie affects linker, -fpie affects compiler)
So instead of probing for existence of -fno-pie -no-pie, remove it altogether.
Fixes#540: Build breakage on Debian 8 with gcc 4.9.
We need the CMake stuff for wayland configuration.
Otherwise, we would have to replicate that ourselves.
This is the full 7ef34eb06de54dd9186d3d21a401b2ef819b59e7 tree except
for tests/ examples/ and docs/
Panders to the idiosyncrasies of my work flow:
I have my raylib build directory mounted as a VirtualBox vboxfs for use
with my Linux VM, but vboxfs doesn't support symlinks, while raylib shared
library versioning on Unix expects symlinks to work.
If this happens, library versioning is now disabled on Unix with
an error message instead of just failing the build.
- Added Vector3OrthoNormalize() to raymath.h - not sure if it is correct
- Implemented MeshBinormals() - Mesh struct has not a place for them...
- Updated model_material_pbr example - tested but not working on my GPU
(old Intel HD), actually, it never worked on it...
Reported in #435, tcc generates out-of-line definitions for inline
symbols, something it shouldn't. This fix punishes tcc for that
by making applications it compiles (slightly) larger...
That way, a user needs only to touch a single file to configure what
features raylib is built with.
Include guards are left out intentionally, because config.h should only
be included in source files, not headers.
Later on, config.h can also define the raylib version (#461).
This is already the order that is used for Android. It doesn't appear to
make a difference on desktop but on web using the timer before it's been
initialized (by glfwInit, inside InitGraphicsDevice) causes the a long
(and variable but often several seconds) sleep between the first and
second frame.
Fixes: 468309d ("Early-exit InitWindow if InitGraphicsDevice fails")
Inspired by #504.
Instead of requiring the user to do PLATFORM_ANDROID #ifdefery,
have the android_main entry point exported by raylib and call
the user-defined main. This way many games could (in theory)
run unmodified on Android and elsewhere.
This is untested!
- SetWindowSize() to scale Windows in runtime
- SetMouseScale() to scale mouse input, useful when rendering game to a
RenderTexture2D that will be scaled to Window size (used on rFXGen tool)
GLFW has been updated to latest version, probably this code is not
required any more due to already been integrated into library... but it
needs to be tested...
Renamed function for consistency with a possible Mesh manipulation functions (maybe added in a future). Naming follows Image*() manipulation functions.
jar_xm.h does some shady pointer casts leading to unaligned accesses
and breaking strict aliasing. x86 has special circuitry for doing
unaligned accesses, but on other architectures, it may trap and require
kernel fix-up or crash outright. With this patch, one obstacle in
porting raylib to the GameBoy Advance has been removed. Go for it ;-)
To avoid having to rewrite that `mempool' code, insert padding before
structs and instruct the compiler (GCC, most importantly), to be gentle
when optimizing.
This fixes#490 (Unless we got ourselves 256-bit pointers, if so,
hello future!)
RAYMATH_EXTERN_INLINE was renamed to RAYMATH_HEADER_ONLY, which user code
may define if they want to use it as header-only library. If multiple
files in the same project define RAYMATH_HEADER_ONLY, they might each
have duplicate out-of-line definitions of the same functions.
By default, raymath.h exposes inline definitions, which instructs the
compiler _not_ to generate out-of-line definitons, if out-of-line
definitions are required, those of the file defined with
RAYLIB_IMPLEMENTATION are used instead. There may be only one such file.
In C++ mode, the compiler will select only one out-of-line definition
automatically, so no need to define a RAYLIB_IMPLEMENTATION.
Unfortunately, we have to remove raymath function declaration from
raylib.h as those declarations would lead to duplicate out-of-line
definitions which would yield linker errors. This problem didn't
exist with GNU89 or C++, because there multiple defintions are ok,
but in C99 they aren't.
RAYMATH_EXTERN_INLINE was renamed to RAYMATH_HEADER_ONLY, which user code
may define if they want to use it as header-only library. If multiple
files in the same project define RAYMATH_HEADER_ONLY, they might each
have duplicate out-of-line definitions of the same functions.
By default, raymath.h exposes inline definitions, which instructs the
compiler _not_ to generate out-of-line definitons, if out-of-line
definitions are required, those of the file defined with
RAYLIB_IMPLEMENTATION are used instead. There may be only one such file.
In C++ mode, the compiler will select only one out-of-line definition
automatically, so no need to define a RAYLIB_IMPLEMENTATION.
Unfortunately, we have to remove raymath function declaration from
raylib.h as those declarations would lead to duplicate out-of-line
definitions which would yield linker errors. This problem didn't
exist with GNU89 or C++, because there multiple defintions are ok,
but in C99 they aren't.
When UnloadModel() --> UnloadMaterial(), avoid unloading default shader (if used) and avoid unlaoding default texture (if used), that data is managed by raylib internally. The question is... should UnloadModel() also UnloadMaterial()?
Supported UTF8 range equivalent to [128..255] (80h..FFh)
Exposed and renamed text function GetGlyphIndex()
Renamed spriteFont parameter name to simply font
Small security check on transmission mission ending screen
They were named so for compatibility with make, but make doesn't use
the anymore. I always forget whether it's SHARED_RAYLIB or
RAYLIB_SHARED...
For now, RAYLIB_SHARED and STATIC_RAYLIB may still be used,
but print a deprecation warning.
These changes are intended to provide context and control over the Linux make install process. make install RAYLIB_LIBTYPE=SHARED now works as expected. libraylib.so is properly installed with attendant runtime links. The examples will be running against the newly installed libraylib.so unless otherwise specified with RAYLIB_RUNTIME_PATH. See raylib/src/Makefile and raylib/examples/Makefile for usage of RAYLIB_INSTALL_PATH, RAYLIB_H_INSTALL_PATH, and RAYLIB_RUNTIME_PATH variables. RAYLIB_RUNTIME_PATH in particular is interesting for portability since sudo isn't needed.
The default configuration and workflow is essentially unchanged and unaffected.
Otherwise we may run into LoadDefaultFont and crash in rlLoadTexture
Also moves InitTimer() before InitGraphicsDevice(), to allow it to be
tested even if InitWindow ultimately fails.
In case graphic device could not be created it returns false instead of
failing with an error tracelog (and consequently closing the program).
Window initialization success could be checked with new function
IsWindowReady()
You can't do much with raylib if glfwInit or glfwCreateWindow fails,
currently it just exits by means of TraceLog(LOG_ERROR.
User code, however, might want to fall back to a text-only UI
or display a warning if raylib can't be used.
glfwSetWindowPos was called on a NULL window, triggering an assert
inside GLFW. Check for failure and exit cleanly by means of
TraceLog(LOG_ERROR instead.
-DWITH_SYSTEM_GLFW=ON: Link against system glfw and fail otherwise
-DWITH_SYSTEM_GLFW=OFF: Use embedded rglfw.c
-DWITH_SYSTEM_GLFW=IF_POSSIBLE: Probe for system glfw but fallback to
rglfw if unavailable
Also change Linux 64-bit CI build to install system glfw and use it,
so this doesn't bitrot.
Addresses #453.
Review rlLoadTexture() function to make it simpler, now OpenGL texture
glInternalFormat, glFormat and glType are retrieved with new function
GetGlFormats()
- Support OpenGL 1.1 if selected macro
- Corrected MSVC compiler issues with (void *) data
- Removed raylib.dll project
- Created DEBUG_DLL and RELEASE_DLL configurations
- Renamed VERSION to RAYLIB_VERSION
- Renamed API_VERSION to RAYLIB_API_VERSION
- Renamed RAYLIB_RELEASE to RAYLIB_RELEASE_PATH
- Support Web Assembly compilation on PLATFORM_WEB
Mouse input is implemented, with all bells-and-whistles. This includes
cursor locking and scroll wheel support.
Keyboard input is reverted to a callback model to better reflect the
existing architecture in "core.c"
- Renamed enum TextureFormat to PixelFormat for consistency
- Added support for pixel format UNCOMPRESSED_R32
- Using GetPixelDataSize() where required
That function depends on SavePNG() and forces platform check on textures
module, that behaviour should be changed, platform definition should be
only required on core module...
* `Alien::raylib` downloads raylib, builds it and installs it in the Perl module path (Basically abusing CPAN as package manager)
* `Graphics::Raylib::XS` depends on `Alien::raylib` and reexports all C symbols as XS symbols usable in Perl
* `Graphics::Raylib` depends on `Graphics::Raylib::XS` and is the actual Perl wrapper with a Perlish API, which users should be using
Now with external OpenAL and GLFW dependencies removed,
we don't have to worry about installing them in CI.
Shared libraries are now always built along with static libs.
Games and examples are built everwhere except for Visual Studio,
because Physac needs pthreads, which VS doesn't provide.
See #401 for the discussion.
Also bumps version number to 1.9.2 without the -dev,
because neither ELF nor MachO like such a suffix.
The -dev suffix will have to be restricted to the git tags.
Updated to latest GLFW library and working on Wayland support, still
looking how to implement it on raylib because it just exposes
PLATFORM_DESKTOP and defaults to X11 windowing system on Linux...
OpenAL Soft backend is still available in audio module, I'm thinking if
exposing it for building in some way or just left it there for advance
users to switch to it manually in case of necessity...
They were disabled because they failed to build,
but this patch set fixes the build on Linux and macOS.
This doesn't apply to the AppVeyor build on Windows yet;
it currently fails at linking with OpenAL.
... for now.
Syntax was confusing Travis CI, AppVeyor is reporting 401,
so lets see if this change at least fixes Travis.
If this doesn't work, it might be that @raysan5's token is required.
cmake --build . --target package # or make package if make is used
can now be used to create binary packages for raylib.
AppVeyor and Travis CI are configured to push the artifacts
that result from building git tags to the related Github releases page.
After installation, compiling new programs is possible with
$ cc game.c `pkg-config --static --libs --cflags raylib`
or
$ cc game.c `pkg-config --libs --cflags raylib`
depending on configuration
Also adds following configuration options:
- WITH_PIC "Compile static library as position-independent code"
- STATIC_RAYLIB "Build raylib as a static library"
- MACOS_FATLIB "Build fat library for both i386 and x86_64 on macOS"
This bug is a result of the buffer of an AudioStream being smaller than
that of a period of the backend playback device. In this situation,
AudioStream's would have pauses between buffer updates because the
backend is not able to re-fill the AudioStream buffer's quick enough
due to it's periods being longer than the AudioStream buffer.
We already have automatic Linux and macOS build via Travis CI.
This adds the same for Windows x86 and x86_64 with both
Microsoft Visual Studio 2015 as well as MinGW-w64.
There have been two problems:
* GLFW itself was compiled with the definitions for compiling
_against_ GLFW (fixed by removing requirement for external glfw)
* rglfw.c was being compiled as C code, although it includes
Objective C files.
This _might_ break the Windows build, needs to be checked.
Fixes#391, but as noted I'd prefer though a separate source directory
and build script for GLFW.
Feature macros need to be defined before #including any headers,
preferably through the build system, but this is good enough.
Fixes a compile error on my fork's Travis CI.
libEGL and libGLESv2 have been renamed on latest Raspbian Stretch
version (also included on latest Jessie upgrade).
It seems to be done to avoid conflicts between official Mesa libs and
Broadcomm provided ones.
Namely:
- GenImageHorizontalV
- GenImageHorizontalH
- GenImageChecked
- GenImageWhiteNoise
- GenImageCellular
The gradient implementation may be a bit naive, for example it doesn't do any gamma correction.
Using the library() function instead of shared_library() allows changing
of the library type via the default_library option.
This allows for easy change between static and dynamic library building.
Use 'meson --default-library=static builddir' to build as static, if no builddir yet exists.
Use 'mesonconf -Ddefault_library=static builddir' to change the type for
an existing builddir.
It seems Sleep() behaves weird on my computer, disabled by default
returning to the busy wait loop... also re-implemented DrawFPS() to
avoid frame blitting...
According to Man Pages, timespec with std=c99 needs "_POSIX_C_SOURCE 199309L". Due a some kind of bug, "#define _POSIX_C_SOURCE 199309L" doesn't work, so we must use "-D_POSIX_C_SOURCE=199309L" in compiler options.
raylib webpage has been completely reorganized and moved from gh-pages
(a pain to work with) to docs folder. Useless libs have been removed,
webs have been renamed, etc.
Now it would be easier (hopefully) to update webpage. :)
- Improved ImageCopy() to support compressed formats
- Renaming file-formats header structs for consistency
- Review variables naming on ImageDither() for consistency
- Improved LoadImagePro() to make a copy of data
- Preliminary support of rRES file format on LoadImage()
- Renamed WritePNG() to SavePNG() for consistency with other file
loading functions
- Renamed WriteBitmap() to SaveBMP() for consistency with other file
loading functions
- Redesigned SaveBMP() to use stb_image_write
The function means to accept a const * so let's declare it.
Will allow passing const buffers in games.
Also constness is next to godliness!
Signed-off-by: Saggi Mizrahi <saggi@mizrahi.cc>
Mask was wrongly applied to 8-bit font image, it generated dark borders
on the font. Grayscale image has to be considered as the alpha mask for
a completely white image to use it correctly.
The first target allow makefile to install the dev files (static library and
header) to standard directories on GNU/Linux platforms; the second allow it to
unistall (remove) the dev files.
It needs lot of improvements.
Matching the same stereo rendering result given by Oculus PC SDK for
Oculus Rift CV1 is very difficult because hardware has changed a lot and
DK2 distortion shader and parameters don't fit on CV1. Some custom
parameters have been calculated to simulate kind of CV1 stereo
rendering. Further work is required on this point.
- Embedded VR distortion shader
- Ready to support multiple VR devices
- Fallback to VR Simulator if device not ready
- Support mono rendering over stereo rendering
...to avoid dynamic conditions on for loop (lightsCount) on standard
shader, it seems GLSL 100 doesn't support that feature... on some GPUs
like RaspberryPi...
... and now physac thread creation is done in InitPhysics() and it is
destroyed in ClosePhysics(). User just need to call these functions to
use physac module.
Old physics update system used a static number of steps to calculate
physics (450 for desktop and 64 for android). It was too much and it was
limited by target frame time...
Now physics update runs in a secondary thread using a fixed delta time
value to update steps. Collisions are perfectly detected and resolved
and performance has been improved so much.
Moved all external libraries used by raylib to external folder inside
raylib src. Makefile has already been update and also the different
includes in raylib modules.
- Added normal and specular maps to standard shader.
- Added full tint attribute to standard shader and material data type.
- Changed point light attenuation to radius.
- 3 light types added (point, directional, spot).
- DrawLights() function added using line shapes.
- Standard lighting example added.
- Removed useless struct variables from material and light.
- Fixed light attributes dynamic locations errors.
- Standard vertex and fragment shaders temporally added until rewrite it
as char pointers in rlgl.
TODO:
- Add normal and specular maps calculations in standard shader.
- Add control structs to handle which attributes needs to be calculated
(textures, specular...).
- Adapt standard shader to version 110.
- Rewrite standard shader as char pointers in rlgl.
- Ambient and lambert lighting added.
- Ambient and diffuse colors linked to standard shader.
- Single light linked to standard shader.
- LoadStandardMaterial() and depending functions added.
Now GLFW3 windows/context creation works ok and a sample red rectangle
has been drawn using rlgl. Next step is working in tracking
position/orientation maths and try to get a simple 3d scene...
- Renamed some functions for consistency (default buffers)
- Removed mystrdup() function (implemented inline)
- Renamed TextFileRead() to ReadTextFile()
This is an early draft, needs lots of work. Still need to figure out way
to calculate total length of song. This is hard because xm tracks stream
out zeros when done, only position in track can be found. Position does
not give any direct value of how much more time is left. I think that by
setting the loop count to 1 and seeking until the end I can total up the
number of samples and come up with a length.
NOTE: It requires a depth texture as input, it should be configured on
rlgl, by default RenderTexture (fbo) uses Depth Renderbuffer instead of
Depth Texture. Check rlglLoadRenderTexture()
Finally, physics update is handled in main thread using steps to get
accuracy in collisions detection instead of moving it to a new thread.
Examples are finished as simple and clear as I could. Finally, physac
module is MORE simpler than in the first version, calculation everything
by the same way for both types of physic objects.
I tryed to add rotated physics a couple of times but I didn't get
anything good to get a base to improve it. Maybe for the next version...
No bugs or strange behaviours found during testing.
physac module base almost finished. All collisions are now resolved
properly and some force functions was added.
COLLIDER_CAPSULE removed for now because in 2D everything is composed by
rectangle and circle colliders...
The last step is move physics update loop into another thread and update
it in a fixed time step based on fps.
If you have raylib on standard directories ("/usr/local/include/raylib/raylib.h" for the header and "/usr/local/lib/libraylib.a" for raylib library) you can compile without edit the makefile.
physac modules is being redesigned. Physics base behaviour is done and
it is composed by three steps: apply physics, resolve collisions and fix
overlapping.
A basic example is currently in progress. The next steps are try to add
torque and unoriented physic collisions and implement physics basic
functions to add forces. Rigidbody grounding state is automatically
calculated and has a perfect result. Rigidbodies interacts well with
each others.
To achieve physics accuracy, UpdatePhysics() is called a number of times
per frame. In a future, it should be changed to another thread and call
it without any target frame restriction.
Basic physics example has been redone (not finished) using the new
module functions. Forces examples will be redone so I removed it from
branch.
Those games have been developed by students and ported to a common base
template. Some of them still require some review to be consistent with
each other (formatting, variables naming, code structure...)
It seems that now works. Tested all free camera features with some
directions and positions and no unexpected behaviours detected. I don't
know if those lines are really indispensable.
- Fixed Android locking screen bug. OnDestroy() was called when locking
screen.
- Power button input must be handled by OS.
- AndroidManifest.xml is affected by configChanges="screenSize".
- Updated library header for android template.
Corrected Android processing for some inputs (BACK button, VOLUME
buttons)
Redesigned Gestures system (some work still required)
SetEnabledGestures() - Only support desired gestures (requires some
review)
- Added new physics engine-module with four new data types: Physics,
Transform, Rigidbody and Collider. This library contains functions to
apply physics calculations to a position vector calculating collisions
automatically.
- Fixed some writing mistakes of lighting module.
- New lighting engine module which contains new data types Light and
Material. These data types and functions facilitates making a basic 3D
iluminated program with a light and a model.
- Added lighting engine module example (currently included in raylib.h;
it might be compiled by separate and include lighting.h in game source C
file).
- Corrected some opengl defines control structures and added some TODO
to fix raylib-opengl 1.1 source build (note: now source can be compiled
without errors, but rlglReadPixels() won't work properly).
Note: most of functions of phong version 330 shader are not in v100
shaders, so I couldn't write a version 100 phong shader. These functions
are included from version 150.
- New model and view transformation matrix added, useful for shaders.
Modelview matrix not deleted to keep opengl 1.1 pipeline compatibility.
- New extra function added DrawModelWiresEx() to set a rotation and
scale transformations to a wire model drawing.
- Other writing and little audio.c bug fixed.
- Renamed function rlEnableFBO() -> rlEnablePostproFBO()
- Defined struct FBO
- Moved FBO creation to function: rlglLoadFBO()
- Reviewed rlglReadTexturePixels(), trying to support OpenGL ES -IN
PROGRESS-
- Camera system moved to a separate module [camera.c]
- WIP: Added customization functions for camera controls
- Added custom shaders support on batch drawing
- Complete redesign of textures module to support multiple texture
formats (compressed and uncompressed)
Moved functions: LoadShader(), UnloadShader()
Add support for PVR textures compressed/uncompressed
WIP: Detect available extensions for compressed textures
Support multiple texture formats (uncompressed and compressed)
Postprocessing shaders support
Model struct redefined and improved
Extended loading functions for Textures and Models
Simplified functions: DrawPlane(), DrawQuad()
Deleted functions: DrawPlaneEx(), DrawGizmoEx()
Now Text module only depends on Textures module
Shapes: Reviewed functions to low lines/triangles usage
Removed useless tabs and spaces around code
We have three vertex buffers: lines, triangles and quads for textures.
Drawing in a desired order could become a nighmare... noww it seems it
works prety well...
title: "[module] Short description of the issue/bug/feature"
labels: ''
assignees: ''
---
**WARNING: Please, read this note carefully before submitting a new issue:**
It is important to realise that **this is NOT A SUPPORT FORUM**, this is for reproducible BUGS with raylib ONLY.
There are lots of generous and helpful people ready to help you out on [raylib Discord forum](https://discord.gg/raylib) or [raylib reddit](https://www.reddit.com/r/raylib/).
Remember that asking for support questions here actively takes developer time away from improving raylib.
---
Please, before submitting a new issue verify and check:
- [ ] I tested it on latest raylib version from master branch
- [ ] I checked there is no similar issue already reported
- [ ] My code has no errors or misuse of raylib
### Issue description
*Briefly describe the issue you are experiencing (or the feature you want to see added to raylib). Tell us what you were trying to do and what happened instead. Remember, this is not the best place to ask questions. For questions, go to [raylib Discord server](https://discord.gg/raylib).*
### Environment
*Provide your Platform, Operating System, OpenGL version, GPU details where you experienced the issue.*
### Issue Screenshot
*If possible, provide a screenshot that illustrates the issue. Usually an image is better than a thousand words.*
### Code Example
*Provide minimal reproduction code to test the issue. Please, format the code properly and try to keep it as simple as possible, just focusing on the experienced issue.*
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.
### Language Bindings
| name | raylib version | language | license | repo |
| rayed-bqn | auto | [BQN](https://mlochbaum.github.io/BQN/) | MIT | https://github.com/Brian-ED/rayed-bqn |
### Utility Wrapers
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 |
enum_option(PLATFORM "Desktop;Web;Android;Raspberry Pi;DRM" "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?")
# Configuration options
option(BUILD_EXAMPLES "Build the examples." ${RAYLIB_IS_MAIN})
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_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)
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)
# 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_PNM "Support loading PNM 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)
Do you enjoy raylib and want to contribute? Nice! You can help with the following points:
-`C programming` - Can you write/review/test/improve the code?
-`Documentation/Tutorials/Example` - Can you write some tutorial/example?
-`Porting to other platforms` - Can you port/adapt/compile raylib on other systems?
-`Web Development` - Can you help [with the website](https://github.com/raysan5/raylib.com)?
-`Testing` - Can you find some bugs in raylib?
This document contains a set of guidelines to contribute to the project. These are mostly guidelines, not rules.
Use your best judgement, and feel free to propose changes to this document in a pull request.
### raylib philosophy
- raylib is a tool to **ENJOY** videogames programming, every function in raylib is designed as a mini-tutorial on itself.
- raylib is **SIMPLE** and **EASY-TO-USE**, I tried to keep it compact with a small set of functions, if a function is too complex, better not including it.
- raylib is open source and free; educators and institutions can use this tool to **TEACH** videogames programming completely for free.
- raylib is collaborative; contribution of tutorials / code examples / bug fixes / code comments are highly appreciated.
- raylib's license (and its external libs respective licenses) allow using raylib on commercial projects.
- Control flow statements always are followed **by a space**:
```c
if(condition)value=0;
while(!WindowShouldClose())
{
}
for(inti=0;i<NUM_VALUES;i++)printf("%i",i);
// Be careful with the switch formatting!
switch(value)
{
case0:
{
}break;
case2:break;
default:break;
}
```
- All conditions checks are **always between parenthesis** but not boolean values:
```c
if((value>1)&&(value<50)&&valueActive)
{
}
```
- When dealing with braces or curly brackets, open-close them in aligned mode:
```c
voidSomeFunction()
{
// TODO: Do something here!
}
```
**If proposing new functions, please try to use a clear naming for function-name and functions-parameters, in case of doubt, open an issue for discussion.**
## Files and Directories Naming Conventions
- Directories will be named using `snake_case`: `resources/models`, `resources/fonts`
- Files will be named using `snake_case`: `main_title.png`, `cubicmap.png`, `sound.wav`
_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).
- [What can I do with raylib?](#what-can-i-do-with-raylib)
- [Which kinds of games can I make with raylib?](#which-kinds-of-games-can-i-make-with-raylib)
- [Can I create non-game applications with raylib?](#can-i-create-non-game-applications-with-raylib)
- [How can I learn to use raylib? Is there some official documentation or tutorials?](#how-can-i-learn-to-use-raylib-is-there-some-official-documentation-or-tutorials)
- [How much does it cost?](#how-much-does-it-cost)
- [What is the raylib license?](#what-is-the-raylib-license)
- [What platforms are supported by raylib?](#what-platforms-are-supported-by-raylib)
- [What programming languages can I use with raylib?](#what-programming-languages-can-i-use-with-raylib)
- [Why is it coded in C?](#why-is-it-coded-in-c)
- [Is raylib a videogames engine?](#is-raylib-a-videogames-engine)
- [What does raylib provide that other engines or libraries don't?](#what-does-raylib-provide-that-other-engines-or-libraries-dont)
- [How does raylib compare to Unity/Unreal/Godot?](#how-does-raylib-compare-to-unityunrealgodot)
- [What development tools are required for raylib?](#what-development-tools-are-required-for-raylib)
- [Which are raylib external dependencies?](#which-are-raylib-external-dependencies)
- [Can I use raylib with other technologies or libraries?](#can-i-use-raylib-with-other-technologies-or-libraries)
- [What file formats are supported by raylib?](#what-file-formats-are-supported-by-raylib)
- [Does raylib support the Vulkan API?](#does-raylib-support-the-vulkan-api)
- [What could I expect to see in raylib in the future?](#what-could-i-expect-to-see-in-raylib-in-the-future)
- [Who are the raylib developers?](#who-are-the-raylib-developers)
### What is raylib?
raylib is a C programming library, designed to be simple and easy-to-use. It provides a set of functions intended for graphics/multimedia applications programming.
### What can I do with raylib?
raylib can be used to create any kind of graphics/multimedia applications: videogames, tools, mobile apps, web applications... Actually it can be used to create any application that requires something to be shown in a display with graphic hardware acceleration (OpenGL); including [IoT](https://en.wikipedia.org/wiki/Internet_of_things) devices with a graphics display.
### Which kinds of games can I make with raylib?
With enough time and effort any kind of game/application can be created but small-mid sized 2d videogames are the best fit. The raylib [examples](https://www.raylib.com/examples.html)/[games](https://www.raylib.com/games.html) and [raylibtech](https://raylibtech.itch.io/) tools are an example of what can be accomplished with raylib.
### Can I create non-game applications with raylib?
Yes, raylib can be used to create any kind of application, not just videogames. For example, it can be used to create [desktop/web tools](https://raylibtech.itch.io/) or also applications for an IoT devices like [Raspberry Pi](https://www.raspberrypi.org/).
### 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 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.
[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.
### How much does it cost?
raylib is [free and open source](https://github.com/raysan5/raylib). Anyone can use raylib library for free to create games/tools/apps but also the source code of raylib is open for anyone to check it, modify it, adapt it as required or just learn how it works internally.
### 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 closed source software. Check [LICENSE](https://github.com/raysan5/raylib/blob/master/LICENSE) for further details.
### What platforms are supported by raylib?
raylib source code can be compiled for the following platforms:
- Windows (7, 8.1, 10, 11)
- Linux - Desktop (multiple distributions, X11 and Wayland based)
- Linux - Native (no windowing system, [DRM](https://en.wikipedia.org/wiki/Direct_Rendering_Manager))
- macOS (multiple versions, including ARM64)
- FreeBSD, OpenBSD, NetBSD, DragonFly
- Raspberry Pi (desktop and native)
- Android (multiple API versions and architectures)
- HTML5 (WebAssembly)
- Haiku
raylib code has also been ported to several [homebrew](https://en.wikipedia.org/wiki/Homebrew_(video_games)) platforms: N3DS, Switch, PS4, PSVita.
Also note that raylib is a low-level library that can be easily ported to any platform with OpenGL support (or similar API).
### What programming languages can I use with raylib?
raylib original version is coded in C language (using some C99 features) but it has bindings to +60 programming languages. Check [BINDINGS.md](https://github.com/raysan5/raylib/blob/master/BINDINGS.md) for details.
### Why is it coded in C?
It's a simple language, no high-level code abstractions like [OOP](https://en.wikipedia.org/wiki/Object-oriented_programming), just data types and functions. It's a very enjoyable language to code.
### Is raylib a videogames engine?
I personally consider raylib a graphics library with some high-level features rather than an engine. The line that separates a library/framework from an engine could be very confusing; raylib provides all the required functionality to create simple games or small applications but it does not provide 3 elements that I personally consider any "engine" should provide: Screen manager, GameObject/Entity manager and Resource Manager. Still, most users do not need those elements or just code simple approaches on their own.
### 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.
### 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.
### 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.
### 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.
A detailed list of raylib dependencies could be found on the [raylib Wiki](https://github.com/raysan5/raylib/wiki/raylib-dependencies).
### Can I use raylib with other technologies or libraries?
Yes, raylib can be used with other libraries that provide specific functionality. There are multiple examples of raylib integrations with libraries like Spine, Tiled, Dear Imgui and several physics engines.
### What file formats are supported by raylib?
raylib can load data from multiple standard file formats:
No, raylib is built on top of OpenGL API, and there are currently no plans to support any other graphics APIs. In any case, raylib uses rlgl as an abstraction layer to support different OpenGL versions. If really required, a Vulkan backend equivalent could be added but creating that abstraction layer would imply a considerable amount of work.
### 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.
### 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 full list of raylib contributors can be seen [on GitHub](https://github.com/raysan5/raylib/graphs/contributors).
I’m working hard on raylib but my resources are quite limited. If you enjoy raylib and want to help / contribute in some way,
please, [let me know][raysan5].
The following help is highly appreciated:
- C programming - Can you write / review / test / improve the code?
- Translators / Localizators - Can you translate raylib to another language?
- Documentation / Tutorials / Example writters - Can you write some tutorial / example?
- Web Development - Can you help with the web? Can you setup a forum?
- Porting to Linux and OSX - Can you compile and test raylib on another OS?
- Testers of current features and multiple systems - Can you find some bug on raylib?
If you can not help on any of the above points but you still want to contribute in some way... please, consider helping
with a small [donation](http://www.raylib.com/helpme.htm) (just some euros...). It will really motivate to continue improving this project (and pay some bills… or some coffee).
raylib philosophy
------------------
* raylib is a tool to LEARN videogames programming, every single function in raylib should be a tutorial on itself.
* raylib is SIMPLE and EASY-TO-USE, I tried to keep it compact with a small set of functions, if a function is too complex or
has not a clear usefulness, better not to include it.
* raylib is open source and free; educators and institutions can use this tool to TEACH videogames programming completely by free.
* raylib is, hopefully, collaborative; contribution of tutorials / code-examples / bugs-solving / code-comments are highly appreciated.
* raylib's license (and its external libs respective licenses) allow using it for commercial products.
I 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 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!
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.
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.
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.
raylib started as a weekend project and after three months of hard work, **raylib 1.0 was published on November 2013**.
Enjoy it.
notes on raylib 1.1
-------------------
On April 2014, after 6 month of first raylib release, raylib 1.1 has been released. This new version presents a complete internal redesign of the library to support OpenGL 1.1, OpenGL 3.3+ and OpenGL ES 2.0.
- A new module named [rlgl](https://github.com/raysan5/raylib/blob/master/src/rlgl.h) has been added to the library. This new module translates raylib-OpenGL-style immediate mode functions (i.e. rlVertex3f(), rlBegin(), ...) to different versions of OpenGL (1.1, 3.3+, ES2), selectable by one define.
- [rlgl](https://github.com/raysan5/raylib/blob/master/src/rlgl.h) also comes with a second new module named [raymath](https://github.com/raysan5/raylib/blob/master/src/raymath.h), which includes a bunch of useful functions for 3d-math with vectors, matrices and quaternions.
Some other big changes of this new version have been the support for OGG files loading and stream playing, and the support of DDS texture files (compressed and uncompressed) along with mipmaps support.
Lots of code changes and lot of testing have concluded in this amazing new raylib 1.1.
notes on raylib 1.2
-------------------
On September 2014, after 5 month of raylib 1.1 release, it comes raylib 1.2. Again, this version presents a complete internal redesign of [core](https://github.com/raysan5/raylib/blob/master/src/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.
- A new display initialization system has been created to support multiple resolutions, adding black bars if required; user only defines desired screen size and it gets properly displayed.
- Now raylib can easily deploy games to Android devices and Raspberry Pi (console mode).
Lots of code changes and lot of testing have concluded in this amazing new raylib 1.2.
In December 2014, new raylib 1.2.2 was published with support to compile directly for web (html5) using [emscripten](http://kripken.github.io/emscripten-site/) and [asm.js](http://asmjs.org/).
notes on raylib 1.3
-------------------
On September 2015, after 1 year of raylib 1.2 release, arrives raylib 1.3. This version adds shaders functionality, improves tremendously textures module and also provides some new modules (camera system, gestures system, immediate-mode gui).
- Shaders support is the biggest addition to raylib 1.3, with support for easy shaders loading and use. Loaded shaders can be attached to 3d models or used as fullscreen postrocessing effects. A bunch of postprocessing shaders are also included in this release, check raylib/shaders folder.
- Textures module has grown to support most of the internal texture formats available in OpenGL (RGB565, RGB888, RGBA5551, RGBA4444, etc.), including compressed texture formats (DXT, ETC1, ETC2, ASTC, PVRT); raylib 1.3 can load .dds, .pkm, .ktx, .astc and .pvr files.
- A brand new [camera](https://github.com/raysan5/raylib/blob/master/src/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).
- 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.
Most of the examples have been completely rewritten and +10 new examples have been added to show the new raylib features.
Lots of code changes and lot of testing have concluded in this amazing new raylib 1.3.
notes on raylib 1.4
-------------------
On February 2016, after 4 months of raylib 1.3 release, it comes raylib 1.4. For this new version, lots of parts of the library have been reviewed, lots of bugs have been solved and some interesting features have been added.
- First big addition is a set of [Image manipulation functions](https://github.com/raysan5/raylib/blob/master/src/raylib.h#L673) have been added to crop, resize, colorize, flip, dither and even draw image-to-image or text-to-image. Now a basic image processing can be done before converting the image to texture for usage.
- SpriteFonts system has been improved, adding support for AngelCode fonts (.fnt) and TrueType Fonts (using [stb_truetype](https://github.com/nothings/stb/blob/master/stb_truetype.h) helper library). Now raylib can read standard .fnt font data and also generate at loading a SpriteFont from a TTF file.
- New [physac](https://github.com/raysan5/raylib/blob/master/src/physac.h) physics module for basic 2D physics support. Still in development but already functional. Module comes with some usage examples for basic jump and level interaction and also force-based physic movements.
- [raymath](https://github.com/raysan5/raylib/blob/master/src/raymath.h) module has been reviewed; some bugs have been solved and the module has been converted to a header-only file for easier portability, optionally, functions can also be used as inline.
- [gestures](https://github.com/raysan5/raylib/blob/master/src/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.
- Raspberry Pi input system has been redesigned to better read raw inputs using generic Linux event handlers (keyboard:`stdin`, mouse:`/dev/input/mouse0`, gamepad:`/dev/input/js0`). Gamepad support has also been added (experimental).
Other important improvements are the functional raycast system for 3D picking, including some ray collision-detection functions,
and the addition of two simple functions for persistent data storage. Now raylib user can save and load game data in a file (only some platforms supported). A simple [easings](https://github.com/raysan5/raylib/blob/master/src/easings.h) module has also been added for values animation.
Up to 8 new code examples have been added to show the new raylib features and +10 complete game samples have been provided to learn
how to create some classic games like Arkanoid, Asteroids, Missile Commander, Snake or Tetris.
Lots of code changes and lots of hours of hard work have concluded in this amazing new raylib 1.4.
notes on raylib 1.5
-------------------
On July 2016, after 5 months of raylib 1.4 release, arrives raylib 1.5. This new version is the biggest boost of the library until now, lots of parts of the library have been redesigned, lots of bugs have been solved and some **AMAZING** new features have been added.
- VR support: raylib supports **Oculus Rift CV1**, one of the most anticipated VR devices in the market. Additionally, raylib supports simulated VR stereo rendering, independent of the VR device; it means, raylib can generate stereo renders with custom head-mounted-display device parameteres, that way, any VR device in the market can be **simulated in any platform** just configuring device parameters (and consequently, lens distortion). To enable VR is [extremely easy](https://github.com/raysan5/raylib/blob/master/examples/core_oculus_rift.c).
- New materials system: now raylib supports standard material properties for 3D models, including diffuse-ambient-specular colors and diffuse-normal-specular textures. Just assign values to standard material and everything is processed internally.
- New lighting system: added support for up to 8 configurable lights and 3 light types: **point**, **directional** and **spot** lights. Just create a light, configure its parameters and raylib manages render internally for every 3d object using standard material.
- Complete gamepad support on Raspberry Pi: Gamepad system has been completely redesigned. Now multiple gamepads can be easily configured and used; gamepad data is read and processed in raw mode in a second thread.
- Redesigned physics module: [physac](https://github.com/raysan5/raylib/blob/master/src/physac.h) module has been converted to header only and usage [has been simplified](https://github.com/raysan5/raylib/blob/master/examples/physics_basic_rigidbody.c). Performance has also been singnificantly improved, now physic objects are managed internally in a second thread.
- Audio chiptunese support and mixing channels: Added support for module audio music (.xm, .mod) loading and playing. Multiple mixing channels are now also supported. All this features thanks to the amazing work of @kd7tck.
Other additions include a [2D camera system](https://github.com/raysan5/raylib/blob/master/examples/core_2d_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.
This new version is so massive that is difficult to list all the improvements, most of raylib modules have been reviewed and [rlgl](https://github.com/raysan5/raylib/blob/master/src/rlgl.c) module has been completely redesigned to accomodate to new material-lighting systems and stereo rendering. You can check [CHANGELOG](https://github.com/raysan5/raylib/blob/master/CHANGELOG) file for a more detailed list of changes.
Up to 8 new code examples have been added to show the new raylib features and also some samples to show the usage of [rlgl](https://github.com/raysan5/raylib/blob/master/examples/rlgl_standalone.c) and [audio](https://github.com/raysan5/raylib/blob/master/examples/audio_standalone.c) raylib modules as standalone libraries.
Lots of code changes (+400 commits) and lots of hours of hard work have concluded in this amazing new raylib 1.5.
notes on raylib 1.6
-------------------
On November 2016, only 4 months after raylib 1.5, arrives raylib 1.6. This new version represents another big review of the library and includes some interesting additions. This version conmmemorates raylib 3rd anniversary (raylib 1.0 was published on November 2013) and it is a stepping stone for raylib future. raylib roadmap has been reviewed and redefined to focus on its primary objective: create a simple and easy-to-use library to learn videogames programming. Some of the new features:
- Complete [raylib Lua binding](https://github.com/raysan5/raylib-lua). All raylib functions plus the +60 code examples have been ported to Lua, now Lua users can enjoy coding videogames in Lua while using all the internal power of raylib. This addition also open the doors to Lua scripting support for a future raylib-based engine, being able to move game logic (Init, Update, Draw, De-Init) to Lua scripts while keep using raylib functionality.
- Completely redesigned [audio module](https://github.com/raysan5/raylib/blob/master/src/raudio.c). Based on the new direction taken in raylib 1.5, it has been further improved and more functionality added (+20 new functions) to allow raw audio processing and streaming. [FLAC file format support](https://github.com/raysan5/raylib/blob/master/src/external/dr_flac.h) has also been added. In the same line, [OpenAL Soft](https://github.com/kcat/openal-soft) backend is now provided as a static library in Windows to allow static linking and get ride of OpenAL32.dll. Now raylib Windows games are completey self-contained, no external libraries required any more!
- [Physac](https://github.com/victorfisac/Physac) module has been moved to its own repository and it has been improved A LOT, actually, library has been completely rewritten from scratch by [@victorfisac](https://github.com/victorfisac), multiple samples have been added together with countless new features to match current standard 2D physic libraries. Results are amazing!
- Camera and gestures modules have been reviewed, highly simplified and ported to single-file header-only libraries for easier portability and usage flexibility. Consequently, camera system usage has been simplified in all examples.
- Improved Gamepad support on Windows and Raspberry Pi with the addition of new functions for custom gamepad configurations but supporting by default PS3 and Xbox-based gamepads.
- Improved textures and text functionality, adding new functions for texture filtering control and better TTF/AngelCode fonts loading and generation support.
Build system improvement. Added support for raylib dynamic library generation (raylib.dll) for users that prefer dynamic library linking. Also thinking on advance users, it has been added pre-configured [Visual Studio C++ 2015 solution](https://github.com/raysan5/raylib/tree/master/project/vs2015) with raylib project and C/C++ examples for users that prefer that professional IDE and compiler.
New examples, new functions, complete code-base review, multiple bugs corrected... this is raylib 1.6. Enjoy making games.
notes on raylib 1.7
-------------------
On May 2017, around 6 month after raylib 1.6, comes another raylib instalment, raylib 1.7. This time library has been improved a lot in terms of consistency and cleanness. As stated in [this patreon article](https://www.patreon.com/posts/raylib-future-7501034), this new raylib version has focused efforts in becoming more simple and easy-to-use to learn videogames programming. Some highlights of this new version are:
- More than 30 new functions added to the library, functions to control Window, utils to work with filenames and extensions, functions to draw lines with custom thick, mesh loading, functions for 3d ray collisions detailed detection, funtions for VR simulation and much more... Just check [CHANGELOG](CHANGELOG) for a detailed list of additions!
- Support of [configuration flags](https://github.com/raysan5/raylib/issues/200) on every raylib module. Advance users can customize raylib just choosing desired features, defining some configuration flags on modules compilation. That way users can control library size and available functionality.
- Improved [build system](https://github.com/raysan5/raylib/blob/master/src/Makefile) for all supported platforms (Windows, Linux, OSX, RPI, Android, HTML5) with a unique Makefile to compile sources. Added support for Android compilation with a custom standalone toolchain and also multiple build compliation flags.
- New [examples](http://www.raylib.com/examples.html) and [sample games](http://www.raylib.com/games.html) added. All samples material has been reviewed, removing useless examples and adding more comprehensive ones; all material has been ported to latest raylib version and tested in multiple platforms. Examples folder structure has been improved and also build systems.
- Improved library consistency and organization in general. Functions and parameters have been renamed, some parts of the library have been cleaned and simplyfied, some functions has been moved to examples (lighting, Oculus Rift CV1 support) towards a more generic library implementation. Lots of hours have been invested in this process...
Some other features: Gamepad support on HTML5, RPI touch screen support, 32bit audio support, frames timing improvements, public log system, rres file format support, automatic GIF recording...
And here it is another version of **raylib, a simple and easy-to-use library to enjoy videogames programming**. Enjoy it.
notes on raylib 1.8
-------------------
October 2017, around 5 months after latest raylib version, another release is published: raylib 1.8. Again, several modules of the library have been reviewed and some new functionality added. Main changes of this new release are:
- [Procedural image generation](https://github.com/raysan5/raylib/blob/master/examples/textures/textures_image_generation.c) function, a set of new functions have been added to generate gradients, checked, noise and cellular images from scratch. Image generation could be useful for certain textures or learning pourpouses.
- [Parametric mesh generation](https://github.com/raysan5/raylib/blob/master/examples/models/models_mesh_generation.c) functions, create 3d meshes from scratch just defining a set of parameters, meshes like cube, sphere, cylinder, torus, knot and more can be very useful for prototyping or for lighting and texture testing.
- PBR Materials support, a completely redesigned shaders and material system allows advance materials definition and usage, with fully customizable shaders. Some new functions have been added to generate the environment textures required for PBR shading and a a new complete [PBR material example](https://github.com/raysan5/raylib/blob/master/examples/models/models_material_pbr.c) is also provided for reference.
- Custom Android APK build pipeline with [simple Makefile](https://github.com/raysan5/raylib/blob/master/templates/simple_game/Makefile). Actually, full code building mechanism based on plain Makefile has been completely reviewed and Android building has been added for sources and also for examples and templates building into final APK package. This way, raylib Android building has been greatly simplified and integrated seamlessly into standard build scripts.
- [rlgl](https://github.com/raysan5/raylib/blob/master/src/rlgl.h) module has been completely reviewed and most of the functions renamed for consistency. This way, standalone usage of rlgl is promoted, with a [complete example provided](https://github.com/raysan5/raylib/blob/master/examples/others/rlgl_standalone.c). rlgl offers a pseudo-OpenGL 1.1 immediate-mode programming-style layer, with backends to multiple OpenGL versions.
- [raymath](https://github.com/raysan5/raylib/blob/master/src/raymath.h) library has been also reviewed to align with other advance math libraries like [GLM](https://github.com/g-truc/glm). Matrix math has been improved and simplified, some new Quaternion functions have been added and Vector3 functions have been renamed all around the library for consistency with new Vector2 functionality.
Additionally, as always, examples and templates have been reviewed to work with new version (some new examples have been added), all external libraries have been updated to latest stable version and latest Notepad++ and MinGW have been configured to work with new raylib. For a full list of changes, just check [CHANGELOG](CHANGELOG).
New installer provided, web updated, examples re-builded, documentation reviewed... **new raylib 1.8 published**. Enjoy coding games.
notes on raylib 2.0
-------------------
It's been 9 month since last raylib version was published, a lots of things have changed since then... This new raylib version represents an inflexion point in the development of the library and so, we jump to a new major version... Here it is the result of almost **5 years and thousands of hours of hard work**... here it is... **raylib 2.0**
In **raylib 2.0** the full API has been carefully reviewed for better consistency, some new functionality has been added and the overall raylib experience has been greatly improved... The key features of new version are:
- **Complete removal of external dependencies.** Finally, raylib does not require external libraries to be installed and linked along with raylib, all required libraries are contained and compiled within raylib. Obviously some external libraries are required but only the strictly platform-dependant ones, the ones that come installed with the OS. So, raylib becomes a self-contained platform-independent games development library.
- **Full redesign of audio module to use the amazing miniaudio library**, along with external dependencies removal, OpenAL library has been replaced by [miniaudio](https://github.com/dr-soft/miniaudio), this brand new library offers automatic dynamic linking with default OS audio systems. Undoubtly, the perfect low-level companion for raylib audio module!
- **Support for continuous integration building*** through AppVeyor and Travis CI. Consequently, raylib GitHub develop branch has been removed, simplyfing the code-base to a single master branch, always stable. Every time a new commit is deployed, library is compiled for **up-to 12 different configurations**, including multiple platforms, 32bit/64bit and multiple compiler options! All those binaries are automatically attached to any new release!
- **More platforms supported and tested**, including BSD family (FreeBSD, openBSD, NetBSD, DragonFly) and Linux-based family platforms (openSUSE, Debian, Ubuntu, Arch, NixOS...). raylib has already been added to some package managers! Oh, and last but not less important, **Android 64bit** is already supported by raylib!
- **Support for TCC compiler!** Thanks to the lack of external dependencies, raylib can now be easily compiled with a **minimal toolchain**, like the one provide by Tiny C Compiler. It opens the door to an amazing future, allowing, for example, static linkage of libtcc for **runtime compilation of raylib-based code**... and the library itself if required! Moreover, TCC is blazing fast, it can compile all raylib in a couple of seconds!
- Refactored all raylib configuration #defines into a **centralized `config.h` header**, with more than **40 possible configuration options** to compile a totally customizable raylib version including only desired options like supported file-formats or specific functionality support. It allows generating a trully ligth-weight version of the library if desired!
A part of that, lots of new features, like a brand **new font rendering and packaging system** for TTF fonts with **SDF support** (thanks to the amazing STB headers), new functions for **CPU image data manipulation**, new orthographic 3d camera mode, a complete review of `raymath.h` single-file header-only library for better consistency and performance, new examples and way, [way more](https://github.com/raysan5/raylib/blob/master/CHANGELOG).
Probably by now, **raylib 2.0 is the simplest and easiest-to-use library to enjoy (and learn) videogames programming**... but, undoubtly its development has exceeded any initial objective; raylib has become a simple and easy-to-use trully multiplatform portable standalone media library with thousands of possibilities... and that's just the beginning!
notes on raylib 2.5
-------------------
After almost one years since latest raylib installment, here it is **raylib 2.5**. A lot of work has been put on this new version and consequently I decided to bump versioning several digits. The complete list of changes and additions is humungous, details can be found in the [CHANGELOG](CHANGELOG), and here it is a short recap with the highlight improvements.
- New **window management and 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.
- **VR simulator** has been reviewed to **allow custom configuration of Head-Mounted-Device parameters and distortion shader**, `core_vr_simulator` has been properly adapted to showcase this new functionality, now the VR simulator is a generic configurable stereo rendering system that allows any VR device simulation with just a few lines of code or even dynamic tweaking of HMD parameters.
- Support for **Unicode text drawing**; now raylib processes UTF8 strings on drawing, supporting Unicode codepoints, allowing rendering mostly any existent language (as long as the font with the glyphs is provided). An amazing example showing this feature has also been added: `text_unicode`.
- Brand **new text management API**, with the addition of multiple functions to deal with string data, including functionality like replace, insert, join, split, append, to uppercase, to lower... Note that most of those functions are intended for text management on rendering, using pre-loaded internal buffers, avoiding new memory allocation that user should free manually.
- Multiple **new shapes and textures drawing functions** to support rings (`DrawRing()`, `DrawRingLines()`), circle sectors (`DrawCircleSector()`, `DrawCircleSectorLines()`), rounded rectangles (`DrawRectangleRounded()`, `DrawRectangleRoundedLines()`) and also n-patch textures (`DrawTextureNPatch()`), detailed examples have been added to illustrate all this new functionality.
- Experimental **cubemap support**, to automatically load multiple cubemap layouts (`LoadTextureCubemap()`). It required some internal `rlgl` redesign to allow cubemap textures.
- **Skeletal animation support for 3d models**, this addition implied a redesign of `Model` data structure to accomodate multiple mesh/multiple materials support and bones information. Multiple models functions have been reviewed and added on this process, also **glTF models loading support** has been added.
This is a just a brief list with some of the changes of the new **raylib 2.5** but there is way more, about **70 new functions** have been added and several subsystems have been redesigned. More than **30 new examples** have been created to show the new functionalities and better illustrate already available ones.
It has been a long year of hard work to make raylib a solid technology to develop new products over it.
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).
- 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 **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 **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.
-`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).
-`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.
- **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.
- New **GitHub Actions CI** system has been implemented for Windows, Linux and macOS code and examples compilation on every new commit or PR to make sure library keeps stable and usable with no breaking bugs.
Note that only key changes are listed here but there is way more! About **30 new functions**, multiple functions reviewed, bindings to [+40 programming languages](https://github.com/raysan5/raylib/blob/master/BINDINGS.md) and great samples/demos/tutorials [created by the community](https://discord.gg/raylib), including raylib integration with [Spine](https://github.com/WEREMSOFT/spine-raylib-runtimes), [Unity](https://unitycoder.com/blog/2019/12/09/using-raylib-dll-in-unity/), [Tiled](https://github.com/OnACoffeeBreak/raylib_tiled_import_with_tmx), [Nuklear](http://bedroomcoders.co.uk/implementing-a-3d-gui-with-raylib/), [enet](https://github.com/nxrighthere/NetDynamics) and [more](https://github.com/raysan5/raylib/issues/1079)!
It has been **10 months of improvements** to create the best raylib ever.
Welcome to **raylib 3.0**.
notes on raylib 3.5 - 7th Anniversary Edition
---------------------------------------------
It's December 25th... this crazy 2020 is about to finish and finally the holidays gave me some time to put a new version of raylib. It's been **9 months since last release** and last November raylib become 7 years old... I was not able to release this new version back then but here it is. Many changes and improvements have happened in those months and, even, last August, raylib was awarded with an [Epic Megagrant](https://www.unrealengine.com/en-US/blog/epic-megagrants-fall-2020-update)! Bindings list kept growing to [+50 programming languages](BINDINGS.md) and some new platforms have been supported. Let's see this new version details:
First, some general numbers of this new update:
- **+650** commits since previous RELEASE
- **+30** functions ADDED (for a TOTAL of **475**!)
- **+90** functions REVIEWED/REDESIGNED
- **+30** contributors (for a TOTAL of **170**!)
- **+8** new examples (for a TOTAL of **+120**!)
Here the list with some highlights for `raylib 3.5`.
- NEW **Platform** supported: **Raspberry Pi 4 native mode** (no X11 windows) through [DRM](https://en.wikipedia.org/wiki/Direct_Rendering_Manager) subsystem and GBM API. Actually this is a really interesting improvement because it opens the door to raylib to support other embedded platforms (Odroid, GameShell, NanoPi...). Also worth mentioning the un-official homebrew ports of raylib for [PS4](https://github.com/orbisdev/orbisdev-orbisGl2) and [PSVita](https://github.com/psp2dev/raylib4Vita).
- 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 **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 **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.
- 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 **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.
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!
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:
Let's start with some numbers:
- **+100** closed issues (for a TOTAL of **+900**!)
- **+400** commits since previous RELEASE
- **+50** functions ADDED (**+30** of them to rlgl API)
- **+30** functions REVIEWED/REDESIGNED
- **+40** new contributors (for a TOTAL of **+210**!)
Highlights for `raylib 3.7`:
- **REDESIGNED: `rlgl` module for greater abstraction level**. This suppose an **important change in raylib architecture**, now `rlgl` functionality is self-contained in the module and used by higher-level layers (specially by `core` module), those upper layers are the ones that expose functionality to the main API when required, for example the `Shaders`, `Mesh` and `Materials` functionality. Multiple `rlgl` functions have been renamed for consistency, in this case, following the `rl*()` prefix convention. Functions have also been reorganized internally by categories and `GenTexture*()` functions have been removed from the library and moved to [`models_material_pbr`](https://github.com/raysan5/raylib/blob/master/examples/models/models_material_pbr.c) example.
- **REDESIGNED: VR simulator and stereo rendering mechanism**. A **brand new API** has been added, more comprehensive and better integrated with raylib, the **new stereo rendering** can be combined with `RenderTexture` and `Shader` API allowing the user to **manage fbo and distortion shader directly**. Also, the new rendering mechanism supports **instancing on stereo rendering**! Check the updated [`core_vr_simulator`](https://github.com/raysan5/raylib/blob/master/examples/core/core_vr_simulator.c) example for reference!
- **ADDED: New file access callbacks system**. Several new callback functions have been added to the API to allow custom file loaders. A [nice example](https://github.com/RobLoach/raylib-physfs) it's the **raylib integration with a virtual file system** [PhysFS](https://icculus.org/physfs/).
- **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.
- **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!
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 long term version (LTS), stable and complete enough for any new graphic/game/tool application development.
Let's start with some numbers:
- **+130** closed issues (for a TOTAL of **+1030**!)
- **+550** commits since previous RELEASE
- **+20** functions ADDED to raylib API
- **+60** functions ADDED to rlgl API
- **+40** functions RENAMED/REVIEWED/REDESIGNED
- **+60** new contributors (for a TOTAL of **+275**!)
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.
- **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.
- **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.
- [**`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**.
- [**`raymath 1.5`**](https://github.com/raysan5/raylib/blob/master/src/raymath.h): This module has been reviewed and some new conventions have been adopted to make it **more portable and self-contained**:
- Functions are self-contained, no function use other raymath function inside, required code is directly re-implemented
- Functions input parameters are always received by value
- Functions use always a "result" variable for return
- Angles are always in radians (`DEG2RAD`/`RAD2DEG` macros provided for convenience)
- [**`raygui 3.0`**](https://github.com/raysan5/raygui): The **official raylib immediate-mode gui library** (included in `raylib/src/extras`) has been updated to a new version, embedding the icons collection and adding mulstiple improvements. It has been simplified and constrained for a better focus on its task: provide a simple and easy-to-use immediate-mode-gui library for small tools development.
- [**`raylib_parser`**](https://github.com/raysan5/raylib/tree/master/parser): Added **new tool to parse `raylib.h`** and tokenize its enums, structs and functions, extracting all required info (name, params, descriptions...) into custom output formats (TXT, XML, JSON...) for further processing. This tool is specially useful to **automatize bindings generation**. Hopefully, this tool will make life easier to binding creators to update their bindings for raylib 4.0 or adding new ones!
- **Zig and Odin official support for raylib**: Those two new amazing programming languages are officially supporting raylib, `Zig` lists raylib as an [official example for C interoperatibility](https://ziglang.org/learn/samples/#c-interoperability) and Odin [officially supports raylib as a vendor library](https://github.com/odin-lang/Odin/tree/master/vendor/raylib). Both languages also have several bingings to raylib. Additionally, Zig build system supported has been added to compile raylib library and examples.
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! :)
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!
Some numbers to start with:
- **+200** closed issues (for a TOTAL of **1230**!)
- **+540** commits since previous RELEASE (for a TOTAL of **+6000**!)
- **+20** functions ADDED to raylib API (for a TOTAL of **502**!)
- **+60** functions REVIEWED/REDESIGNED
- **+70** new contributors (for a TOTAL of **+360**!)
Highlights for `raylib 4.2`:
- **raylib extra libraries cleanup**: raylib has been on diet and all the _extra_ libraries included on previous releases have been removed from raylib. Now raylib only includes the original **7** raylib modules: `rcore`, `rlgl`, `rshapes`, `rtextures`, `rtext`, `rmodels` and `raudio`. But no worries, _extra_ libraries have not been deleted, they have been moved to their own repos for better maintainability and more focus on its functionality. The libraries moved out from raylib repo are: [`raygui`](https://github.com/raysan5/raygui), [`physac`](https://github.com/raysan5/physac), [`rmem`](https://github.com/raylib-extras/rmem), [`reasings`](https://github.com/raylib-extras/reasings) and [`raudio`](https://github.com/raysan5/raudio) (standalone mode). On that same line, a new **amazing GitHub group:** [`raylib-extras`](https://github.com/raylib-extras) has been created by @JeffM2501 to contain raylib extra libraries as well as other raylib add-ons provided by the community. Jeff has done an amazing work on that line, providing multiple libraries and examples for raylib, like [custom first-person and third person camera systems](https://github.com/raylib-extras/extras-c/tree/main/cameras), [Dear ImGui raylib integration](https://github.com/raylib-extras/rlImGui), [multiple specific examples](https://github.com/raylib-extras/examples-c) and even a complete [RPG Game Example](https://github.com/raylib-extras/RPGExample)! Great work Jeff! :D
- **raylib examples review**: The +120 raylib examples have been reviewed to add clearer information about when the were first created (raylib version used) and when they were updated for the last time. But the greatest improvement for users has been the **addition of an estimated difficulty level** for every example, [web has been updated accordingly](https://www.raylib.com/examples.html) to reflect those difficulty levels. Now examples are classified with **1 to 4 stars** depending on difficulty to help users with their learning process. Personally, I think this "small" addition could be a game-changer to better guide new users on the library adoption! Additionally, this new raylib release includes 7 new examples; the most interesting one: [`text_codepoints_loading`](https://www.raylib.com/examples/text/loader.html?name=text_codepoints_loading) that illustrates how to load and draw custom codepoints from a font file, very useful for Asian languages.
- [**`rres 1.0`**](https://github.com/raysan5/rres): New `rres`**resources packaging file-format**, including a [`rres-raylib`](https://github.com/raysan5/rres/blob/master/src/rres-raylib.h) library implementation and [`rrespacker`](https://raylibtech.itch.io/rrespacker) tool. `rres` file format has been [under development for +8 years](https://github.com/raysan5/rres#design-history) and it was originally created to be part of raylib. It was highly inspired by _XNA XNB_ resources file format but design has changed a lot along the years. This first release of the format specs is engine-agnostic and has been designed to be portable to any engine, including lots of professional features like data processing, compression and encryption.
- [**`raygui 3.2`**](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 4.2. Multiple controls have been reviewed for library consistency, now all controls follow a similar function signature. It has been battle-tested with the development of +8 published tools in the last months. 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.
- [**`raylib_parser`**](https://github.com/raysan5/raylib/tree/master/parser): Multiple contributors **using the tool to automatize bindings creation** have contributed with improvements of this **tool to parse `raylib.h`** (and other raylib-style headers) to tokenize its enums, structs and functions. Processed data can be exported to custom file formats (i.e XML, JSON, LUA) for bindings generation or even docs generation if required.
- **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.
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 it 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 advance 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 themselfs.
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**.
**raylib is a simple and easy-to-use library to enjoy videogames programming.**
raylib is a simple and easy-to-use library to learn videogames programming.
raylib is highly inspired by Borland BGI graphics lib and by XNA framework and it's specially well suited for prototyping, tooling, graphical applications, embedded systems and education.
raylib is highly inspired by Borland BGI graphics lib (more specifically WinBGI) and by XNA framework.
Allegro and SDL have also been analyzed for reference.
*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.*
Want to see how easy is making games with raylib? Jump to [code examples!] (http://www.raylib.com/examples.htm)
Ready to learn? Jump to [code examples!](https://www.raylib.com/examples.html)
history
-------
---
I've developed videogames for some years and last year I had to taught videogames development
to young people with artistic profile, most of them had never written a single line of code.
<br>
I started with C language basis and, after searching for the most simple and easy-to-use library to teach
videogames programming, I found WinBGI; it was great and it worked very well with students, in just a
couple of weeks that people that had never written a single line of code were able to program (and understand)
[](https://github.com/raysan5/raylib/commits/master)
- **Full 3D support**, including 3D Shapes, Models, Billboards, Heightmaps and more!
- Flexible Materials system, supporting classic maps and **PBR maps**
- **Animated 3D models** supported (skeletal bones animation) (IQM)
- Shaders support, including model 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)
- **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 [+60 programming languages](https://github.com/raysan5/raylib/blob/master/BINDINGS.md)!
- **Free and open source**.
* Written in plain C code (C99)
* Uses C# PascalCase/camelCase notation
* Hardware accelerated using OpenGL 1.1
* Transparencies support (RGBA Colors)
* Custom color palette for better use on white background
* Basic 3D Support (camera, basic models, OBJ models, etc)
* Powerful Text module with SpriteFonts support
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).
```c
#include"raylib.h"
raylib uses on its core module the outstanding [GLFW3] (http://www.glfw.org/) library. The best option by far I found for
window/context and input management (clean, focused, great license, well documented, modern, ...).
intmain(void)
{
InitWindow(800,450,"raylib [core] example - basic window");
raylib is licensed under a zlib/libpng license like GLFW3. View [LICENSE] (https://github.com/raysan5/raylib/blob/master/LICENSE.md).
while(!WindowShouldClose())
{
BeginDrawing();
ClearBackground(RAYWHITE);
DrawText("Congrats! You created your first window!",190,200,20,LIGHTGRAY);
EndDrawing();
}
tool requirements
CloseWindow();
return0;
}
```
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.
#### Installing and building raylib on multiple platforms
[raylib Wiki](https://github.com/raysan5/raylib/wiki#development-platforms) contains detailed instructions on building and usage on multiple platforms.
- [Working on Windows](https://github.com/raysan5/raylib/wiki/Working-on-Windows)
- [Working on macOS](https://github.com/raysan5/raylib/wiki/Working-on-macOS)
- [Working on GNU Linux](https://github.com/raysan5/raylib/wiki/Working-on-GNU-Linux)
- [Working on Chrome OS](https://github.com/raysan5/raylib/wiki/Working-on-Chrome-OS)
- [Working on FreeBSD](https://github.com/raysan5/raylib/wiki/Working-on-FreeBSD)
- [Working on Raspberry Pi](https://github.com/raysan5/raylib/wiki/Working-on-Raspberry-Pi)
- [Working for Android](https://github.com/raysan5/raylib/wiki/Working-for-Android)
- [Working for Web (HTML5)](https://github.com/raysan5/raylib/wiki/Working-for-Web-(HTML5))
- [Working anywhere with CMake](https://github.com/raysan5/raylib/wiki/Working-with-CMake)
*Note that the Wiki is open for edit, if you find some issues while building raylib for your target platform, feel free to edit the Wiki or open an issue related to it.*
#### Setup raylib with multiple IDEs
raylib has been developed on Windows platform using [Notepad++](https://notepad-plus-plus.org/) and [MinGW GCC](https://www.mingw-w64.org/) compiler but it can be used with other IDEs on multiple platforms.
[Projects directory](https://github.com/raysan5/raylib/tree/master/projects) contains several ready-to-use **project templates** to build raylib and code examples with multiple IDEs.
*Note that there are lots of IDEs supported, some of the provided templates could require some review, so please, if you find some issue with a template or you think they could be improved, feel free to send a PR or open a related issue.*
learning and docs
------------------
raylib has been developed using exclusively two tools:
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.
raylib is present in several networks and raylib community is growing everyday. If you are using raylib and enjoying it, feel free to join us in any of these networks. The most active network is our [Discord server](https://discord.gg/raylib)! :)
To compile examples, make sure raylib.h is placed in include path and libraries raylib (libraylib.a) and glfw3 (libglfw3.a)
are placed in the libraries path. It's also recommended to link with file icon.o for fancy raylib icon usage.
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.
If you are using raylib and you enjoy it, please, [let me know][raysan5].
If you feel you can help, then, [helpme!] (http://www.raylib.com/helpme.htm)
acknowledgments
---------------
The following people have contributed in some way to make raylib project a reality. Big thanks to them!
- [Zopokx](https://github.com/Zopokx)
- [Elendow](http://www.elendow.com)
[raysan5]: mailto:raysan@raysanweb.com "Ramon Santamaria - Ray San"
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.
First version of raylib is quite complete and functional but there is still a lot of things I would like to improve.
Here it is a list of features I would like to add and functions to improve.
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:
Around the source code there are some TODO points with pending revisions/bugs and here it is a list of features I would like to add.
- [GitHub Issues](https://github.com/raysan5/raylib/issues) has several open issues for possible improvements or bugs to fix.
- [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 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.
| ## | 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.
| ## | 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 |
| country.mp3 | [@emegeme](https://github.com/emegeme) | [CC0](https://creativecommons.org/publicdomain/zero/1.0/) | Originally created for "DART that TARGET" game |
| target.ogg | [@emegeme](https://github.com/emegeme) | [CC0](https://creativecommons.org/publicdomain/zero/1.0/) | Originally created for "DART that TARGET" game |
| target.flac | [@emegeme](https://github.com/emegeme) | [CC0](https://creativecommons.org/publicdomain/zero/1.0/) | Originally created for "DART that TARGET" game |
| coin.wav | [@raysan5](https://github.com/raysan5) | [CC0](https://creativecommons.org/publicdomain/zero/1.0/) | Made with [rFXGen](https://raylibtech.itch.io/rfxgen) |
| sound.wav | [@raysan5](https://github.com/raysan5) | [CC0](https://creativecommons.org/publicdomain/zero/1.0/) | Made with [rFXGen](https://raylibtech.itch.io/rfxgen) |
| spring.wav | [@raysan5](https://github.com/raysan5) | [CC0](https://creativecommons.org/publicdomain/zero/1.0/) | Made with [rFXGen](https://raylibtech.itch.io/rfxgen) |
| weird.wav | [@raysan5](https://github.com/raysan5) | [CC0](https://creativecommons.org/publicdomain/zero/1.0/) | Made with [rFXGen](https://raylibtech.itch.io/rfxgen) |
Some files were not shown because too many files have changed in this diff
Show More
Reference in New Issue
Block a user
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.