C99 Game Library. XNA-like. Single source. Platform Independent. Allocator Aware.
Forked from the awesome raylib game framework: https://www.raylib.com/
NOTICE: rayfork is still under very early development and it is not recommended that you use it professionally at the moment.
rayfork only has one .c file and only depends on libc, which means it can be easily compiled as a library from the command line.
gcc -c rayfork.c clang -c rayfork.c cl -c -EHsc rayfork.c ```
rayfork does not provide a platform layer, that means it won't create a window, load OpenGL, or capture input for you.
This is by design, so that you can easily use rayfork on multiple platforms (including game consoles) by using the method that works best for you. There are templates for using rayfork with GLFW, SDL, sokol-app and custom platform layers.
The renderer currently has OpenGL33 and OpenGL-ES3 backends (with more to be added) that are implemented in a portable way which allows rayfork to be compiled on any platform, with the only dependency being libc. OpenGL procs are passed explicitly to rayfork and there is a simple macro to aid with this.
Because of this you can easily compile rayfork for any platform be it PC, Mobile or Consoles.
Functions that do IO are often optional and explicitly ask for IO callbacks. A simple wrapper for the libc IO functions is provided as
Functions that allocate explicitly ask for an allocator and sometimes also for a temporary memory allocator (memory that is freed inside the function). A simple wrapper for libc's malloc/free is provided as
All dependencies are also used with custom allocators in mind, the library will never allocate without you knowing.
Every function that requires an allocator or io callbacks has an
_ezversion which wraps the original function and calls it with
rf_default_io, this is useful for testing code quickly.
The library is only one header and source file and can be customized at compile time using preprocessor definitions. No additional compile flags are needed, depending on the graphics backend you might need to link against certain libraries.
raylib was created initially for educational purposes and has matured over time into a very useful games library, similar to XNA.
However, due to its nature, several design choices in raylib make it hard to use for professional game developers:
Hard to use a custom platform layer (eg: using with a custom platform layer on Android with Android Studio)
Hard to port on other platforms (eg: iOS, consoles)
Little control over memory allocations and io.
rayfork is designed to address those issues and make it easy to develop professional games using the API from raylib.
I started this project because I love raylib and C99 and I really wanted to develop my game using them.
Many libraries however do not follow the principles that I look for in a library (see this article) which makes using them in games hard/annoying which is why I want to create a library that indie developers can confidently and easily use to develop their projects without sacrificing control, portability or quality.
If you want to be able to develop games easily with libraries that respect the principles mentioned above, please consider contributing to rayfork.
You can check the issues tab and find a lot of things you can do to contribute.
I am also looking for help in developing things outside my expertise: - Improving the rendering API - More graphics backends (sokol-gfx, vulkan, custom console backends) - A particle system - Physics - Networking
Keep the naming convention to snake case, use
rf_function_namefor interface functions and
_rf_function_namefor private functions.
Prefix all functions with
Don't include additional headers in the interface, work towards minimizing includes in general.
#pragma region \ #pragma endregionfor folding regions of code and consider using an editor with support for folding those regions to get an easier grasp of the code.
Try to apply the advice from this article in general. Some of the more important advice would be: