EPISODE 1780

[INTRODUCTION]

[0:00:01] ANNOUNCER: 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 a start in software development by creating mods and running servers for Gary's Mod. End game development remains his favorite way to experience and explore new technologies and concepts.

[INTERVIEW]

[0:00:58] JN: Ray, welcome to the show. Thank you for joining me today.

[0:01:01] RS: Hello, Joe. Thanks for having me. It's a pleasure.

[0:01:04] JN: As we mentioned, you are 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 application 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?

[0:01:26] RS: Well, actually, before Raylib, I was working in video games development. I work in EA for some years, and also working in small companies. I also tried to create my own company, published a couple of mobile games for Windows Phone at that moment. 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.

My task was teaching video games, programming to mostly art students. Yeah, that was a challenge, because, well, usually, the art students were not that interested in programming. The first option was using some no-code tool, like the [inaudible 0:02:16]. At the moment, it was the beginning of Unity getting into the market. I decided to go low level. I really tried to teach actual programming to art students. To do so, I did some tests. I started with C, and I checked some libraries out there. After some months of trying different approaches, I found one that actually worked, that was a very, very old library called Borland BGI graphics. That's from the 70s, maybe.

Surprisingly, it worked extremely well, because it was super simple, like init, close, draw. It was super simple. After that first year of teaching, I decided to create an alternative to BGI, but more adapted to modern times. Modern times at the moment, I mean, OpenGL. I did so. It was a weekend project, actually, Raylib. Just in a couple of months, I got our first version quite complete with a lot of functionality to do some 2D, to do some 3D, and everything. I started testing, or using it with the students. 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 poll, that the moment was the assignment in the subject. 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 no path, and compiling, and running their games. Yeah, that was the origin of the library. From there, I started getting a lot, a lot of feedback, because the students were quite excited about the library, and started asking for improvements, reporting bugs, letting other students from other institutions know about the library, and the library started growing.

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. Yeah, and it started growing. At that moment, I was re-activating my company, the previous one that I had published Windows Phone games. At that moment, I started working in the library with a few students. The plan was to keep working on games in this development. Actually, we released a PS data game at that time. Most of the day was working in Raylib. It was six hours per day working in the school, teaching with Raylib. Then there was another six hours every day working in the office with some students developing Raylib.

[0:05:06] JN: Incredible.

[0:05:08] RS: Yeah. I did work for about six years, that way, something like that. Five, six years. Yeah, and really kept growing and growing and growing. 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. Yeah, the library started getting recognition in a lot of places and started to grow, and really, really were becoming really, really big. Yeah. Since that moment, for the last five years, actually I quit at that moment teaching to focus 100% in the company to not only develop Raylib, but also develop an ecosystem around Raylib with some libraries and to develop tools focused for video games development, but always using Raylib as the base technology. The technology kept growing along all the other products around it, also were built. Yeah, that's mostly to today.

[0:06:15] JN: That's awesome.

[0:06:15] RS: At this moment, Raylib 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.

[0:06:28] JN: Yeah, it's a huge achievement. I think I saw, so, well, we're talking about it a bit today, but you've just released Raylib 5.5. I think I saw, was it 150 contributors to 5.5?

[0:06:39] RS: Yeah. About 150 for this release alone, but about 650 overall along the years.

[0:06:47] JN: That's awesome. Yeah, that is a huge achievement. Also, just going back to that, the early days in that first class, I think you must have had the most engaged class of students in the world to share the library and start contributing to it. That's awesome. I definitely want to ask you just from an educator's perspective about how you approach that task of choosing C to teach art students. We'll get to that later on. 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.

[0:07:25] RS: Yeah. Actually, the library itself is quite simple in terms of programming. I mean, not internally, but the API, it's quite simple. It's just C library, so there is no any abstraction, like object-oriented programming, or anything. It's just functions, procedural programming, and structures with data. Mostly all the structure are completely transparent. I mean, they are not open pointers to some internal structure. When you create an image or a text tool, you just define it like any other variable, and you have to ideally exit to my image point with K format and everything.

