3 ms·

I used to lurk in #SDL and help beginners, the common misconception is that SDL encompasses a much larger scope of game engines than just providing an abstracti

I used to lurk in #SDL and help beginners, the common misconception is that SDL encompasses a much larger scope of game engines than just providing an abstraction of platform-specific details. It's not SDL's fault beginners have poorly defined/uninformed expectations. But you're right about the documentation being kind of a mess. The SDL1.2 vs SDL2 differences can be annoying and for a beginner just figuring out what version the example/tutorial code they're looking at relates to can be challenging.

TotempaaltJ 5y ago
> It's not SDL's fault beginners have poorly defined/uninformed expectations. It might not be their fault but I'd still say they're probably in the best position to correct it.
- pengaru 5y ago
  I'm not sure what SDL can do to prevent this. From what I saw the primary cause was beginner game programming tutorials on the web, outside the SDL project, created by volunteers, judging by the code quality, often beginners themselves. The lazyfoo ones were especially popular back when I was involved. These tutorials would go immediately to creating a main.c with an SDL dependency, before even discussing game engine architecture or frankly anything at all. So you have a total noob who likely doesn't know anything about C let alone game development, being faced with their first C listing and it's immediately mentioning SDL junk for creating a window and this stuff called an event loop. Of course the newbie is lost, most the time they can't even get it to compile. The tutorial is some random abandoned long-forgotten thing on the web, with zero support available. So where do they go? SDL of course! It's the only thing on their radar at this point, and while barely on life support, there's still something resembling a community in #SDL, more recently I think they shifted to slack or something so maybe it's improving. SDL isn't in the business of teaching to build game engines. Just because awful game programming tutorials on the web tend to start with SDL because it's the platform abstraction so you initialize it first, doesn't mean SDL should take on that role, which seems to be what you're implying they're best positioned to do. There's already insufficient resources to maintain the API docs and fix bugs as-is. If you're interested in volunteering for the job, Ryan Gordon is the man to reach out to.
- krapp 5y ago
  There really isn't much to learn aside from the API. SDL isn't a game engine, or even close to one. Once you know how to open a window, poll for events (maybe even create custom events and use the event system for messaging or signals), load a texture from a file and make sprites, and maybe basic AABB collision detection with rects, you know most of what SDL is useful for. Everything else is "code the rest of the f'ing owl" territory, which is outside SDL's purview.

TotempaaltJ 5y ago

> It's not SDL's fault beginners have poorly defined/uninformed expectations. It might not be their fault but I'd still say they're probably in the best position to correct it.

pengaru 5y ago
I'm not sure what SDL can do to prevent this. From what I saw the primary cause was beginner game programming tutorials on the web, outside the SDL project, created by volunteers, judging by the code quality, often beginners themselves. The lazyfoo ones were especially popular back when I was involved. These tutorials would go immediately to creating a main.c with an SDL dependency, before even discussing game engine architecture or frankly anything at all. So you have a total noob who likely doesn't know anything about C let alone game development, being faced with their first C listing and it's immediately mentioning SDL junk for creating a window and this stuff called an event loop. Of course the newbie is lost, most the time they can't even get it to compile. The tutorial is some random abandoned long-forgotten thing on the web, with zero support available. So where do they go? SDL of course! It's the only thing on their radar at this point, and while barely on life support, there's still something resembling a community in #SDL, more recently I think they shifted to slack or something so maybe it's improving. SDL isn't in the business of teaching to build game engines. Just because awful game programming tutorials on the web tend to start with SDL because it's the platform abstraction so you initialize it first, doesn't mean SDL should take on that role, which seems to be what you're implying they're best positioned to do. There's already insufficient resources to maintain the API docs and fix bugs as-is. If you're interested in volunteering for the job, Ryan Gordon is the man to reach out to.
krapp 5y ago
There really isn't much to learn aside from the API. SDL isn't a game engine, or even close to one. Once you know how to open a window, poll for events (maybe even create custom events and use the event system for messaging or signals), load a texture from a file and make sprites, and maybe basic AABB collision detection with rects, you know most of what SDL is useful for. Everything else is "code the rest of the f'ing owl" territory, which is outside SDL's purview.