Raylib is a lightweight, beginner-friendly, and open-source C library for game development, known for its simplicity and lack of external dependencies. It's designed to streamline the creation of 2D and 3D games, and has an intuitive API for managing graphics, audio, and input. Ramon Santamaria is the founder and lead developer of Raylib. He joins the show with Joe Nash to talk about the Raylib project. Joe Nash is a developer, educator, and award-winning community builder who has worked at companies including GitHub, Twilio, Unity, and PayPal. Joe got his start in software development by creating mods and running servers for Garry's Mod.
Endgame development remains his favorite way to experience and explore new technologies and concepts. Ray, welcome to the show. Thank you for joining me today. Hello, Joe. Thanks for having me. It's a pleasure. So as we mentioned, you are a developer of Raylib, which I'm sure lots of our audience are familiar with. A fantastic C library for game development and all kinds of other, I guess, graphical allocation development. What I want to start with is the path leading up to Raylib, which, as I understand it, is 11 years old today, so we've got quite a journey. Where did your interest in game development come from? Way back before Raylib, what led you to where we are today? Well, actually, before Raylib, I was working in video game development. I worked in EA for some years and also worked in small companies. I also tried to create my own company, publish a couple of mobile games.
for Windows Phone at that moment. And after that, I got a job as a professor in a private education institution. Actually, it was the first one to start teaching video games, an official video game development course here in Spain, I think, actually. And my task was teaching video games programming to mostly art students. And yeah, that was a challenge because, well, usually the art students were not that interested in programming. The first option was using some kind of no-code tool like drag-and-drop. At the moment, it was kind of the beginning of Unity getting into the market.
But I decided to go low level at it. And I really tried to teach actual programming to other students. And to do so, I did some tests. I started with C. And I checked some libraries out there. And after some months of trying different approaches, I found one that actually worked. That was a very, very old library called Borderland BGI Graphics. That's from the 70s, maybe. And surprisingly, it worked extremely well. Because it was super simple, like init, close, draw. It was super simple. After that first year teaching, I decided to create an alternative.
to VGI, but more adapted to modern times. Modern times at the moment mean OpenGL. And I did so. It was a weekend project, actually, really. And just in a couple of months, I got a first version quite complete with a lot of functionality to do some 2D, to do some 3D, and everything. I start testing or using it with the students. And also surprisingly, it worked super, super good. The students were super engaged with the library, and almost all the students were able to create a point. At that moment, it was the assignment in the subject. And they really enjoyed programming, but not...
Only they enjoyed creating games, but they enjoyed the fact of writing code, writing code in a quite raw way with notepad and compiling and running their games. And yeah, that was the origin of the library. But from there, I started getting a lot, a lot of feedback because the students were quite excited about the library. I started asking for improvements, reporting bugs, letting other students from other institutions know about the library. And the library started growing. And well, at that point, I thought that it could be interesting to keep working on it. I actually released it as open source because...
I thought it was the best option for education and to reach a wider audience. And yeah, it started growing. At that moment, I was reactivating my company. The previous one that I had published, Windows Phone Games. But at that moment, I just started working in the library with fewer students. The plan was to keep working on games in case development. Actually, we released a PS Vita game at that time. But most of the day was working in Raylib. So it was like six hours per day working in the school, teaching with Raylib. But then there was another six hours every day working in the office with some students developing Raylib. Incredible.
Yeah, and it worked for about six years that way, something like that, five, six years. And yeah, it kept growing and growing and growing. And then at some point, after those first five, six years, I got an email from Google that they were giving me an award for the open source project. And yeah, the library started getting recognition in a lot of places and started to grow really, really, well, becoming really, really big. And yeah, since that moment, for the last five years, actually, I quit at that moment teaching to focus 100% in the company.
not only develop RedLib, but also develop an ecosystem around RedLib with some auxiliary libraries and to develop tools focused for video games development. But always using RedLib as the base technology. So the technology kept growing along all the other products around it also were built. Yeah, that's mostly today. At this moment, RedLib is super big. Yeah, it's unbelievable the point it has reached right now. It's unbelievable that I've been living years doing that. Yeah, it's a huge achievement. I think I saw...
And we'll be talking about it a bit today, but you've just released Raylib 5.5. And I think I saw, was it 150 contributors to 5.5? Yeah, about 150 for this release alone. But about 650 overall in the years. Yeah, that's a huge achievement. And also, you know, just going back to that.
you know, the early days in that first class, I think you must have had the most engaged class of students in the world to like share the library and start contributing to it. That's awesome. I definitely want to ask you, you know, just from an educator's perspective about how you approach that task of, you know, choosing C to teach art students. So we'll get to that later on. But for now, I guess I'll settle on Raylib. Before we get into all of the details, I guess for folks who aren't aware, can you run us briefly through how Raylib works, what it is and what it does and what it's used for? Kind of a high level introduction to the library, I guess. Yeah, actually the library itself is quite simple in terms of
I mean, not internally, but the API, it's quite simple. It's just the library, so there is no any kind of abstraction, like object-oriented programming or anything. It's just functions, procedural programming, and structures with data. Mostly all the structures are completely transparent. I mean, they are not about pointers to some internal structures. So you can, when you create an image or a text tool, you just define it like any other kind of variable, and you have daily access to my image point, width, height, format, and everything. So it's all the library itself is kept, or I try to get it as much simple as possible.
Always thinking in those first users of the library, the students are not any kind of students. Students that mostly have an art profile and they usually start not interested in code. But many of them actually, after some courses, have ended up working as a programmer in different companies. So that's amazing. So simplicity is one of the key points of the library. Besides that, the library tries to cover mostly the basic functionality that you need to make a small or mid-sized game. You've got functionality to manage the window, the inputs, all kinds of inputs, keyboard, mouse, gamepad.
You have functionality to load images, to upload them to GPU as textures, to load models, the meshes, the materials. Well, that's kind of the most about functionality that has been added along the years. Then you have some basic collision detection functionality. You also got a small math library included that actually is portable that can be used outside of Relic. And you also have some basic functionality to draw textures, models, and to play audio, to load audio and to play audio. So it covers most of the basic functionalities that you need for.
video games development, about the architecture of the library. Since the beginning, it was designed in a way that it was very, very modular. I always thought, okay, it only has seven modules, and that means seven C files. So that's intended to simplify the build system, because in the past, I struggled a lot with build systems, and I decided to simplify that. Actually, when I was at EA, I was in charge of build pipelines and text pipelines, audio pipelines, and I know how complex can it be, actually. And I tried to simplify building at maximum, so I tried to keep.
all the library very small and self-contained in time for architecture. But I also try to make all the modules independent from each other and being able to use them as much as possible as an independent library that you can take out from Raylib and include into your engine or into your program to just do some of the functionality that you need. For example, the audio module, it's completely self-contained, the couplet of anything. So you can just pick up the audio module that are a C file with some header dependencies. You need the audio device, load some audio file, multiple formats are supported, it's configurable also, play the audio and close the audio device.
It's focused on that kind of simplicity. The same for the shapes module. In the shapes module, it's quite self-contained. It only depends on a bunch of functions to create vertex. Well, I think it depends on six, seven basic functions.
to define the vertex data. But then the module is self-contained. So if you want a module to create shapes or kind of shapes like circles, rings, rectangles, rounded border rectangles, well, lots and lots of types of shapes, you can just pick that module. And again, it's the same. OK, you have to provide like seven functions, but mostly any engine already gives you those seven functions. And well, that's the same with every module. Then another of the important parts of the library is an abstraction layer over OpenGL. That's why it's one of the key parts of the library. It's called LGRLGL. And it's a kind of a mapping.
of multiple OpenGL versions from legacy OpenGL to modern OpenGL into an immediate mode OpenGL, kind of. Okay, you also have all the extra functionality to load the meshes and the perfect buffer and everything, but it has a small set of functions that let you just use the library like the immediate mode OpenGL 1.1. And actually that proved to be very, very, very useful because in this latest release, I saw that some people ported RightLib to work on all consoles, on retro consoles and homebrew consoles. And that was thanks to that support for the OpenGL 1.1. Well, back-end, because it's one of the back-ends. It's not the default one, but the default uses OpenGL 3.3, and OpenGL ES 2.0 on web, Android, and Raspberry Pi, or embedded devices. But yeah, that was one of the modules that I think is more useful. But summarizing all together, because I think I'm going into many topics, the library itself, it's intended to basically draw anything on any kind of display. It could be a game, it could be a demo, it could be some kind of multimedia application, it could be a tool, or yeah, anything. And considering it's easy.
And it supports a really wide number of platforms. Yeah, actually, I've seen the library used for many, many, many kinds of applications, not only games. And actually, I'm an electronic engineer, and I love seeing the library running on embedded devices or some kind of display or anything. And yeah, I love it. I see that running in an embedded device. Yeah, that's always exciting. I always think of, you know, I think that the classic example is like...
people putting doom on silly things, right? And whenever there's like that on a new thing, I always get excited by it. So I can only imagine when it's your library that ends up being on, you know, like a pregnancy test or whatever it is people are putting stuff on. That's awesome. Okay, got so much to talk about. So I want to come back to things like the console support and some of the features of the library that you mentioned, like collision detection. But I guess to start with, you started at the beginning talking about, you know, your principles of the API design and, you know, wanting to keep things simple, given the background of the project, that totally makes sense. But, you know, it's been 11 years, you've had like loads of different users come, the library, the audience has really grown. So I'm really interested in, you know, in how you approach API design. In design, you know, there's what?
350, 380 functions? There was an update in 5.5. There's like a lot of functions now. There's a big API surface area. So how do you think about the design of that API now, you know, with the past, present, and future audiences? Well, that's a good question. Actually, at the moment, Rayleigh 1.0 started with 80 functions, only 80 functions. But I thought that was enough to make many kinds of games. But Rayleigh 5.5 has reached the 580 functions.
It was a little bit off. Yeah, that's great. That's awesome. But I also have to say that a couple of years ago, I did an analysis of the market, and I looked for all the open source GitHub repos using RiteLib that I could find, and I compiled like 200 repos or so, and I did some text analysis, text scrapping, and I listed the most used RiteLib functions in all the source files only in those 200 repos, and guess what? What was the surprise? Were the most used functions. Actually, what did the agent work?
That's such a cool idea as well. Yeah, you need window, close window, draw rectangle, begin drawing and drawing, draw circle. I mean, low texture, low texture. I mean, the simple ones were the most used ones. I mean, also, there is some bias here, obviously, because at that moment, the library has been in the market for eight years. And yeah, people start and they use the first function. So there is some bias in that analysis, obviously. But many of the advanced functions added to the library were barely used, actually. There was not many people using them.
And yeah, it was surprising. But as I'm answering your question now, how I approach the API. Simplicity is always the key for me. And sometimes I have some discussions about that on the Discord or with the contributors of the library because sometimes they try to add more functionality. And I have to say no, not because it's not useful, but because it belongs to another level. I try to keep the library at a kind of a low level. And it's recommended that if you want to use it to make a mid-game.
You build your small engine over it and add that functionality in that level, but not in the low level. So I try to keep the library at low level. About things I always keep in mind, for example, the function names. Function names always follow the same pattern. They try to follow the natural language. So as much as possible, do not follow a programmer language because when you go, you tend to use the technical terms that you should use to name everything. And sometimes if you think of the people that is going to use the library that maybe is people with not that much experience, it's easier for them to name the functions with some easier names.
All the functions you already follow the pattern, that verb, subject, and object. There are usually two, three words, three words at maximum, sometimes maybe four words, but I try to keep it in that way always, always the same. Also, in the name of parameters, I try to keep always under five, six parameters, always. And yeah, that's more of it. So I try to keep it simple all the time. That's my object. Sometimes it's not easy, because you have to do things that get complicated, and yeah, it's not easy to...
always keep it simple. But that's the objective. If things tend to be too complicated or the functionality to add turns to be too complicated, I try to abstract as much as possible. If it's a low-level functionality, I try to keep internal and just expose the minimum required for most of the users and then maybe allow some flags, some build flags, or some additional configuration options to configure more advanced functions. Or otherwise, I evaluate if that functionality maybe belongs to a lower...
level, and then it shouldn't be in Rayleigh, but maybe in an auxiliary library or a secondary library. I actually got some of those secondary libraries. I got RightWee that it's a library to create UIs, mostly intended for tooling, but it has a lot of embedded UI functionality. Got also REST for resources packaging. That's also another library where I got random number generator. I got several auxiliary libraries that, well, are kind of in that Rayleigh ecosystem and are intended for users that need that extra functionality for their specific project.
can use those libraries. Actually, last year or so, like one year ago or one year and a half ago, one Reilly developer in the community created a separate organization, a separate repository called Reilly Bextras that has proven to be very, very, very useful because for all the people that came to the community asking for advanced functionality, a common answer is, oh, maybe not for Reilly, but you can add that to Reilly Bextras. And it's usually an additional library or additional template or whatever module that does not need to be in the core library because maybe it's not useful for many, many people. It could be interesting to have it. Sometimes, well, like a binary partition or some kind of additional functionality that, for example, in the community, there are a lot of people coming wanting to make a Minecraft. Okay, that's very common. I did notice that the cover image in your Discord was like a voxel. Yeah, there is a lot of users that are starting with Rayleigh and come to the community and, oh, I want to make a Minecraft. And it's, okay, then they start, okay, so what we need, we need some kind of Oak 3 and all that. But in Rayleigh Extras, actually, there is a kind of a Minecraft template with everything set up, with a lot of extra functionality.
and it can be used as a reference. So not everything has to be regularly. Yeah, and we'll come back to community management a bit as well, because I think the way you manage the ecosystem is really incredible. But just that concept of like, hey, I'm an open source maintainer with a very well-specified focused project, and lots of people have lots of enthusiasm. So there's a space where they can have that enthusiasm that's separate. That is a very nifty solution. So going back to one of the things you mentioned, parameters. This is one of the areas I think is really interesting, particularly about, well, API design with C, but also particularly for your audience, which is, you know, when you get to thinking about your data structures in C and teaching beginners and...
people who aren't programmers and dealing with pointers and dealing with how you parameterize your functions. What is your approach to that? Because that just seems like an area of endless foot guns for library designers in C trying to teach beginners. Well, actually, I forgot to mention about that. The objective at the beginning was avoiding pointers at all. So the first set of functions for Relief had no pointers at all. All the data extractors were just passed to the different functions by value. That's it. It has some problems related to that, but yeah, they are not that bad. What I tried was minimize the size of all the extractors provided. Actually, the extractors are...
quite small, usually under 32, 48 bytes. So it's acceptable to pass them by value. And yeah, that was one of the objectives. With the year, the library has kept growing. And now, yeah, obviously you have some more advanced functions that require pointers. But I think they are out maybe 20 or 30 out of 580. So it's in some cases where you really need pointers because obviously you have to load data. For example, in an image, in an image you have to load data. Then the pointer is just kept inside the structure. So you've got the structure with width, height, format, midmaps, and the pointer to data. Or if it's textures, well, the data is already in the GPU, so you've got the identifier, so that's easier.
But what I try is to keep it simple for those students. Later on, in the last few years, I've been also teaching programming in the university for computer science students. And yeah, that's a completely different mentality because, I mean, for them, they usually love programming and they usually love to go as much technical as possible and go into the test. But actually, even though the beginning of this year, I was teaching in the university to computer science students. Well, I actually was teaching Unity. But I had to teach in the syllabus about programming patterns.
solid concepts and all this information. And I'm so used to coding C with a procedural way with just data and everything and functions that operate on data that when I was teaching all those concepts, it was called, oh, really? Yeah, I had to tell that. So I said that, but I let the students know that that's an option. There's another way, yeah. Yeah, that's another way. And actually procedural programming, it's so enjoyable because...
you really see everything that's happening in the low level. You focus on data, but for me, it's everything. It's the most important thing. At the end of the day, it's what you have, and then it's just operating over that data. And that's a bit of the loss of your right loop. You've got data that you can run, and you just call functions that operate over that data, and sometimes they retard you about it. I think that after many years working in that project, my mentality is so focused on that way of programming that when I look at the different abstractions of the programming, C++, C++, the solid and everything.
it's kind of wow no no way i mean programming can be way simpler than that and works you know yeah no no it's something we talk about a fair amount of guests on the show i guess which is like one of the nice things about game development is sometimes it feels like it gives you an opportunity to get down to like you know the lower level and to get down to like simple abstractions and to just like you know it just has to render once and render once on the screen and like you don't have to maintain it for a million years and that's kind of stuff right so yeah but it's also it's really interesting so first of all uh complete tangent you talk at upc right not this time okay cool i think in several universities yeah I usually tout for some time, maybe one year, two years. I make some money and then I can be sometimes working on Raylib and the tools and all the ecosystem. So this last time I was working in, it's called Techno Campus. That is another university that is near Barcelona, that they also have a video games degree and a computer science degree. And this time I was teaching there. But before that, I was in the UPC for...
For two years. Cool. It was 2020 to 2022. That's awesome. Cool. Yeah, I guess you would have been... The reason I ask is because UPC has a very famous student-run hackathon, but I guess it wouldn't have been running when you were there due to COVID. But yeah, they would have been a great audience for Alem. You mentioned teaching Unity, and I think it's, you know, you summarized, I guess, the challenges of teaching something like Unity to game dev students very well, which is just so many concepts, so many abstractions. But I guess a more holistic level, a higher level when you just think about introducing people to game dev. How do you explain to...
new developers, like, hey, here is why you would choose Raylib versus why you would choose a Unity, a Godot, an Unreal, like a full-fledged engine? Well, I think that, I mean, Raylib can teach you not only the basis of how things work in the inside, but also, well, be a guide to start your path. I mean, actually, those first six, seven years that I was teaching with Raylib, Raylib was a pretty small part of the syllabus. It was like 60 hours in total. Then we jumped it into, at that moment, it was into Monogame. And after that, we jumped into Unity. And I thought that was a great path because Raylib was low-level, was C.
Then you jump into Monogames that actually really is very inspiring in Monogames with the naming conventions and the structures and everything. And with Monogames, you can learn C Sharp, you can learn some object-oriented programming and some more advanced concepts. And then when you understand that, you can jump into Unity because then all the game loop and everything is abstracted into Unity internal structure. But you can start working in a higher level, just managing the logic of the game and the assets and the data and the different scenes. So I think that's a great path, in my opinion. Start in a low level, try to understand how things really work.
If possible, try to go a bit deeper, because that's another point about WriteLib. It's designed in a way that the source code, it's very, very, very simple to read. It has a lot of comments, avoids any kind of complex programming techniques. It's very simple in terms of code. So students that want to dig farther, actually, I had many students that had gone inside WriteLib and then had sent improvements and have, well, improved the library. Yeah, that's it. You can go inside and learn a bit deeper, different concepts, maybe about 3D, about models, about animation, about audio.
You can go deeper, but after that, you can move on and you can move to other upper level frameworks or engines. And I think that's a great path, actually. Yeah, I agree. That does sound really fantastic. And I guess along that way as well, people...
There's like this perpetual issue of computer science education where like they try to teach the abstractions before the student has encountered the problem that requires the abstraction. I always think about this with like Git version control, right? Like the universities try to teach version control before students have worked on big code bases with lots of people and understand why it's helpful to them. And so it's just another thing in the way. But in that path that you described, you know, you get to see the low level and then you get introduced to the monogame and you see like, okay, that takes away some of the low level. I know how the low level works, but now I know why I want this abstraction. And then you get to scenes in Unity. So I think that's a really great approach. That's awesome. Yeah, actually, there's another point that I mentioned. I got it in the head since the beginning. It's about building systems. Right.
Because usually, in my experience, that's the point where most students struggle a lot with the build systems. I don't know, in the different places I've been teaching, usually I've seen a lot of problems in the students understanding how everything works. In the sense that, not how everything works, but how to configure properly a complete development environment. I mean, not only... Maybe starting with compiling the command line, but then setting up some, I don't know, make file or some basic script. From there, try to grow it up. Maybe, I don't like CMake, but maybe CMake or even Visual Studio that is kind of a standard in the industry, I think. How to properly configure a project in Visual Studio. And then from there, move on and not only use the control version system, but even set up some continuous integration, continuous delivery that nowadays, it's quite standard and quite simple to set up these kind of systems. That's one of the problems I found with the students. And, well, I try to address as better as possible, but...
Yeah, I think it's super important because at the end of the day, many students just want to write code and press the play button. That's the easy part, actually. Usually, if you are in a big company, there are many, many, many other side methods and processes that are as important as just compiling the code that need to be done and need to be understood. Someone has to do that work. Yeah. I mean, we could turn this into a whole educational episode, but yeah, I 100% agree. And I think a lot of that instinct to just want to press the play button also comes from like, you know, a lot of the platforms for teaching code nowadays where they give you the fully working cloud environment, you just type the code and press play. You know, I always use the analogy of like, it's the difference between learning how to use a tool versus maintain the tool, right? Like you can learn how to carve a spoon with a sharp knife, but if you don't know how to sharpen the knife, then you're not going to be carving spoons very long, right? It's going to, it's going to blend and you have to start again. Yeah, I think that's a fantastic point. Yeah, but sometimes your spoon can broke, maybe. And then you have to do something.
Yeah, absolutely. But you mentioned there, interestingly enough, so talking about the build systems and CI and stuff, I think this is a good time to talk about Raylib 5.5, given that you've got some fantastic new tooling in that, including solving this issue for very new people. So I guess to start with, so 5.5 was a big release, right? You're working on this one for a while. Yeah. Well, actually, it's been one year of changes, like 800 changes or so, many, many changes. Yeah, well, I've been working on it for a year, mostly at this moment, and actually for the last two years or so, mostly reviewing and merging changes. And that's it. Mostly done. In the past, I was adding features or adding examples or adding content.
But for the last two years or so, I've been mostly doing the reviews, and attending the community, and helping the community, and trying to help the initiatives in the community, organizing the jobs, and doing a lot, a lot of community work, because actually it has grown a lot. It's difficult to manage. That must be very exciting, but also, I imagine, as somebody who likes writing code a lot, there must be a really interesting mindset change. Yeah, well, actually, I still do, but I do with my tools. I develop tools, I publish the tools, and in that side, I write code a lot.
You've given the library to your community and you've gone to your little playground in the corner. Yeah, absolutely. Because as all the tools use Raylib as a base library, that's super good. Because at the same time that I'm developing the tools, if I need a new function, I can add it to Raylib. Or if there is something that is broken in Raylib, I can fix it on the go. That's really great. Yeah, 5.5. What's new in 5.5? That was the question.
Well, yeah, it's been one year with all those changes. And for the last two months, approximately, it's been the time that I put to this release because I got a checklist with everything that should be done before any release. And it's a long checklist, actually. You have to check the compilation for all the platforms. You have to check the example. You have to check the web. You have to check the different social networks. You have to create the installer. The installer for the new Riley version, actually, it's created with Riley itself. Actually, it's one tool that I sell to create installers. So actually, there are a lot of things. And not all of them work at first try, actually.
Because, yeah, for that last release, the last two nights, it was crazy because the installer was not... I'm about to release a new version of the installer. It was not properly tested. And actually, right, 5.5 installer is the test version. And there were some things that were not working, I suspected. And it was like, oh, I have to release this day. And, well, it was a bit stressful, but, yeah, it's out. And about the features of this new release. Well...
There are many, so I cannot list all of them. But what I consider were some of the key features of the release was the improvement on the addition of two new platform backends. In Rally 5.0, there was a big internal redesign of the library. that we have a core module that was a C file with 10,000 lines of code in a C file. And it was multiple defines to select the platform that it was building the code for. So all that code was moved into separate modules to have one module for platform desktop, one module for platform Android, one module for platform DRM that is for embedded systems that run over there. So it was moved all the code into separate modules. Not only that, it was created a template module to be able to add new platforms just overwriting the set of functions required for that. And I kept the core module just like a wrapper to the different...
platforms. And then at compile time, you choose the platform you want and it compiles. So it worked super good. Actually, it has pushed the library during this year a lot. Actually, it has pushed it further than expected because, well, what happened that was some people pick up and start porting it to consoles, to Dreamcast, even Nintendo 64, PS Vita, PS4 Homebrew, PSP, Lightning. So yeah, they only have to write one module, like core PS Vita, core PS4, put all the windowing inputs code in there, then enable the OpenGL 1.1 backend.
and link with the platform libraries for the OpenGL 1.1 backend. So we have seen, that's another of the features of the 5.5, we have seen a lot of porting of Riley to all consoles, to retro consoles. It was like, wow. That's awesome. Yeah, especially Dreamcast, so that's wild. Well, actually, even Spine is working on Dreamcast. Even, you know, the 2D animator system. Right, right, right. That's, wow, it's amazing. But besides that, besides that porting to multiple consoles, two new backends have been added, also thanks to that split. That was a new library that just hit the market, an open source library that is called...
Well, the naming for the graphics libraries are sometimes a bit complex, but it's RGFW. Oh, yes, absolutely, yeah. Yeah, it's a library for abstract, the windowing and input system, but also supports Windows, Linux, Mac. It also supports Web, or it's about to support Web. And yeah, I love single-file header-only libraries, and this is a single-file header-only library. For me, it's like, wow, that's great. Yeah, okay, it's maybe 7,000 lines, never mind. Yeah, you can just drag and drop that library into your code.
And yeah, and you got a full backend for multiple operating systems. So that's great. Well, it was added that backend option to Rayleigh because in the last month, I've seen a deceleration in the maintenance of GLFW library. That's another popular library. So just in case for the future, it was great to have some alternative supported by Rayleigh. And also in the same line, recently it was published, or I don't know if it's still in alpha or beta, it's officially published, but SDL3 library, that's a super popular library for windowing and inputs.
Well, it's widely used in many games. But it also added a module for support multiple graphics libraries that at the moment is not used, but it's interesting to keep an eye on it. And another of the supported backends was SDL2 was already supported. So thanks to contributors, because all that has been done by contributors, so I just reviewed it, was the support for SDL3 backend. Another feature, GPU skinning, that was also requested many, many times. That was when you compute the different positions on the animation. Every frame of animation, you have to reposition the vertex of the model. I can see them, actually. You have to compute that position based on the skeleton of the model. And that process of computing the new positions of the vertex can be done in CPU. It's a lot of matrix operations. Or it can be done in the GPU. Till now, for right-leaf, it was done in CPU. That's great for small models up to maybe...
2000 Vertex. That's not a problem. But the community was asking for GPU skinning. Well, actually, they were asking it because Unity added it. There are many Unity users. Probably they saw GPU skinning, and so they asked for GPU skinning. But it has been requested many, many times. I was quite reticent to add it because it requires some redesign. And also, depending on the technique used to add the GPU skinning, all OpenGL versions, like OpenGL ES for Android or Raspberry Pi devices or embedded devices or web.
It's not simple. It has limitations to implement the GPU skin because it requires more advanced OpenGL features. But at the end, one animation programming professional, Daniel Holden, proposed an implementation that was pretty good and was also supported in all the devices and everything. And yeah, it finally was merged and added to write as an additional option. One thing I guess we haven't mentioned, so you mentioned the installer, but as well as the installer, you also have the project setup tool, I guess. They're all kind of interesting to me because you've got this low-level C header-only library and you're starting to build out and include like...
you know, ecosystem of tools around it where, like, I think the installer adds, like, you get a version of Notepad++ with it and everything as well, right? How are you thinking about what's acceptable tooling to wrap around the library without taking you into, like, a full desktop engine situation, right? Like, where's the line? Yeah, well, actually, that line, it's quite difficult to set, because... Okay. The point is that when you are working on a project for so long, usually all the maintenance, it becomes boring. I mean, it's not enjoyable anymore to, oh, I know there is a bug. What happens here? There are some pixels that are not growing currently when you rotate. It takes a long time. There are those kinds of bugs that require a long time to investigate, to set up an environment, just to test the bug properly, the multiple platforms, everything. It becomes boring.
You must have so many weird emulators installed to test all the weird consoles. No, no, no. Actually, at this point, I don't have that. Oh, good, good, good. That's true. I never had a Mac, for example. Yeah, yeah. The Mac backend has only got... That's someone else's problem now. Yeah, yeah. The point is, maintenance becomes a boring task. So you are all the time thinking in other ways to make it more entertainment, the process of keep working on railing. Right. Okay. So the result in this last release, I also released one month ago or so, a tool that it was intended to build a project structures.
mostly intended for newcomers. Because what I've seen in the past, or along the years, is that the new people that start with RedLive usually start with a .c file that plays anywhere, and they start working with that c file, they compile this c file, and they play with the c file. But at some point, you need to maybe create other c files, all the modules, you need to include some additional library, some RedLive extra library, you need to add the resources, and you need to do a more, let's say, more professional project setup. What I said at the beginning, what I've seen in the university, that when students have to do a full setup, with the build system, continuous integration, delivery, GitHub, licenses with me, contributors, conventions, all these kind of environment, full environment pieces, they usually struggle, they have problems. So despite I'm a bit against providing a tool to do that automatically, because I think that students should learn to do that.
Well, I agree with that. Yeah. Yeah, I guess it doesn't fully do it. I mean, it sets it up automatically, right? But then they're still working with it. It's not like it's abstracted away behind a UI. They get the output and they have to work with it, right? Yeah. You just define some names, product name, project name, company name, resources, directories. You define some basic properties of the project. And then the tool basically pickups a template. Actually, the tool is open source and template is there. You can check that and modify. And just renames everything that needs to be renamed to follow the naming that the user has provided. And it creates a project.
We can pre-configure makefile, VS Code task, Visual Studio 220 tasks, a complete continuous integration system for multiple platforms to build the project and to make a release and automatically attach the build project. It configures the resources. So it gives you a Ritme template with something pre-configured. It gives you a full structure with many, many things already pre-configured. And then you can just pick that up, put it somewhere in your computer and upload it to GitHub. And you have a full base project to start working in a kind of more professional way.
to create not only small demos, but also some kind of a small, mid-sized game. That's awesome. Yeah, that was a tool. But going back to your question, where is the limit? I always have clear that the limit is that RightLip is not an engine. It does not pretend to be an engine. Probably a high-level framework in the borderline between an engine, but not at that point, because I think that an engine, in my experience, some of the things that need to be provided are some kind of a screen manager system, some kind of system to manage the different screens of the game, some kind of...
entities or game object managing system. That could be a simple array, but that could be something more at least or something more complex. And the third part that I think every engine should have is the content manager, the resource manager or the asset manager, an integrated system to process all the resources and manage all the resources. So I think those three systems are the three key parts an engine should have, and right-leaf doesn't have those parts. And actually, it's supposed that the user can build those parts by themselves.
And I think they are not that complex. Actually, there is a screen manager example in RightLib as an example that is a simple switch that can change from one screen to another screen, even with some transitions. So it's kind of fancy. To manage the object, you can have only a list of an array. So it shouldn't be that dramatic. And for the content manager part, it's probably the more complex part. I created the REST library with an REST packet tool, trying to kind of supply that third part that would make RightLib more aligned with an engine. Interesting. Yeah, that's the line I said. Yeah, but besides the line, I mean...
Even with that line, you can do very interesting things. Like, for example, the Project Configurator, the Riley Project Creator, it's one of those things. It's a tool that setups on the project. And now, actually, I'm thinking about another tool. I'm thinking I got it designed, and I haven't really seen it yet in the future. But that's another step that I've also seen sometimes could be dramatic for people starting with Riley. That could be like a third tool to do easy the process to build games to multiple platforms.
I feel like we talk about it too much on the show, but we talk with game developers a lot about porting to other platforms and what a nightmare it is. So I could definitely see how that would be a useful tool. Yeah, but for that reason, Unity and Real Godot are so successful. That's always the most complex part of game development. Besides big games that try to push the graphics to the limits or try to innovate a lot in some aspects, usually building for multiple platforms is a drama. Yeah. So we've spoken a lot throughout our chat about how big the ecosystem is and the fact that people are contributing more and more and you're now in a position of being much more in reviewer and maintainer mode. In the lead up to this, I always have a little poke about the projects, look at the ecosystem, look at what it's doing.
I do not understand how you have the time to do a thing you do. I think your Reddit alone is ridiculous. Let alone Discord, let alone running your own game jams, let alone all of it. So I guess just straight at the top, what is your community management approach to this project? How do you think about managing and growing and nurturing that community as a maintainer? I don't have that much time. Actually, it doesn't necessarily match. So about six hours a day, so that's okay. But in the last two years or probably in the last three or four years, my time put into the social networks and the Rally community in general has been increasing a lot day after day.
Maybe, I remember I started by 2020 because of the pandemic that I was at home and everything, maybe I spent one or two hours a day. At the moment, I'm spending probably five, six hours a day easily. And that's a lot of time. And not only the computer, but a lot of time with the mobile phone. And, well, I got multiple communities, X, Blue Sky Wrestling, Reddit, YouTube.
Discord. Discord is the community where I spend most time because I've seen the community there growing super fast and actually it's a super nice, super nice community. I just spend a lot of time welcoming new users, trying to help, trying to answer their questions, trying to engage with them. I do a lot of everyone to try to create that engagement. And I also did a lot of actions in X and now in Blue Sky, trying to create content and trying to engage the audience in that sense with some buyer, with some images. But yeah, you have to think about it. You have to create it. You have to...
Try to publish it in a certain moment that you think it's going to work. And actually, the community management work, it's a full-time job if you do it. And also what I've noticed in the last few months is that it's probably taking too much time of my time. The different communities, the different social networks from Raylib from developing, for example, the tools or the separate libraries. I got several tools that have not been published yet and I want to publish. The installer that I publish with, Raylib.
installer was supposed to be published one month ago in my timelines so i'm trying to to manage that at the moment some way but it's so addictive you know yeah yeah very instant feedback right yeah but it's not only the instant feedback it's that you have created something that has become super popular and there is a lot of people that maybe send you mails and write you write a message and contact you and are using that tool and ask you for help that somewhat you feel like you have to do that yeah that it makes sense yeah and it becomes addictive and Yeah, well, at the moment, I'm trying to manage it better and trying to limit the time I put on the social networks and on the community. But it's true that for the last two days, since I published Rally 5.5, I did connect to... Around big releases, it makes sense to be a little bit more online, I guess. Yeah, yeah, yeah. Rally has been released two days ago, and there have been like 15 merges already, 15 pull request merges in those two days. Yeah, it's certainly a lot of work, for one.
one person. It's too much work for one person. Financially, it's not sustainable. That was going to be my next question. Because I mean, I know I've seen you mentioned interviews in the past that, you know, you've gone from, you previously had a cycle of having a full-time job and then coming back to Raylip, having a full-time coming to Raylip. I know you've received various grants over the years, but I think I saw in a Discord AMA that I think as much as, I think it was recently, I think it was in September that you said, you know, currently the project is not super sustainable and it's hard to do basic maintenance. So how economics of open source is always an issue. How are you currently maintaining this work?
I wish I had a good answer for you. Like, yeah, it's funded with... Well, at the moment, I received some donations. I got GitHub sponsors. I got some sponsors, and I also got some patrons. All the numbers are open. Okay, so you can go there on GitHub Sponsor or on Patreon and check the numbers. Donations are quite low. I think it's about $700 per month, something like that. It's not that much. Yeah, I also try to make some kind of business with all the tools, with the running technologies, and I publish tools. Some tools are free, actually.
but some tools are paid. And they actually sell, but neither very low numbers. And besides that, I maintain relief by my puntual contract work that I do. Here in Barcelona, for example, I collaborate with GameBCN that helps new companies, new startups, video game startups to start. And I collaborate with them with consulting, different educational optimization, methodologies, processes. I help them with that. And besides that, I work from that time in the university to teach some subjects for a span of time.
at the moment that's my situation yeah it's different moving parts but yeah i'm quite concerned about that you know because it's not i have no stability right no that's not stable in the long term and it's never sustainable so i'm just living a bit day today and i'm thinking what to do next so it's complicated yeah yeah yeah such a also just you know two industries renowned for being unstable economically being a video games developer being an open source developer and there you are in the middle of them Well, if you're listening to this folks and you've got some GitHub sponsorship money, you know where to put it. I highly recommend. So we are coming towards the end of time. So there's one last question I wanted to ask you. I know you've just released 5.5 and you're very focused on that, but I guess what's next? Are we talking a 6.0? Is it a 5.6? What's next on the roadmap? The truth is that for the last two years or so, I've been saying that, okay, that's the last release. Oh, really? Wow, okay. Yeah, I tried to move on and look for something else. But then when the release happens, there is so much engagement in the following weeks and months that I just keep working on it.
Also, it's true that I see the project and I believe in it. I think, wow, that's a great project. And most of the people that have tried RightLip really praise it and really love it. So I hardly ever hear bad reviews about the library. A lot of people really enjoy it. Here I have something that...
could help a lot of people, but not only education, but to spread programming, to spread low-level programming, to get a better understanding on video games development. I mean, I really believe in the project. And that's probably what keeps me pushing it month after month and year after year to try to make it somewhat sustainable at some point. Yeah. So, yeah, that's it. So I don't know. I don't know what's next already. For the moment, I am focused on a couple of tools that I want to get out, I want to publish.
maybe before Christmas, I don't know. Then there is one tool that we're talking about that when I created the project, the Rally Project Creator, I planned a second tool, but I probably can't tell you what it is, that it's a project builder that in a similar way, you can just click a button and get an InstaBuild for Windows, for web, or for other platforms. Maybe I will release that as a small tool, as a support tool for Rally. I don't know what's next. I don't know what's next. The community is already pushing to other graphics APIs.
I have seen the endless discussion about Vulkan. But actually, there is already some user, because, okay, usually the community is always asking for things. But there are not that many people doing the things they ask for. But it seems that there are a user that has created a backend for DirectX 12. Oh, wow, okay. And it's already functional. That's a big job. That's a big job, indeed. And yeah, and I saw that, and it goes, oh, that's super interesting. Maybe we can open that box and consider supporting other graphics APIs other than only OpenGL. But yeah, again.
The amount of work, not only to do that, that it's a big amount of work, to do that, to integrate that, to maintain that, it's so big that it's scary. I can't do that alone. But then as you say, the fact that someone has gone as far as to start that themselves is a good, hopefully, it's a positive indicator that you won't be doing it alone and that this is someone who's going to get really engaged. Yeah, absolutely. Absolutely. And actually, I got some people in the Riley community. Shout out for Jeff. It's really pushing the Riley community a lot. And he's a creator of Riley Extras and actually is doing a lot, a lot for Riley.
We have to have a discussion. We set the discussion after Rallyu 5.5, so probably now it's the moment, to see what direction can the project go from here now. Yeah, let's see. So it's an adventure. Yeah, absolutely. Fingers crossed. It eventually gets a little bit easier. But for now, thank you very much for your time for the run. It's been wonderful. Thanks for spending the time with us and running us through so many amazing details about the API and the community. It's been a pleasure talking to you. Oh, thank you very much to you. Thanks for inviting me. And it's always been a pleasure to be here. Thank you.