It's all the library itself is kept. Oh, 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 end up working as a pro [inaudible 0:08:31] in different companies, so that's amazing. Simplicity is one of the key points of the library. Besides that, the library tries to cover mostly the basic functionalities that you need to make a small, or mid-sized game. You got functionality to manage the window, the inputs, all inputs, keyboard, mouse, gamepad. You have functionality to load images, to upload them into GPU as text tools, to load models, the meshes, the materials. Well, that's 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, it's portable, that can be used outside of Raylib. You also have some basic functionality to, well, to draw text tools, models, and to play out, to load out and to play out here. 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 have seven modules, so that means seven C files. 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, all your pipelines, and I know how complex can it be, actually. I tried to simplify building at maximum. I tried to keep all the library very small and set containing entire architecture, but I also tried 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 is completely self-contained. De-couple of anything, so you can just pick up the audio module that are a C file with some headers, 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 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 shape, like circles, rings, rectangles, rounded border rectangles, well, lots, lots of types of shapes, you can just pick that module and again, it's the same. Okay, you have to provide seven functions, but mostly any engine already gives you those seven functions.

Well, that's the same with every module. Then another of the important part of the library, it's an abstraction layer over OpenGL. That's why it's one of the key parts of the library. It's called LGL. It's a mapping of multiple OpenGL versions from legacy OpenGL to modern OpenGL, into immediate mode OpenGL, kind of. Okay, you also have all the extra functionality to load the meshes and the vertex buffer and everything, but it has a small set of functions that let you just use that library, like the immediate mode OpenGL 1.1.

Actually, that proved to be very, very, very useful, because in this latest release, I saw that some people ported Raylib to work on all consoles, on retro consoles and on all new consoles. That was thanks to that support for the OpenGL 1.1. Well, backend, because it's one of the backend. It's not the default one. By default it 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 it's more useful. l, so my writing all together, because you think I am going into many topics, the library itself, it's intended to basically draw anything on any display, it could be a game, it could be demo, it could be some multimedia application, it could be a tool, or yeah, anything.

Considering it's C and it supports are a really wide number of platforms, yeah, actually, I've seen the library used for many, many, many kinds of applications, not only games. Actually, I'm electronic engineer, and I love seeing the library running on embedded devices for calling some display or anything. Yeah, I love it. I see that running in an embedded device.

[0:13:42] JN: Yeah, that's always exciting. I think the classic example is people putting doom on silly things, right? Whenever there's 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 a pregnancy test, or whatever it is, people are putting, for example, that's awesome. Okay. God, so much to talk about. 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 your principles of the API design, and wanting to keep things simple, given the background of the project, that totally makes sense, but it's been 11 years, you've had loads of different users come, the library, the audience has really grown, so I'm really interested in how you approach API design, in design there's what, 350, 380 functions? There was an update in 5.5. There's a lot of functions now. There's a big API surface area. So, how do you think about the design of that API now with the past, present, and future audiences?

[0:14:42] RS: Well, that's a good question. Actually, at the moment, Raylib 1.0 started with 80 functions. Only 80 functions. I thought that was enough to make many kinds of games. But Raylib 5.5 has reached the 580 functions. So, yeah.

[0:15:02] JN: I was a little bit off. Yeah, that's great. That's awesome.

[0:15:05] RS: I also have to say that a couple of years ago, I did an analysis of the market, and I look for all the open-source GitHub repos using Raylib that I could farm. I compiled 200 repos also. I did some text analysis, text scrubbing, and I listed the most used Raylib functions in all the source files, only those 200 repos. Guess what, what was the surprise, where the most used functions? Actually, were the 18 functions on the library -

[0:15:42] JN: That's amazing. That's such a cool library as well.

[0:15:46] RS: Yeah, init window, close window, the draw rectangle, begin drawing and drawing, drawing circle. I mean, low texture, draw texture. I mean, the simple ones were the most used ones. I mean, also there is some BS here, obviously, because at that moment, the library has been in the market for eight years. Yeah, people start and they use the first version, so there is some BS in that analysis, obviously.

Many of the advanced, advanced functions added to the library were barely used, actually. There was not many people using them. Yeah, it was surprising. But answering your question now, how I approach the API, simplicity is always the key for me. 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. 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 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 at that functionality in that level, but not in the low level. I try to keep the library at a low level.

