SDL VS raylib

Since I keep the SDL include and lib files local to the msvs project for Windows, I downloaded SDL3-devel-3.2.8-VC.zip file from GitHub.

You see, for the past several years I have used many programming languages and many more game frameworks and libraries. Programming languages like Java, C#, C++, and even, sadly, JavaScript (I know...). Game frameworks like LWJGL, SDL2, Raylib, MonoGame, SFML, and many more. Essentially, I have seen it all. Out of all of them, I think SDL2 was closer to what I was looking for, though, Raylib was the one I used the most at the beginning. And the reason I liked SDL more was because it was more"lower-level" than Raylib or SFML. Additionally, it had that C-style of programming that I have always been fond of. However, despite that, I decided to go against any of these libraries.

> cross platform/web/mobile distribution

Unfortunately, each and every platform has its own unique quirks[], and I think the problem is too large for a project like LÖVE to tackle.

In fact, LÖVE's authors have already done "90% of the work in 10% of the code": you can make a ZIP file, change the extension to .love, and just distribute that. Install LÖVE, double-click YourGame.love, and you're done. You can also concatenate the game executable with the ZIP file to create a self-contained binary distribution for that target platform (super old & cute trick; it's possible because ZIP's "header" is in fact, at the end of the archive).

[]: In 2016 I've attempted a "one game per month" challenge; but I also wanted to distribute executables for Windows, macOS, and Linux, so that all of my friends could just play them. It went something like this:

- Windows: distributing executables from your personal domain is considered a crime; the browser and the OS will yell at the user, block the download, blacklist you, etc.

- macOS: simply concatenating won't work; you need an elaborate dance to create a .app bundle, and distribute that in a .dmg - good luck building that on a Linux host, also good luck debugging without an actual Mac. Nevermind code signing, you can bypass that with shift-right-click-open. Oh wait, macOS 15 won't let you.

- Linux: are you ready for the .so hell?

- BSD: bonus! The documentation for SDL_GetPlatform doesn't even enumerate all of the possible values! You need to source-dive to get them: https://github.com/libsdl-org/SDL/blob/f45ce45603a00e92332f9... - plus any possible patches in ports; most developers won't ever care, and will just hardcode "Linux". Checking for $DISPLAY is also unreliable: macOS users may have XQuartz installed, Wayland purists may run without XWayland, etc.

The current status of X11 is that it works.

The current status of Wayland is that it doesn't.

It's really that simple. I think this exchange can help you understand my position better: https://github.com/libsdl-org/SDL/pull/9345#issuecomment-201...

>Wayland has a myriad of unresolved problems regarding surface suspension blocking presentation and the FIFO (vsync) implementation being fundamentally broken leading to reduced GPU-bound performance.

To which someone replies:

>If we do this, we are basically accepting these issues are unfixable for the next ten years (SDL4). Having this as the default in SDL3 (which isn't being used yet!) is important for signaling to other stakeholders that we actually do need to get solutions in place for detected issues.

To which the committer says:

>SDL is not your tool for "signaling to stakeholders" about what is important. It's an actual library used by real developers and users!

Likewise. My PC is not a tool for signaling library/DE developers that there are more and more people using Wayland now and that they can finally stop maintaining X11 legacy code. I use my PC for real things. I couldn't care less if things are running on X11 or Wayland so long as they work.

If Wayland isn't working with my use case, I just won't use it. I won't switch to Wayland juts to beta test it, and then spend years begging people who know how to hack Linux to implement the features I need that I had on X11.

If Linux drops X11, and Wayland still doesn't work. I won't use Wayland. I'll use Windows.

Very cool project, and well thought with the choice of Raylib or SDL2. But since Raylib can compile to Android (https://github.com/raysan5/raylib/blob/master/examples/Makef...), do you think it could be difficult to add Android as a target platform ?

You could take raylib (https://www.raylib.com) and bolt quickjs to that.

I don’t have a review, but here’s a significant project using it in a complicated cross platform build with different systems dependencies: https://github.com/raysan5/raylib/blob/master/build.zig

They also have a cmakelists.txt to compare against.

One of the nicer things is that if you’re working with less technical folks, they only need to download the zig binary because it bundles the entire toolchain.

As I play around with raylib, the small, easy, and exceptionally cool game library, I met a small issue. There is no elegant way of packing files together. When I use a texture or audio, or any external resources, I either need to convert it into a C++ header that declares a byte array filled with that resource, or making sure the the user having the resource at the particular place. The first approach is no good when comes to loading new resource after compilation, while the latter approach is kind of awkward and too easy to break.

For this most recent assignment we were tasked with contributing a larger feature to an open source project. During my time with the previous assignment I worked on a game engine called Litecanvas, inspired engine by libraries like raylib and p5.js/Processing.

Let's take a look at another API. Raylib. Now Raylib does a little bit more than just load images. Raylib is more of a game framework than a single-purpose library. It will create a window, handle input, load images, render pixels, handle loading and rendering fonts, and so on. Even though Raylib does multiple things, it doesn't go overboard. It tries to be simple yet robust. There's a clear vision for the library. They didn't try to force a GUI editor into the API or an alternative string type. It had one goal and that is to become a game framework. What happens when Raylib has added all the features it needs to add? Well, call it feature-complete and just move on. There's no need to bloat an API for no reason other than you "felt like it".

Don't like having to use gigantic game engines to make games? Here's a whole suite of beautifully simple libraries with bindings for a lot of languages: raylib