Linux game programming with SDL2

[eichenhain]

Hi guys,

over the next few weeks I want to look into SDL2 with C++ on Linux. So far I found Lazy Foo's tutorial[lazyfoo.net] and a video series along the same lines from Coding Made Easy on youtube.

• Do you have any suggestions on what other resources to use?
  
• If you are a SDL expert, may I occasionally ask you a questions?
  
• Does learning SDL2 sound intriguing and you want a study buddy? Add me on Steam.

Thanks!
eichenhain

[Aoi Blue]

There are quite a few Open Source game engines that utilize SDL2 as an underlayer, but have far more done for you already.

I highly recommend looking into those, because SDL2 was really designed as a multimedia library, not a game library.

[Cheeseness]

Originally posted by ruediix:

I highly recommend looking into those, because SDL2 was really designed as a multimedia library, not a game library.

This is untrue[en.wikipedia.org]. SDL was written by one of the Loki porters to help ease the porting process.

eichenhain, Lazy Foo's tutorials aren't a bad place to start now that they've been updated for SDL2. I've been working on an SDL2/OpenGL engine for one of the games I'm working on and put together a little example game here[github.com] (it's got a couple of lighting bugs, but at least gives an idea of how to set up an OpenGL context and draw some stuff, as well as how to handle input. It's heavily commented to hopefully make things make sense to newcomers.

I'm more than happy to chat about stuff if you need :)

[Aoi Blue]

Originally posted by Cheeseness:

Originally posted by ruediix:

I highly recommend looking into those, because SDL2 was really designed as a multimedia library, not a game library.

This is untrue[en.wikipedia.org]. SDL was written by one of the Loki porters to help ease the porting process.

Well yes, I should be more clear. Games were one of the largest target programming types for SDL, which was made to fill the gap of a missing unified library base to handle all the functions used in multimedia and games at the time.

However, it was specificailly designed as a layer to sit between the multimedia hardware and the game engine, to make porting game engines (such as the Doom and Quake engines) easier. It was not designed with running games directly in mind.

To call SDL a game engine would be like calling DirectX a game engine. Frankly, it's built to enable gaming, and other multimedia, but it's far from a complete game engine.

That was my point. SDL was built to handle the multimedia layer of games. (Vector graphics, raster graphics, audio, etc.) It was not built to handle the game engine functions (Physics, object instancing, material handling, AI, etc.)

If you want to build your own game engine, or port an existing one to a new platform, SDL is a great choice. However, if you want to make a game, it will likely be better to save yourself trouble and use an engine that has much of the work done for you, not just the bare essentials.

[Cheeseness]

Originally posted by ruediix:

To call SDL a game engine would be like calling DirectX a game engine. Frankly, it's built to enable gaming, and other multimedia, but it's far from a complete game engine.

Nobody was calling SDL a game engine.

Originally posted by ruediix:

That was my point. SDL was built to handle the multimedia layer of games. (Vector graphics, raster graphics, audio, etc.) It was not built to handle the game engine functions (Physics, object instancing, material handling, AI, etc.)

Your point is at least partially incorrect and mostly misleading though. SDL was first and foremost written to support the porting of games, so you are incorrect when you say that it was not designed with running games in mind.

SDL has no support for vector graphics, and only rudimentary support for rendering sprites or rendering audio. More advanced functionality is exposed by separate projects that extend SDL's functionality like SDL_image or SDL_audio (no SDL related project provides vector rendering functionality, so you might be confused about that).

For me, SDL's key benefits are in providing cross platform convenience methods for windowing (not multimedia), input (not multimedia), thread management (not multimedia) and timer support (not multimedia). These are all significant and valuable.

Originally posted by ruediix:

If you want to build your own game engine, or port an existing one to a new platform, SDL is a great choice. However, if you want to make a game, it will likely be better to save yourself trouble and use an engine that has much of the work done for you, not just the bare essentials.

A lot of this depends on what it is you're making. Game development (like most types of development/engineering projects) benefits from picking the right tool to match the task at hand and the resources available. Generalisations about avoiding trouble aren't very helpful here, I don't think, especially when eichenhain's post is explicitly framed around a desire to learn SDL.

I used to feel that writing games from this level was more time costly than it actually is. Having done it twice now, I feel like I have a better perspective and was wrong in assuming that the time cost of not using pre-existing engines was prohibitive.

Have you made anything "from scratch" with SDL? Have you made anything using a pre-existing engine? If the answer to either of these is no, then you can't really make the comparison, can you?

[Aoi Blue]

A lot of this depends on what it is you're making. Game development (like most types of development/engineering projects) benefits from picking the right tool to match the task at hand and the resources available. Generalisations about avoiding trouble aren't very helpful here, I don't think, especially when eichenhain's post is explicitly framed around a desire to learn SDL.

I used to feel that writing games from this level was more time costly than it actually is. Having done it twice now, I feel like I have a better perspective and was wrong in assuming that the time cost of not using pre-existing engines was prohibitive.

Have you made anything "from scratch" with SDL? Have you made anything using a pre-existing engine? If the answer to either of these is no, then you can't really make the comparison, can you?

I haven't.

Your point is also valid.

I've read plenty of case studies of other people's experiences, and if there is no premade engine that can fit your needs, you will spend more time adapting one to do so than writing one from scratch.

It often seems logical to chose a complete game engine, but if your game doesn't meet it's needs then it is useless, thus it is very important to learn to write a game engine from scratch.

As a note, I am now agreeing with you.

[Cheeseness]

It's all good. Sorry if I came across as dismissive.

[Aoi Blue]

Cool Sorry if I came across as argumentitive, instead of helpfull.

[eichenhain]

Thank you for both of your insights, ruediix and Cheeseness. I do not wish to study SDL as a convenient means to create a game. I'm aware of the myriad of game engines like cocos2d-x or SLUDGE. It's more my desire to understand certain key concepts before perhaps toying around with an engine building on SDL2 later on.

For those playing along at home, I found a competent book that covers topics a bit more in-depth than Lazy Foo does: Shaun Mitchell: SDL Game Development (Packt Publishing 2013).

For a general overview on how a SDL2 game is made up, Cheeseness' hover-drive example game[github.com] mentioned above proved very useful. Playing around and watching the changes gave me more insight than the piecemeal tutorials I work on.

So far my own attempts do not go beyond simple animations, some font rendering and basic user input. But it's fun and every little success feels good!

[Cheeseness]

Originally posted by eichenhain:

But it's fun and every little success feels good!

This is what I found when I started doing this stuff. It was hugely empowering to discover that all this stuff was doable and less complex than I'd imagined.

How are you handling animation? That's something I haven't tackled yet.