About things that I always keep in mind, for example, their function names. Function name will always follow the same pattern. They try to follow the natural language. As much as possible, do not follow a programmer language, because when you call, you tend to use the technical terms that you should use to name everything. Sometimes if you think of the people that is going to use the library that maybe it's people with not that much experience, it's easier for them to name the functions with some easier names. But all the functions you really follow along the pattern that bear subject and object. There are usually two, three words at maximum. Sometimes maybe four words. 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 -

[0:18:10] JN: Yeah. That's great.

[0:18:11] RS: That's more it. I try to keep it simple all the time. That's my objective. Sometimes it's not easy, because you have to do things that get complicated. 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 terms to be too complicated, I try to abstract as much as possible. If it's a low-level functionality, I try to keep internal early and just expose the minimum required for most of the users, and then maybe allow some flags, some blue 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 Raylib, but maybe in an auxiliary library, or a secondary library, I actually got some of those secondary libraries. I got right away that it's a library to create UIs, mostly intended for tooling, but it has a lot of immediate mode UI functionality. Got also address for resources packaging. That's also another library. Well, I got random number generator. I got several auxiliary libraries that, well, are in that really Raylib ecosystem, and are intended for users that need that extra functionality for their specific project, can use those libraries.

Actually, that's year or so, like one year ago, or one year and a half ago, one Raylib developer in the community created a separate organization, a separate repository called Raylib Extras that has proven to be very, very, very useful, because for all that people that came to the community asking for advanced functionality, a common answer is, "Oh, maybe not for Raylib, but you can add that to Raylib Extras." 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. But 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.

[0:20:30] JN: I did notice that the cover image in your Discord was a voxel-like rendering.

[0:20:35] RS: Yeah, there is a lot of users that are starting with Raylib and come to the community and, "Oh, I want to make a Minecraft." It's okay. And they start, okay, so what we need, we need some kind of tree, and all that. But in Raylib Extras, actually, there is a Minecraft template with everything to that, with a lot of extra functionality. It can be used as a reference. Not everything has to be in Raylib.

[0:21:05] JN: Yeah. 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 focus 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.

Going back to one of the things you mentioned, you mentioned parameters. This is one of the areas that I think is really interesting, particularly about, well, API design with C, but also, particularly for your audience, which is 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 and C trying to teach beginners.

[0:21:51] RS: Well, actually, I forgot to mention about that. The objective, the thing was avoiding pointers. The first set of functions for Raylib had no pointers at all. The data structures 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 structures provided. Actually, the structures are quite small, usually under 32, 48 bytes, so it's acceptable to pass them by value. 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. I think they are out maybe 20, or 30 out of 580. In some cases where you really need pointers, because obviously, have to load data. For example, an image, image you have to load data. Then the pointer is just kept inside the structure. You've got the structure with width, height, format, mid-maps, and the pointers to data.

Or if it's textures, well, the data is already in the GPU, so you've got the identifiers, so that's easier. What I tried 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. Yeah, that's a completely different mentality, because for them, they usually love programming, and they usually love to go as much technical as possible and go into details. Actually, even though the beginning of this year, I was teaching in the university to computer science students, well, actually, I was teaching Unity. I had to teach in the syllabus about programming patterns, solid concepts, and all of these information.

I'm so used to coding C with a procedural way, with just data, it's 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. I tell them. I let the students know that that's an option.

[0:24:22] JN: There's another way. Yeah.

[0:24:23] RS: Yeah, that's another way. 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 the data, and that's a bit of the philosophy of Raylib, where you've got data, that you move around, and you just call functions that operate over that data, and sometimes they return you a value.

I think that after many years working in that project, my mentality, it's so focused on that way of programming, that when I look at the different abstractions of the early programming, C++, the version of C++, the solid, and the solid concept and everything, it's kind of, wow, no way. I mean, programming can be way simple than that, and works.

[0:25:23] JN: Yeah. No, no. It's something we talk about a fair amount with 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 the lower level, and to get down to simple abstractions, and to just, because you know, it just has to render once and render once on the screen, and you don't have to maintain it for a million years, and this stuff. It's also, it's really interesting, so first of all, a complete tangent. You taught at UPC, right?

[0:25:49] RS: Not this time.

[0:25:49] JN: Okay, cool.

[0:25:50] RS: I think in several universities, because I usually talk for some time, maybe one year, two years. I make some money, and then I can be some time.

[0:26:01] JN: Back to Raylib.

