Game Development kits

This is sort of an addendum to the page about sepples. While switching back and forth on C and C++ on that game I also switched SDKs so here's what I've used and what I thought of them. Most of this stuff is from years ago so it's probably out of date and I don't intend for it to be a guide on choosing toolkits.

SDL

It started out using SDL1 but didn't get very far before SDL2 came out and I switched to that.
Going from SDL1 to SDL2 I thought a lot of things had become more complicated. For example instead of just having a window to draw to you now had a window, a renderer attached to it and a render texture attached to that. You had to fiddle with display modes when loading PNGs to get their transparency to work and in general it felt a bit clunky and low level.

Modularity is a big thing with SDL and functionality is split between sub-libraries, for example SDL can't load a PNG you need SDL_image for that.
This creates small but annoying problems like the documentation becoming fragmented. The SDL wiki only deals with the actual SDL library and SDL_image, SDL_mixer, SDL_net and SDL_ttf all have their own documentation that is often not as good and it's difficult to find example code for some of them. Their maintained status can also seem in doubt, if you look at SDL projects the last modified date for SDL_mixer is 2018 ( 2 years as of now ) and SDL_net is 2016. At least it doesn't feel like they get as much attention as the base SDL library. I also remember not liking SDL_mixer though the only specific thing I can think of was that it was missing a way of getting the length of a sound file and you had to calculate it yourself.
Back then emscripten had only ported SDL2 and SDL2_image so you'd have to port the rest yourself it you wanted to compile for WASM. That appears to have been fixed but still, it was missing for years.

Support for drawing shapes is very limited. It only has rectangles, points and lines so for anything more complex you have to make your own implementation. When drawing a trapezoid I had to do a sort of scanline approach. Had it only implemented triangles you could have used those to draw any shape you'd like so why they haven't done that is a mystery to me.

SDL does have the nicest input handling I've seen in any library though. Supports different keyboard layouts not just US, you can easily get the key character, something that couldn't be done in the other two libraries without making your own lookup table.
It's also the fastest toolkit I've used.

The reason I stopped using it however was it's lack of shader support. I had to do palette swapping which for modern graphics you sadly have to use a shader for and there doesn't appear to be any way to do this in SDL2. Or rather you'd have to switch to using OpenGL directly to draw things and then you could use GLSL for shaders. However you can't mix OpenGL and SDL draw functions so you'd have to do all the drawing yourself in OpenGL which defeats the purpose of using SDL to simplify development. It seems this is the same problem you're going to have if you want to do 3D with SDL since it doesn't have any 3D support. You could still use it to open a window, handle input and sound but all drawing would have to be reimplemented in OpenGL.

Getting a GUI kit for SDL also turned out to be a hassle. They were all pretty awful or unmaintained or - usually and - completely undocumented. The one I settled on was called Guichan, a C++ only library which is what I was using at the time. It was severely out of date even back then but it worked well enough.

Qt

After SDL I went looking for more of an all-in-one library since missing functionality was what had bothered me the most when using SDL, especially I wanted something with a GUI toolkit. I was using C++ and so I went with Qt but it turned out to take a bit too much of a kitchen sink approach.

First of all it's a lot slower than any other library I've tried. The game was comfortably getting above 300 frames in SDL but struggled to achieve 80 frames in Qt and would frequently dip below 60. I tried activating hardware acceleration and there was something like five ways of doing this in Qt - this would become a recurring theme - but none of them made the slightest difference to frame rates.

I also seemed to have picked a bad time to start using Qt. They were moving away from being a pure C++ library and towards using something called QML which is their version of javascript. Some functionality was duplicated and some of the C++ stuff was semi-deprecated. You could find forum posts that referenced the C++ documentation and there would be comments like "as you can see this is being deprecated for QML" but then you'd go to the documentation and it would not say anything about being deprecated. Making it seem like they'd had gone back and undeprecated some C++ parts and maybe had second thoughts about going full QML.
In fact the whole project was in limbo. It was owned by Nokia and by this point Nokia was already in dire straits and had been sold to Microsoft or at least Microsoft's Trojan horse had become CEO and the writing was on the wall.

The project had previously undergone several revisions and this made it difficult when searching for solutions to problems you ran into. It was hard to tell if what someone was talking about was applicable to the current Qt version or if it even worked any more or if it needed the new QML stuff.

I kind of liked Qt despite it's warts. It was very comprehensive and the C++ parts were nice but I never did liked QML which seemed to be the future and besides it was way too slow.

SFML

I ditched Qt but stuck with C++ so SFML is then the obvious choice if you're going FOSS.
SFML is heavily invested in C++ and OOP and even though I don't like either of those it never really became a problem because the library is so well laid out.
The only time I felt they took the OOPishness too far was with the shapes drawing. Normally if you want to draw a rectangle there's a function in the library called DrawRectangle() that takes some position and size as it's parameters and simply draws a rectangle to the screen but in SFML you first have to create a Rectangle object with the desired parameters and then call it's Draw() method. This quickly becomes annoying when you have to draw an arbitrary amount of shapes each frame. Say you have to draw a 200 polygons, well you'd first have to construct 200 polygon objects and when you already have your own data structures this is completely pointless.

SFML doesn't have a GUI toolkit but there is one called TGUI which pretty close to being an official one and it was alright, feature complete and fairly simple to use.

Over all if you're using sepples it's a great choice for a library. It's a bit slower than SDL but not by much and equivalent to Raylib.

Raylib

After going back to C I tried Raylib which I've stuck with since. It very beginner friendly and streamlined, no sharp edges here like in SDL. Everything is built right in and the documentation is great with small examples for all the functions.
There's even an official immediate mode GUI in the form of rayGui. You're not going to create an Office suite with it but for smaller things like menus it's the best way of doing a GUI I've tried so far. All the other GUIs had some complex method of handling events like button presses; Qt had signals/slots and both TGUI and Guichan did something similar but with rayGui you just have one line of code with the button and the function that should active when it's clicked. Less flexible perhaps but for me it works just as well but with less code and being easier to read. Even for some slightly larger projects I've come to prefer it.
It's a bit slower than SDL but I'll gladly trade those few frames for the ease of use.