SDL2 is pretty nice because it provides enough functionality to do pretty much anything you will need, it gives you a lot of control over what you're doing and it's very stable. The problem is that its C syntax doesn't exactly encourage you to write clean and modern C++ code, which means you may have to abstract and make more wrappers, and it also probably has less high-level functionality than some other libs. I did try SFML once earlier and it seemed good for the most part, but because it had some small bugs that I didn't like, I decided to go with SDL2 instead. But they may have fixed those bugs by now, so it could be worth trying.

I have learned SDL2 a bit, but again I can't move further than a basic window with some sprites, that I loaded

A video game is basically an interactive movie. You display graphic images at some rate (like 50fps) to the computer screen. Each image is a bit different (ie taken 1/50th of a second later), and you get the illusion of movement, just like a regulat movie.

If you don't deal with user input (or the user doesn't provide input), you are just simulating, the world that you display continues running at wall-clock speed (assuming you don't have a 'pause' button), and you keep displaying images.

The user input means that whatever the user controls changes direction, color, start or stop firing bullets, make a jump, etc etc. Basically, you register what the current activity is of the user character (just like everything else that exists in the world), and the world will display the new behavior as it runs through time, displaying new images at 50 fps.

"make a game" in the technical sense is thus make a program that creates these images at the required rate, and sends them to the video. Usually, you need to keep track of all data (like position and speed of everything) in you world in order to do that.

How to understand somebody's code?

That's an art too, and it's different from programming.

Reading everything starting at line 1 of the first file, and ending at the last line of the last file doesn't work, it is too much information.

Instead, you look for specific parts only. For example, you want to fix a bug in Money payments.

Focus on that. You search for functions that deal with payment. Their name normally contains something that relates to what they do. You can perform a text search on "payment" or "pay" or "paymoney" or "debt" or "credit" (be a little creative in how people may name what you're looking for!). All these terms may give you a lines in files for a closer look. Alternatively, if it's player payments, find the type that represents money amounts, or the name of the variable that holds player money, or the function that handles money updates of player money. All those things have names that you can search for across all files. Read the lines and functions in that neighbour hood, and slowly you get a picture of how money gets dealt with.

Another way in are the files themselves. Check them. Can you see patterns in the filenames? eg tile_funcs.c may contain functions. "tile" may point to something that exists in the game. Read each filename and consider what it may contain. Open the file, and read the function names. Don't worry if it doesn't hit home immediately, you're exploring foreign code, these things take time.

If you get closer to what you want to know about, you have to really understand the code. My standard trick is to start adding Doxygen documentation to the functions and data that you think you understand. You don't get everything, but some stuff is understandable, so document it. Writing that text makes you quite aware of its function, and even better, you can now read your text instead of deducing functionality from the code, which is a lot faster.

If you do this for a longer period of time, the system that is used in the code will become clear. You start to understand the code, see how it works.

All this goes a lot faster if you have people that know the code nearby. Check if the project has a mailing list or a forum or an IRC channel, and read what they discuss. Ask questions where to find things, etc.