[0:26:02] RS: Yeah. Well, working on Raylib, and the tools, and all the ecosystem. This is the 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, a computer science degree. This time, I was teaching them. Before that, I was in the UPC for two years.

[0:26:23] JN: Cool.

[0:26:23] RS: It was 2020 to 2022, something.

[0:26:26] JN: That's awesome. Cool. Yeah, they have a - I guess, you would have been - the reason I asked 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. Yeah, they would have been a great audience for Raylib. You mentioned teaching Unity, and I think it's - 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?"

[0:27:07] RS: 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, because 60 hours in total, then we jump it into, at that moment, it goes into mono game, and after that, we jump into Unity. I thought that was a great path, because Raylib was low level, was C, then you jump into mono game, that actually Raylib is very inspiring in mono game with the naming conventions and the structures and everything. 

With no mono game, you can learn C-sharp, you can learn some object-oriented programming, and some more advanced concepts. Then, when you understand that, you can jump into Unity, because then all the game looks, 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. 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 Raylib. It's designing a way that the source code, it's very, very, very simple to read. It has a lot of comments, avoids any complex programming techniques. It's very simple in terms of code.

A student had one to dig farther. Actually, I had many students that had gone inside Raylib, and then had sent improvements and have 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. I think that's a great path, actually.

[0:29:14] JN: Yeah, I agree. That does sound really fantastic. I guess, along that way, as well, people, there's this perpetual issue in computer science education, where they try to teach the abstractions before the student has encountered the problem that requires the abstraction. I always think about this with git in version control, right? The universities tried to teach version control before students have worked on big code bases with lots of people and understand why it's helpful to them. It's just another thing in the way. In that path that you describe, you get to see the low level, and then you get to introduce the mono game, 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. Then you got the scenes in Unity. I think that's a really great approach. That's awesome.

[0:29:54] RS: Yeah. Actually, there's another point that we didn't mention. I got it in the head since the beginning. It's about building systems. 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 in 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 it's a standard in the industry thing, how to properly configure a project in Visual Studio. Then from there, move on and not only use the configuration system, but even set up some continuous integration, continuous delivery, that nowadays, it's quite standard and quite simple to set up these systems. That's one of the problems I found with the students, and well, I try to address whether that's possible.

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 is the easy part, actually. Usually, if you are in a big company, there are many, many, many other site 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.

[0:31:39] JN: Yeah. I mean, we could turn this into a whole education episode. But yeah, I understand you clearly. I think a lot of that instinct to just wanting to press the play button also comes from 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. I always use the analogy of like, it's the difference between learning how to use a tool versus maintain the tool. 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. It's going to blunt and you have to start again. Yeah, I think it's a fantastic point.

[0:32:11] RS: Yeah, but sometimes your spoon can broke, maybe. Then you have to do something.

[0:32:16] JN: Yeah, absolutely. 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. I guess, to start with, so 5.5 was a big release, right? You're working on this one for a while.

[0:32:33] RS: Yeah. Well, actually, it's been one year of changes, like what? 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. That's it. Mostly done 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, the reviews are very key and attending the community and helping the community, trying to help the initiatives in the community, organizing game jobs, and doing a lot, a lot of community work, because actually, it has grown a lot. It's difficult to manage.

[0:33:21] JN: That must be very exciting, but also, I imagine, as somebody who like writing code a lot, that must be a really interesting mindset change.

[0:33:27] RS: Yeah. Well, actually, I still do, but I do with my tools. I develop tools, I probably use the tools, and in that side, yeah. I write code a lot.

[0:33:37] JN: You've given the library to your community, and you've gone to your little playground in the corner.

[0:33:41] RS: Yeah, actually, because as all the tools use Raylib as the 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 good.

[0:33:56] RS: That's really great. Yeah, 5.5. What's new in 5.5?

[0:34:02] RS: Yeah. That was the question. Yeah. Well, yeah, it's been one year with all those changes. 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. It's a long checklist, actually. You have to check the compilation for all the platforms. You have to check the examples, 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 Raylib version, actually, it's created with Raylib itself. Actually, it's one tool that I sell to create installers.

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, Raylib's 5.5 installer is the test version. There were some things that were not working as expected, and it was like, "Oh, I have to release this day." Well, it was a bit stressful. But, yeah, it's out.

