SDL is designed to act as a basic means of accessing a wide variety of different low-level subsystems of a computer in a cross-platform (i.e. operating system independent) manner.

Its graphics are limited (in SDL1 and SDL2 at least) because it provides only that basic substrate for building on top of and not (in itself) advanced rendering such as OpenGL or DirectX or Vulkan (etc).

However, it is designed so that any of those more advanced rendering systems (OpenGL, DirectX, Vulkan, etc) can be connected to it and rendered within its window.

Very soon though, SDL3 (the successor to SDL2) will be released and it in contrast will provide some built-in cross platform abstractions over the various rendering systems.

Prior to the upcoming SDL3 though, many people would use a rendering middleware library such as BGFX to reduce the amount of hand-made rendering code they have to build on top of SDL1 or SDL2.

However, that is generally only relevant to games that need/want 3D rendering or GPU effects such as shaders.

SDL's built-in graphics are designed to be independent of GPUs, such that it can work even without one. It provides a few functions for enabling using GPU-based graphics though, which people then hook into to customize their engine as they please.

SFML does have more graphics support than SDL2, but SDL3 will likely have more than SFML once released.

SDL is also the most widely used low-level cross-platform multimedia abstraction library, so much so that Steam (Valve) have been rumored to sometimes just drop in a new SDL.dll file into broken SDL-based games installs for inactive devs to see if that'll fix the game and sometimes it does.

Many proprietary game engines are actually built on top of SDL. The one I worked with when I was a AAA game developer did, for example, as I could tell by the presence of its distinguishing DLL files in the test output of the proprietary engine's build process.

Most importantly though, what you are comfortable working with is indeed the most important thing, because getting anything done is better than nothing.

The easiest full-fledged engine choices for newbies are probably (loosely from easiest to hardest of the most popular options, according to my subjective estimate):

(1) Unity, (2) Godot, (3) Defold, and (4) Unreal Engine

Likewise, for "code-only" libraries and/or frameworks (similarly ordered):

(1) Love2D, (2) Raylib, (3) XNA/FNA/Monogame, (4) Solar2D, (5) SFML, and (6) SDL

However, there's good reasons why SDL is so dominant for building custom proprietary game engines. Even Love2D itself is actually built on top of SDL under the hood. SDL is famous for being reliable and broadly supported and is the oldest of these libraries probably if I recall correctly.

Each of the above has a myriad of subtle pros and cons and consequences and none are better or worse than others without knowing the context and exactly what the project will end up being.

To a first approximation: Engines are codebases connected to full GUI-based editors and are what most corporate and indie game developers use to create most kinds of games. Libraries and frameworks on the other hand give you much tighter control of the structure of your code and substantially reduce the extent to which you have to "force your brain to fit someone else's brain" compared to engines, but the cost of that is a much larger proportion of work has to be done manually by you. Full engines often have literally millions of lines of code in them.

You can't go wrong picking any of them, unless your choice is incompatible with a very specific goal of your project. What's most important is to pick one and stay commited to it (I say this as a hypocrite though, lol... historically I've switched far too often).

Try them out and then simply trust your instinct about which one feels the most right to you.

It is very likely you will have a natural preference after trying to get a basic text project (with some things moving around or whatever) set up in each one.

Just listen to what your heart says, after giving a few of them a whirl.

Anyway though, I hope that helps and that it was not too overwhelming and/or verbose.

Game development can be confusing for those who are new to it though, since there is so much terminology leading in so many directions, so I wanted to clarify it.

--------