3 ms·

> 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 positi

> 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.

> 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.