About the features of this new release, well, there are many, so I cannot list all 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 Raylib 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. It was multiple defines to select the platform that it was building the code for.

[0:35:48] JN: I see.

[0:35:49] RS: All that code was moved into separate modules to have one module for platform. There's one module for platform Android, one module for platform DRM that is for embedded systems that run over the core. 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. I kept the core module just like a wrapper to the different platforms, and then a compile time, you choose the platform you want, and it compiles.

[0:36:24] JN: Very cool.

[0:36:24] RS: 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 drink as even Nintendo 64, PS Vita, PS4 homebrew, PSP led me. Yeah, they only have to write one module, like core PS Vita, core PS4, put all the Window media input code in there, then enable the OpenGL 1.1 backend, and link with the platform libraries for the OpenGL 1.1 backend. We have seen that's another of the features of the 5.5. We have seen a lot of porting of Raylib to all consoles, to retro consoles. It was like, wow, unbelievable.

[0:37:20] JN: That's awesome. Yeah, especially Dreamcast, that's wild.

[0:37:23] RS: Well, actually, even a spine is working on Dreamcast. Even the 2D animating system is working on Dreamcast. That's wow, it's amazing. Beside 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 it's called, well, the naming for the graphics libraries are sometimes a bit complex, but it's LGFW.

[0:37:51] JN: Oh, yes. I haven't figured that yet.

[0:37:52] RS: Yeah. It's a library for abstract, the windowing and input system, but it also supports Windows, Linux, Mac, it also supports web lately, or it's about to support web. 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 the library into your code. Yeah, and you got a full backend for multiple operating systems. That's great.

Well, it was added that backend option to Raylib, because in the last month, I've seen a deceleration in the maintenance of GLFW library, that's another popular library. Just in case for the future, it was great to have some alternative supported by Raylib. Also in the same line, recently, it was published, or I don't know, it's still in alpha or beta to officially published, but SDL3 library, that's super popular library for windowing, and inputs. Well, it's widely used in many games. It also added a module for super multiple graphics libraries that at the moment is not used, but it's interesting to keep an eye on it.

Well, another of the supported backends was SDL2 was already supported. Thanks to contributors, because oh, that has been done by contributors. I just review, it was on the computer, was the support for SDL3 backend.

[0:39:32] JN: Cool That's awesome.

[0:39:34] RS: 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. 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 Raylib, it was done in CPU. That's great for small models, up to maybe 2,000 vertex. That's not a problem. But the community was asking for GPU skinning. Well, actually, they were asking it, because Unity added it. As many, there are many Unity users, probably they sell GPU skinning, and so they ask for GPU skinning. It has been requested many, many times. I was quite reticent to 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 devices, or a bit devices, or web, it's not simple. It has limitations to implement the GPU skinning, because it requires more advanced OpenGL features.

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. Yeah, it finally was merged and added to Raylib as an additional option.

[0:41:19] JN: 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 interesting to me, because you've got this low-level C header-only library, and you're starting to build out and include ecosystem of tools around it. I think the installer adds you get a version of Notepad++ for it, and everything as well, right?

[0:41:42] RS: Yeah.

[0:41:44] JN: How are you thinking about what's acceptable tooling to wrap around the library, without taking you into a full desktop engine situation, right? Where's the line?

[0:41:54] RS: Yeah. Well, actually, that line, it's quite difficult to set, because, okay, the point is that when you all are working on a project for so long, usually all of them maintainers 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 drawing, currently, when you rotate, and it takes a long time, usually." There are those bugs that require a long time to investigate, to set up an environment, just to test the bugs properly, the multiple platforms, everything, it becomes boring.

[0:42:33] JN: You must have so many weird emulators installed to test all the weird consoles.

[0:42:37] RS: No, no, no. Actually, at this point, I don't have that many -

[0:42:40] JN: Oh, good, good, good.

[0:42:41] RS: - emulators. That's the truth. I never had a Mac for example. The Mac, again, has probably got -

[0:42:47] JN: That's someone else's problem now.

