I think Raylib satisfies a similar CAPABILITIES-niche to Godot...
I am _not_ talking about ease of use or interface.
For a long time Godot has not been ready for medium-large 3D releases, that is changing, but for the most part both it and Raylib are very reliable and will be perfectly good to release a 2D game with.
I'm not actually sure whether a 3D game with skinned meshes will ever be in-scope for Raylib. Wouldn't seem like it.
I interpret this to mean something like “as my game gets more involved” which is not unrelated to a venture into 3D. Why are you policing my comment which is trying to be helpful?
Most of my code in the last year and a half has been Odin. My personal codebase moved from C11 to Odin. I would say that Odin is just more streamlined and easier for a beginner to learn with (which is who Raylib is aimed at.) Both syntax and semantics are simpler; so much so that the (relative to C) smaller ecosystem doesn't pose a problem to learners.
I like Odin because it values the low-friction of C, unlike just about every other "better C" I've tried. It adds friction where you're likely to cut yourself, and reduces friction where it matters; in places like:
- having semantic modules instead of textual inclusion
I flat out disagree. If we want things that are better than average, we will need to be making things that are not average. The machine doesn't learn yet.
SFML historically was a little more accessible if you were an OOP programmer but a total beginner to working with audio/graphics/networking programming from a game perspective. You had to be OK with or devoted to OOP/classes, want a higher-level library with a few more batteries included (especially cross-platform input and networking) but less flexibility, don't need to target game consoles, don't want or need to work in C, and are primarily or only working in 2D.
That said, even for those uses SDL2 (much less SDL3) caught up to SFML about 6-7 years ago in usability issues for people without experience coding at that level. Circa 2015, SFML was the easier route to both performance and a working cross-platform binary. That hasn't been true for a long time now, even when SFML started to get refurbished around 2021/2022. The only times I've come across SFML since 2017/2018 have been projects migrating off of it and onto SDL 2 or 3.
It's good to have both SFML and SDL, among other C++ options and other-language frameworks. Even looking at 3.1, I don't think I'd recommend SFML now, especially not for the same reasons I might've done it 10 years ago. But it's good to see them modernizing anyway, and changes like this might make it easier to update and maintain old or abandoned projects that still use SFML.
As maintainer I won't be able to give you an unbiased response. The biggest difference is, that SFML is a C++ library.
What motivates me to work on SFML is, that we're building something separate from SDL. I don't think, we - as in the general developer world - do anyone a favor in consolidating everything into one library (why use X, when Y does the same?). Additionally, I think it's a very interesting "field" of trying to provide a common API across different OS; and sadly it seems to be an area where few resources exist and fewer developer actually understand it, as "everyone" just uses SDL. Finally, I really like the open and welcoming community we've built over the years and at the same time, I'm happy we're not getting as much attention/pressure as SDL.
I appreciate the response. I've actually got my own platform-layer which can be a bit like SDL/SFML in shape at times, so I totally understand the desire to work on that kind of problem. I'm good with different competing solutions in similar spaces, as well. I don't think one library to rule them all is necessarily a good idea.
Lately I've been doing the experiment of just forgoing the library entirely for this kind of code. It's a bit like gradually building up my own SDL/SFML directly in-place. I'm sure people would find that wasteful or odd, but I enjoy learning the differences in the platforms, and being better positioned to integrate with a particular platform. I'm also shipping way less code. Although admittedly I'm not sure if I'd do this if I were a C++ dev, I write Odin and part of the experiment is putting Odin through its paces and seeing how well it fits in this part of the stack (very happy so far.)
Thank you for writing effectively what I was curious about. "Simulating traffic" can mean a lot of things, I remember on the old SimCity they just "colored" each road-tile as red/yellow/green, (no doubt from a ternary flag) and the visuals just sort of blended between the states (car density.)
Being able to do millions of things each second should enable all sorts of behaviors, especially for a game of the era when you asked the OS to kindly step aside while you run your program.
> especially for a game of the era when you asked the OS to kindly step aside while you run your program.
totally! I was also wondering this. I know each operation takes some number of cycles, but there's still 25,000,000 of them happening per second, and there's no multi-tasking... :shrug: :)
Everyone will have their different take on what Swift is, and what a proper alternative looks like. Swift started life as a C-family successor, so I'll be looking at languages with similar aims (fine-grain control, scaling to large projects.)
The first two I'd mention are D and Nim. I only wrote ~10k LoC with these languages (so they weren't really for me) but they strike me as similar to Swift. They both optionally support an automatic memory management strategy like GC, (whereas Swift as ARC) and there is great effort put into metaprogramming facilities. Both D and Nim compile much faster than Swift, and offer better error messages than the Swift compiler in the presence of complex generic expressions. In the context of the parent post (games) Nim is especially well equipped with a package ecosystem. D seems a touch less lively, but has a following.
For myself, I prefer the Odin programming language. Full disclosure, I've been donating to Odin for about a year now after happily using it for more than 5. After writing "Orthodox C++" for a while, I stumbled on Odin and feel as if it was made specifically for me. The compiler is fast, and the language has been something like a tutor or mentor for me, as it applies friction in places where I usually waste time. It would take some hand-holding as a first-language though, as some error messages relating to overloading/generics would seem obtuse to a beginner.
EDIT: I've recently been exposed to the Raku language, and it strikes me as sort of a ... dynamic version of Swift? It's jammed full of functionality, with an emphasis on being able to design syntax a-la DSL.
Also I'd add that Swift is sort of part of this new litter of "no-paradigm languages" like Kotlin and C#. I don't think Kotlin can actually dip as low-level as C# and Swift can, though. At least I think only C# and Swift have some kind of safety-wrapped user-level pointer "thing."
I am _not_ talking about ease of use or interface.
For a long time Godot has not been ready for medium-large 3D releases, that is changing, but for the most part both it and Raylib are very reliable and will be perfectly good to release a 2D game with.
I'm not actually sure whether a 3D game with skinned meshes will ever be in-scope for Raylib. Wouldn't seem like it.
reply