So while I feel good about deciding to use C, raylib turned out to be trouble. First off, it has strange design choices that harm the developer experience:
Raylib uses int everywhere that you would expect an enum type. This prevents the compiler from type checking and the functions don’t self document. Take this line in raylib’s header for example:
// Check if a gesture have been detected
RLAPI bool IsGestureDetected(unsigned int gesture);
It looks like gesture might be an ID for a gesture you’ve registered for. Reading the raylib source reveals that gesture parameter is actually a Gesture enum! This happens everywhere. Raylib’s only documentation is the header file, so you have to go to the implementation to see if any int parameter is really an enum, and if it is, which enum.
Raylib doesn’t do basic parameter validation, by design. This function segfaults when dataSize is null:
unsigned char *LoadFileData(const char *fileName, int *dataSize);
The raylib header doesn’t indicate that dataSize is an out parameter, or that it must not be null. This no-validation choice affects many functions and made trivial problems hard to track down. If you’re lucky it segfaults somewhere useful (but it doesn’t log an error). If you’re unlucky it just silently does something weird.
Raylib doesn’t take responsibility for its dependencies. There are issues in GLFW that raylib won’t work around or submit a patch for. As an end user of raylib, the method they chose to create a window is an invisible implementation detail. I care about raylib’s features working for me, regardless of what that means internally.
The raygui UI library is just a toy:
can’t display floating point numbers. I had to make a float text field.
doesn’t handle mouse event routing for overlapping or clipped elements
can’t do rounded corners, which are everywhere in UIs.
can’t be styled to look good
And finally just plain bugs:
raygui tooling had a bug that prevented changing the font from the hyper-stylized default (please pick a reasonable default!)
Drawing functions like DrawCircle(...) don’t share vertices between triangles. That causes pixel gaps due to floating point error when the current matrix has scaling or rotation.
For a while I reported issues as I found them, but almost all of them them were closed as “wont fix”. This was frustrating and discouraging, and it was time consuming to write the bug reports, so I just stopped.
So yeah, while it was great that raylib made me an OpenGL window, I paid dearly for that convenience. Luckily I usually found an escape hatch: either by using OpenGL functions directly, or implementing a feature from scratch. In the future I’ll go with sokol.
The quote: “The raygui UI library is just a toy” is about raygui and not raylib.
Most of the post is negative. But there is a positive part: this amazing work was done using raylib.
Author contradicts itself when he says: “There are issues in GLFW that raylib won’t work around or submit a patch for.”. In github, the issues that he posts are about GLFW fixes to raylib, but he does not post the GLFW issues to GLFW.
Raylib specified undefined behavior for a function, that the parameter must not be null. Raylib also defined behavior for another function that it shows only upto a number of characters. These are acceptable assumptions for a game library. It is not acceptable for the author and the Ariane rockets.
My advice is to ignore these posts, use the library for a while, and decide if it suits you.
The best library is no library. If you’re already drawing with OpenGL, just do a little bit more work and draw you own UI. After this, all that’s left is to open a window, which is quite easy in most platforms, and getting user input, which is a bit more involved, but not the end of the world. These libraries necessarily limit you to the lowest common denominator, so you’ll be missing out on features and you’ll likely have overhead. The best place to write a portability layer is in your own app, not in a library. You’re in a much better position than some library to decide what platforms you want to support and what you need from them. Using openGL, in itself, will already make a good part of the code cross-platform.
While we’re at it, I recommend switching to Vulkan. Granted, it’s more verbose, but every step makes sense, contrary to all the magic that happens in OpenGL. If the main thing you want from these libraries is an OpenGL context, that’s another point in favor of Vulkan, as it’s easy to initialize it, no libraries required.
I have had a mostly all positive experience with Raylib but I do think the Sokol project is also powerful and well designed.
Raylib is a simple api geared towards newbs at programming so it has made some odd design choices to avoid tripping up new users.
But don’t let that stop you from taking a look. Raylib is one of those projects that just works and works well IMO.
The gripes in this article seem to be nitpicking or bike-shedding on API details that seriously aren’t the end of the world.
I’ve been able to control sound effects, music streams, shaders, blend modes, and textures with ease. The performance is solid and if you want a tighter more idiomatic experience you can use the Zig wrapper library.
I chose to use C directly and it’s still a breeze.
I think the mark of a good piece of software is that it stays out of your way and while still giving you the power to do what you need. Lots of people are having success with Raylib these days.
I have never used raylib (or sokol), so these may all be valid issues. But on a positive note, here in zig land we can write a wrapper that hides all these warts and makes it very easy to work with the library. It might even be possible to do most / all of the work at comptime and have zero overhead for all the safety you gain. THIS is one of the areas where zig shines.