[0:42:48] RS: Windows back with Unity. Yeah, yeah, yeah. The point is, maintenance becomes a boring task. You are all the time thinking in other ways to make it more entertainment, the process of keep working on Raylib, okay? The result, in this last release, I also released one month ago or so, a tour that it was intended to build a project structure more intended for newcomers. Because what I've seen in the past, or along the years, is that the new people that they start with Raylib, usually start with the point 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.

At some point, you need to maybe create all the C files, or the modules. You need to include some ex-additional libraries, some Raylib 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, that what I've seen in the university, that when students have to do a full setup with the build system, continuous integration within the library, GitHub licensees, readme, contributors, conventions, all this, get ignored, all this environment, full environment pieces, they usually struggle. They have problems. 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 they would do that. Yeah.

[0:44:28] JN: Yeah. I guess, it doesn't fully do it. I mean, it sets it up automatically, 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.

[0:44:38] RS: 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 picks up a template, and then actually, the tool is open source, and the template is there, you can check that and modify, and just renames everything that needs to be renamed it, to follow the naming that the user has provided. It creates a project with a configure, make file, BS code task, Visual Studio, 220 task, 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. It gives you a readme template with something preconfigured. It gives you a full structure with many, many things already preconfigured.

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 more professional way, to create not only a small demo, but also some kind of a small mid-sized game.

[0:45:55] JN: That's awesome.

[0:45:56] RS: Yeah. That was a tool. But going back to your question, where is the limit? I always have clear that the limit is that Raylib 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 screen manager system, some kind of system to manage the different screen games, some entities, or game object managing system. That could be a simple array, but could be something more at least, or something more complex.

The third part that I think every engine should have is the content manager, their resource manager, or the asset manager. An integrated system to process all the resources and manage all the resources. I think those three systems are the three key parts an engine should have. Raylib doesn't have those parts. Actually, it's supposed that the user can build those parts by themselves. I think they are not that complex. Actually, there is a screen manager example in Raylib, as an example, that is a simple switch that can change from one screen to another screen, even with some transition, so it's fancy to manage the object, you can have only a list of an array, so it shouldn't be that dramatic. For the content manager part, that's probably the more complex part. I created the arrest library with an arrest packer tool, trying to supply that third part, that would make Raylib more aligned with an engine.

[0:47:48] JN: Interesting.

[0:47:48] RS: Yeah. That's the line I said. But besides the line, I mean, even with that line, you can do very interesting things. For example, the project configurator, the Raylib project creator, it's one of those things. It's that one that setups on the project. Now actually, I'm thinking about another tool. I'm thinking, I got it designed, and I haven't really seen it yet in a future, that that's another step that I've also seen, sometimes could be dramatic for people starting with Raylib. That would be a third tool to easy the process, to build games to multiple platforms.

[0:48:30] JN: I feel like, we talk about it too much on the show, but we talk about - 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.

[0:48:39] RS: Yeah. For that reason, due to Unity, Unreal, Godot are so successful. It's only, 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.

[0:48:59] JN: Yeah. 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 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. 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?

[0:49:34] RS: I don't have that much time. Actually, it don't necessarily match. About six hours per day, so it'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 Raylib community in general, has been increasing a lot day after day. 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, not only in the computer, but a lot of time with the mobile phone.

Well, I got multiple communities, X, BlueSky, recently, 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 community. I've spent a lot of time welcoming 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 BlueSky, trying to create content, and trying to engage the audience in that sense with some vibe, 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. Actually, the community management work itself, good job if you do it.

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 published with Raylib as installer was supposed to be published one month ago in my timelines. I'm trying to manage that at the moment some way, but it's so addictive.

[0:52:10] JN: Very instant feedback, right?

[0:52:11] RS: Yeah. But 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 memes, and why do you provide that message, and contact you, and are using that tool and ask you for help, that somewhat you feel like you have to do that. That it makes sense. It becomes addictive. Yeah, yeah.

Well, at the moment I'm trying to manage. Trying to manage it better, and trying to limit the time I put on the social networks, on the community. I'm through that for the last two days, since I published Raylib 5.5. I did connect it - 

[0:52:57] JN: Around big releases. Yeah, it makes sense to be a little bit more online, I guess.

[0:53:01] RS: Yeah, yeah, yeah. Raylib has been released two days ago, and there have been 15 merges already. 15 pool requests in those two days. Yeah. No, it's certainly a lot of work for one person. It's too much work for one person. Financially, it's not sustainable, and that's also important.

