I agree entirely with the author on the limitations of Raylib. I'm currently working on a tower-defense style game that I started in Raylib, but I'm running into many of the same limitations (and more). Things such as toggling fullscreen not working consistently across platforms, not being able to enumerate screen modes, toggling rendering features at runtime, saving compiled shaders etc., etc. Having said that, I appreciate Ray's work on this library and will continue to sponsor him. Raylib is great for quickly banging out a prototype, but not much beyond that unless you're okay with living with severe limitations.<p>Lesson learned, for sure, but I'm too far into the development to swap all of the Raylib stuff out for SDL (or something else) now.
> The Shapes are kept in a statically allocated array [...] Can’t fail to allocate, can’t be leaked, no fluff. Lovely. The 100 shape limit wasn’t limiting in practice. With very little time to optimize the renderer, the framerate would drop before you even got to 100 shapes.<p>That's the best example of avoiding premature optimization I've seen in a while.
Super interesting post, and appreciate him talking about the various decisions like his handling of memory (and the issues he ran into with raylib). As someone who's finally diving into part 2 of crafting interpreters (and using it to refresh myself on C) being reminded of what C does well is great.
Long ago, I worked on the operating system for a desk phone. With only 64K of RAM, there was no dynamic memory management whatsoever. We made heavy use of static variables and let the compiler figure out how to allocate everything at compile time.<p>It’s easy to forget that many applications probably don’t need dynamic memory management at all. You can often get away with allocating a few fixed size buffers and just handling the edge cases nicely when those buffers are full.<p>And in such a context, C is indeed a whole lot safer. No memory leaks. Your only concern is buffer overflows, which can be managed through careful use of sizeof when all of your variables are statically allocated. I’m not saying Rust and Go aren’t great options these days, but humble old C still works and doesn’t have to be nightmarishly complex.
Off-Topic:<p>Glad to see for the first time a WebAssembly interface where the text does not look blurry. I repeat, it is the first time.<p>Extending this to programs and some operating systems (such as Windows), in the past few years, there has been a pervasive issue with the text rasterization methods that have become a common trend and default setting.<p>Unfortunately, users often do not have the option of turning off anti-aliasing to get sharp text, and in the rare cases where this option is available, the interface (menus, etc.) still uses anti-aliasing.
I really like this kind of projects. I still like the low level of C. Now I work with rust a lot and elixir/erlang but I often miss the simplicity and explicitness of C. For this, I use zig a lot too. It is a very nice improvement over C while keeping a lot of its philosophy.
Really agreed with his assertion of c. More to his “ Its syntax doesn’t hide complex operations. It’s simple enough that I don’t have to constantly look things up”, and further if you need to look up something about c, it is very easy and very informative. Simple and old lang has its benefits.
<i>You could certainly make it harder on yourself by malloc-ing each Shape individually and storing those pointers in a dynamic array. Using a language like C# ... would force that allocation structure.</i><p>What's stopping you from using a fixed array of structs in C#, just as the author has done in C?
I hope somebody will continue this project. It's a few months away to be a serious alternative to Blender / FreeCAD for certain use cases, with a much softer learning curve.
Just started using Raylib, bummed to hear about the limitations!<p>As a novice C programmer, the simplicity and immediacy of results opened my eyes to how C can feel as productive as higher level languages with robust standard libs.
There's something really powerful about taking the tools that you know very well and just making something cool with them. Really enjoyed this writeup, thanks.
To get a look at SDF rendering in a game, check out the blue clouds on the ground in Solar Ash:<p><a href="https://youtu.be/HqQpYSQDIZQ?si=vMKplmGJIGvUn_LT" rel="nofollow">https://youtu.be/HqQpYSQDIZQ?si=vMKplmGJIGvUn_LT</a>
This looks cool, after 3 years in financial technology industry working on c/c++ projects I’m in process of revisiting textbooks and relearning computer science fundamentals! Added raylib to my ‘explore’ list<p>I love this idea of reinventing wheel with such explicit goal (even if it sounds counterintuitive to some), we can rethink initial assumptions, best case scenario we come out with better implementations and paradigms than existing standards, worst case scenario you learn internals of tools and techniques you use daily!
"Using a language like C#, Javascript, or Python would force that allocation structure."<p>No. C# structs are C structs. Shape[], Span<Shape> or Shape* would not be an array of pointers. Any of the following would work:<p><pre><code> var fromHeap = new Shape[100];
var fromStack = (stackalloc Shape[100]);
var fromPool = ArrayPool<Shape>.Shared.Rent(100);
var fromMalloc = (Shape*)NativeMemory.Alloc(sizeof(Shape) * 100);</code></pre>
Really cool and the video was great too. Indie devs should probably consider doing this sort of thing more often, building these simple tools in service of a game rather than just using the industry standard tool. It can be a great way to add artistic character as well as rigorously enforce some limitations if that's what you're after.
Nice, I was considering a project like this myself. Signed distance fields are awesome. Everyone into modelling should check out ImplicitCAD based on SDFs.
getting tired of the underhanded shilling for c and procedural style programming. the people doing this still pretend they are the underdogs but their point of view is over saturated.