Can recommend Odin[0] if you want to play with Raylib. Great for prototyping, although I'm not sure if it will last further on in development. Still have to figure that one out.
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 think the magic is still mostly in raylib in that it's a well designed API with high composability. It feels like playing and building. Odin is special in its own right.
There's no particular feature of Odin that really stands out, but where Odin outclasses every language available is that every single feature has been very thoughtfully considered and designed to have the least amount of issues. Once you work with it for a few months, it becomes obvious very quickly its vision is remarkably consistent, leading to a smooth and outright delightful development experience.
I will caution, if you are the type of developer who likes to pull in lots of packages and dependencies to start a project, it's not for you. There's no package manager, and rightly so[1]. You'll have to build most high-level systems yourself. But when you realise that most frameworks and dependencies are trivial to implement by hand, this won't be a bother.
If you're the kind of developer who loves building systems and doing everything yourself, you'll feel right at home.
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?
Man, am I so excited. raylib is how I managed to actually.. start getting proper fun out of programming, and finally get some projects that could be considered complete, as small as they were.
I've got a bunch of options because I get a stupid amount of free parts from work, but based on the other person who replied to you, I'd definitely recommend trying it with an ILI9341, they're super ubiquitous and competitively priced. It's probably what I will use.
Nothing against the MIPI-DSI displays, but sometimes they require you to write pin definitions for like, 40 pins, it gets a little ridiculous.
This is awesome. I don't do any graphics programming and don't really have any Raylib experience (or keep up with the projects developments) but it inspired me to begin learning C this past few months. I started building my own zero dependency software renderer (all it can do is color the background and render a spinning 2d rectangle). I'm really excited to dig into the rlsw source code later today.
The remaining issue I have with Raylib is that the library has no concept of a Text object, so for text-heavy scenes (lots of combat damage texts in fast paced games, lots of UI elements), the library spends most of the time recalculating font glyph stuff when drawing text.
> NEW Text Management API: Along with the new file system functionality, a new set of text management functions has been added, also very useful for text procesing and also used in custom build systems creation using raylib. At the moment raylib includes +30 text management functions:
I have read it, if you scroll down to the API list for the new text functions, they all relate to text (string) manipulation, not text rendering. There's still no native mechanism for caching text vertexes between frames.
About a year ago I was curious about building an ECS-based game engine with world simulations like in dwarf fortress, but obviously at much smaller scale while playing Starfield. Something cool started to materialise after tinkering so I thought why not turn it into a space-sim roguelike with a simulated living world.
I use swift because it gives me fantastic devex with all its great type inference and macros + raylib gives me cross platform input handling / rendering and window management.
C-interop setup is basically instant - you point compiler to c headers and the API becomes immediately visible on swift side
As for swift ergonomics, I particularly love that I can now write very readable code, like:
a lot of cool-looking stuff in my ECS is supported by Swift parameter packs; however, once you start using them a lot you find limits pretty soon.
One example: the following wouldn't compile in swift:
func query<each T, each K>(
_ body: ((repeat each T), (repeat each K)) -> Void
) { ... }
so you kinda work around it with extra type wrappers but this looks ugly - I've been using macros to hide some of the ugliness away xD
edit: the example is oversimplified just to show the point - in this example compiler can't really tell where T ends and K starts, so its logical; but I had more complex cases where a human would've been able to infer types correctly
I tried raylib and I love it, but I need to build a lot from scratch (like most game frameworks). But I also really dislike engines as I prefer making games with code rather than a GUI.
I am currently working on a framework/engine hybrid called vectarine [1] where I make my game with code while still enjoying niceties of an engine like hot reloading, integrated debugging, asset management etc.
I worked on a game in Golang+Raylib and had loads of fun. It strikes a perfect balance for people like me, that don't want to use a game engine, but also don't want to build one completely from scratch. It leaves many things to the developer, but takes care of most of the boring stuff (especially things that are platform specific). Can highly recommend.
do we still need unreal engine and unity? if yes what are the things that raylib is missing that these engines have? beginner gamedev so please take it easy here
Those engines serve a different purpose than a library like Raylib. They give you a bunch of stuff out of the box like lighting, raytracing (esp Unreal), pathfinding, and a ton of helper functions used in making a game like vector calculations.
Raylib helps you draw stuff, play sound, and do the basics. But you're gonna be writing your own lighting/raytrace/pathfind/etc functions and it's ultimately going to take longer. The upside is if you need to do something very unique, all of the power to mske it reality is in your hands because Raylib isn't opinionated on how your game logic works and how it's packaged up. It's just the delivery guy to give the result to the user.
I think engines like Unreal, Unity, and Godot will remain popular with people who are more interested in creating a game than creating a game engine.
> if yes what are the things that raylib is missing that these engines have?
Asset management and import pipelines, rendering pipeline, loads of ready-to-go features like environments, baked lighting and global illumination, AO, reflections, particle systems, input mapping and event propagation, scripting, audio systems, GUI systems, and lots more.
Raylib is a library that you could use to build all that stuff, but otherwise it's a useful library, not a fully-featured game engine.
If you don't want a game engine and know exactly what you features you need and want to build only that, then Raylib is a great option.
If you don't want to write a global illumination system or asset management pipeline but would rather focus on creating gameplay, then a game engine is a good choice.
Raylib is more of a low level runtime library than an engine. Godot, Unity, Unreal etc. come with very extensive interactive tooling for game creation. Modern engines are really about interactive content editing and collaboration in the development process. This is essentially table stakes for game development in larger teams, and comes with a lot of added internal complexity.
Raylib is for hobbyists that want control over everything, but don't want to go through the hassle of dealing with DirectX/OpenGL. It isn't competing with Unreal/Unity at all.
I don't know that any open source project will ever compete with Unreal and its high end tech targeting the AAA space. But beyond that, Raylib doesn't give a ton of things an engine does because that is not the point of a library like it. This is to let someone build their own engine how they want, Unreal/Unity/Godot/etc let you give up some control and decision options to skip a ton of work building out a lot of basic features.
The scope/feature set of both is just quite a lot wider, from IDEs to an ecosystem of 1st and 3rd party libraries and extensions. The rendering engines and their capabilities are also quite different (with Unreal and Unity both being quite a lot more advanced).
Can recommend Odin[0] if you want to play with Raylib. Great for prototyping, although I'm not sure if it will last further on in development. Still have to figure that one out.
[0] https://odin-lang.org/
What’s special about Odin when it comes to Raylib? (Genuinely curious)
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
- having a nice build-system built in
- smart bounds-checking/integer-wrapping semantics (customizable, too!)
- predefined mathematical operators for things like vectors and matrices
- an actually useful core library
I think the magic is still mostly in raylib in that it's a well designed API with high composability. It feels like playing and building. Odin is special in its own right.
There's no particular feature of Odin that really stands out, but where Odin outclasses every language available is that every single feature has been very thoughtfully considered and designed to have the least amount of issues. Once you work with it for a few months, it becomes obvious very quickly its vision is remarkably consistent, leading to a smooth and outright delightful development experience.
I will caution, if you are the type of developer who likes to pull in lots of packages and dependencies to start a project, it's not for you. There's no package manager, and rightly so[1]. You'll have to build most high-level systems yourself. But when you realise that most frameworks and dependencies are trivial to implement by hand, this won't be a bother.
If you're the kind of developer who loves building systems and doing everything yourself, you'll feel right at home.
[1] https://www.gingerbill.org/article/2025/09/08/package-manage...
If you know C, not much because you steer away from the gotchas. If you don't, it's a good language, and with less surprising effects.
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.
They didn't say anything about godot or 3d meshes.
“not sure if it will last further on development”
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?
Your comment was so unrelated I thought you replied to the wrong comment.
Man, am I so excited. raylib is how I managed to actually.. start getting proper fun out of programming, and finally get some projects that could be considered complete, as small as they were.
The new software renderer looks very cool. Will have to give this a spin on an ESP32S3
what display are you talking to ? i haven't touched an ESP in a few years, this sounds like a fun reason to dust one off.
I've got a bunch of options because I get a stupid amount of free parts from work, but based on the other person who replied to you, I'd definitely recommend trying it with an ILI9341, they're super ubiquitous and competitively priced. It's probably what I will use.
Nothing against the MIPI-DSI displays, but sometimes they require you to write pin definitions for like, 40 pins, it gets a little ridiculous.
Fully tested and verified:
ESP32-S3-BOX-3 (320x240 ILI9341, SPI) - Working
M5Stack Core S3 (320x240 ILI9342C, SPI) - Working
ESP32-P4 Function EV Board (1024x600 EK79007, MIPI-DSI) - Working
Easy to add: Any board with ESP-BSP noglib support. Just add to board_init.c.
This is awesome. I don't do any graphics programming and don't really have any Raylib experience (or keep up with the projects developments) but it inspired me to begin learning C this past few months. I started building my own zero dependency software renderer (all it can do is color the background and render a spinning 2d rectangle). I'm really excited to dig into the rlsw source code later today.
The remaining issue I have with Raylib is that the library has no concept of a Text object, so for text-heavy scenes (lots of combat damage texts in fast paced games, lots of UI elements), the library spends most of the time recalculating font glyph stuff when drawing text.
You should have read the post :P
> NEW Text Management API: Along with the new file system functionality, a new set of text management functions has been added, also very useful for text procesing and also used in custom build systems creation using raylib. At the moment raylib includes +30 text management functions:
I have read it, if you scroll down to the API list for the new text functions, they all relate to text (string) manipulation, not text rendering. There's still no native mechanism for caching text vertexes between frames.
I'm currently building my roguelike in swift using c-interop with raylib - this brings me so much joy
more info pls.
there is not much to brag about yet :'(
About a year ago I was curious about building an ECS-based game engine with world simulations like in dwarf fortress, but obviously at much smaller scale while playing Starfield. Something cool started to materialise after tinkering so I thought why not turn it into a space-sim roguelike with a simulated living world.
I use swift because it gives me fantastic devex with all its great type inference and macros + raylib gives me cross platform input handling / rendering and window management.
C-interop setup is basically instant - you point compiler to c headers and the API becomes immediately visible on swift side
As for swift ergonomics, I particularly love that I can now write very readable code, like:
> world.addRelation(attacker, Attacks.self, target) > world.addRelation(player, Owns.self, sword)
or
> for (entity, position) in world.query(Position.self).with(Health.self, Velocity.self).without(Enemy.self) {}
This sounds cool. You mentioned Swift's macros - would you mind talking a bit how you are using them?
a lot of cool-looking stuff in my ECS is supported by Swift parameter packs; however, once you start using them a lot you find limits pretty soon.
One example: the following wouldn't compile in swift:
so you kinda work around it with extra type wrappers but this looks ugly - I've been using macros to hide some of the ugliness away xDedit: the example is oversimplified just to show the point - in this example compiler can't really tell where T ends and K starts, so its logical; but I had more complex cases where a human would've been able to infer types correctly
Do you use any bindings or directly use C functions (with a modulemap) in Swift?
No bindings, I wrote a few wrappers myself to make often used functions a bit more swifty, but otherwise its pretty smooth sailing
I tried raylib and I love it, but I need to build a lot from scratch (like most game frameworks). But I also really dislike engines as I prefer making games with code rather than a GUI. I am currently working on a framework/engine hybrid called vectarine [1] where I make my game with code while still enjoying niceties of an engine like hot reloading, integrated debugging, asset management etc.
[1] https://github.com/vanyle/vectarine
I worked on a game in Golang+Raylib and had loads of fun. It strikes a perfect balance for people like me, that don't want to use a game engine, but also don't want to build one completely from scratch. It leaves many things to the developer, but takes care of most of the boring stuff (especially things that are platform specific). Can highly recommend.
After more then 6 hours after release, there still isn't a tsoding speedrun for it.
do we still need unreal engine and unity? if yes what are the things that raylib is missing that these engines have? beginner gamedev so please take it easy here
Those engines serve a different purpose than a library like Raylib. They give you a bunch of stuff out of the box like lighting, raytracing (esp Unreal), pathfinding, and a ton of helper functions used in making a game like vector calculations.
Raylib helps you draw stuff, play sound, and do the basics. But you're gonna be writing your own lighting/raytrace/pathfind/etc functions and it's ultimately going to take longer. The upside is if you need to do something very unique, all of the power to mske it reality is in your hands because Raylib isn't opinionated on how your game logic works and how it's packaged up. It's just the delivery guy to give the result to the user.
any helper libraries that can be used with raylib for implementing stuff like raytracing, pathfinding etc?
I think engines like Unreal, Unity, and Godot will remain popular with people who are more interested in creating a game than creating a game engine.
> if yes what are the things that raylib is missing that these engines have?
Asset management and import pipelines, rendering pipeline, loads of ready-to-go features like environments, baked lighting and global illumination, AO, reflections, particle systems, input mapping and event propagation, scripting, audio systems, GUI systems, and lots more.
Raylib is a library that you could use to build all that stuff, but otherwise it's a useful library, not a fully-featured game engine.
If you don't want a game engine and know exactly what you features you need and want to build only that, then Raylib is a great option.
If you don't want to write a global illumination system or asset management pipeline but would rather focus on creating gameplay, then a game engine is a good choice.
Raylib is more of a low level runtime library than an engine. Godot, Unity, Unreal etc. come with very extensive interactive tooling for game creation. Modern engines are really about interactive content editing and collaboration in the development process. This is essentially table stakes for game development in larger teams, and comes with a lot of added internal complexity.
Raylib is for hobbyists that want control over everything, but don't want to go through the hassle of dealing with DirectX/OpenGL. It isn't competing with Unreal/Unity at all.
I don't know that any open source project will ever compete with Unreal and its high end tech targeting the AAA space. But beyond that, Raylib doesn't give a ton of things an engine does because that is not the point of a library like it. This is to let someone build their own engine how they want, Unreal/Unity/Godot/etc let you give up some control and decision options to skip a ton of work building out a lot of basic features.
Raylib basically just draws graphics.
Unity and Unreal do anything most games will ever need and have massive ecosystems.
For example , Unity has built in physics , navigation, asset management, input handling, build systems, audio processing, etc.
Unreal has that and arguably more.
Godot is getting there, but still has growing pains. In larger projects things get weird.
We never needed them, it is all about where do you want to spend your development budget.
The scope/feature set of both is just quite a lot wider, from IDEs to an ecosystem of 1st and 3rd party libraries and extensions. The rendering engines and their capabilities are also quite different (with Unreal and Unity both being quite a lot more advanced).
Looking forward to Tsoding's new 6.0 speedrun.
Waiting for Tsoding to do another Raylib speedrun
That's his go to for "hello world" for different languages :D. I love it so much.
[dead]