[0:53:21] JN: Yeah, that was going to be my next question, because I mean, I know, I've seen you mentioned interviews in the past that you've gone from - you previously had a cycle of having a full-time job, and then come back to Raylib, having a full-time and come back to Raylib. 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 as recently, I think it was in September that you said, currently the project is not super sustainable, and it's hard to do basic maintenance. Economics of open source is always an issue. How are you currently maintaining this work, yeah?

[0:53:51] RS: 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, where I got some sponsors, and I also got some patrons. All the numbers are open. Okay, so you can go there on GitHub sponsor, on Patreon, and check the numbers. Donations are quite low. I think it's about $700 per month, something like that. Not that much. Yeah. I also, I try to make some business with all the tools, with Raylib technologies, and I publish tools. Some tools are free, actually. But some tools are paid. They actually sell, but neither very low numbers.

Besides that, I maintain Raylib by my Puntual contract work that I do. Here in Barcelona, for example, I collaborate with a game BCN that helps new companies, new startups, video game startups to a start, and I collaborate with them with consulting, different educational, optimization, and methodologies, processes. I help them with that. Besides that, I work from time to time in the university to teach some subjects for a span of time. At the moment, that's my situation.

[0:55:18] JN: Lots of moving parts.

[0:55:20] RS: Yeah, it's different moving parts. But yeah, I'm quite concerned about that, because it's not - I have no stability. That's not stable in the long term. It's neither sustainable. I'm just living a bit day-to-day, and my mind thinking what to do next, actually. It's complicated. Yeah.

[0:55:45] JN: Yeah. Yeah. Also, just two industries renowned for being unstable economically, being a video games developer, being an open-source developer, and there you are a developer. Well, if you're listening to this, folks, and you've got some GitHub sponsorship money, you know where to put it, Raylib. Highly recommend.

We are coming towards the end of our time. 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? Do we talk in a 6.0? Is it a 5.6? What's next on the roadmap?

[0:56:18] RS: The truth is that for the last two years or so, I've been saying that, okay, that's the last release.

[0:56:24] JN: Oh, really? Wow, okay.

[0:56:27] RS: Yeah. I try to move on, 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. Most of the people that has tried Raylib really praise it and really love it. I hardly ever hear bad reviews about the library. People really enjoy it. Clearly, I have something that could help a lot of people, but not only notification, but to spread programming, to spread low-level programming, to get a better understanding on video games development. I really believe in the project. That's probably what keeps me pushing it month after month and year after year to try to make it somewhat sustainable at so point.

Yeah, that's it. I don't know. I don't know what's next for Raylib. For the moment, I focus 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 Running Project Creator, I plan a second tool that, well, I probably can tell you what's it, that it's a project builder. That in a similar way, you can just click a button and get an insta build for Windows, for web, or for other platforms. Maybe I will release that small tool as a support tool for Raylib. I don't even know what's next. I don't know what's next. The community is already pushing to other graphics APIs.

[0:58:21] JN: I have seen the endless discussion about Vulkan.

[0:58:24] RS: But actually, there is already some user, because, okay, usually in the community, it's 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.

[0:58:42] JN: Oh, wow. Okay.

[0:58:43] RS: It's a really functional -

[0:58:44] JN: That's a big job.

[0:58:45] RS: That's a big job, indeed. Yeah, and I saw that and it was, "Oh, that's super interesting. Maybe we can open that box and consider supporting other graphics APIs, other than only OpenGL." 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.

[0:59:16] JN: 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.

[0:59:28] RS: Yeah, yeah, yeah. Absolutely. Absolutely. Actually, I got some people in the Raylib community. Shout out for Jeff. It's really pushing the Raylib community a lot. It's a greater of Raylib Extras, and actually, it's doing a lot, a lot for Raylib. We have to have a discussion. We said the discussion after Raylib 5.5. So, probably now it's the moment to see what direction can the project go from here now. Yeah, let's see. It's an adventure.

[0:59:58] JN: Yeah, absolutely. Fingers crossed. It's an adventure that gets a little bit easier. For now, thank you very much for your time today, Ramon. 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.

[1:00:13] RS: Oh, thank you very much to you. Thanks for inviting me. It's all interview now. Pleasure to be here. Thank you.

[END]