Every article tag can be clicked to get a list of all articles in that category. Every article tag also has an RSS feed! You can customize an RSS feed too!
We do often include affiliate links to earn us some pennies. See more here.

Looks like cross-platform game development with SDL is going to get easier, as Ryan Gordon (also known as Icculus) has confirmed an Epic MegaGrant and details what it will be used for.

What is SDL? Simple DirectMedia Layer (SDL) is a cross-platform development library designed to provide low level access to audio, keyboard, mouse, joystick, and graphics hardware. It is used by video playback software, emulators, popular games and some game engines.

Ryan Gordon is one of the people responsible for its development, and Gordon has also ported plenty of games to Linux, macOS and other platforms over many years. In a new post on Patreon, a fun announcement was detailed about an approved Epic MegaGrant and how it's going to be used to improve SDL.

Previously if people wanted more than what SDL could do on a graphics level, they would be told something like "use OpenGL directly". Not great advice now, with Vulkan being pushed forwards and Vulkan is a much more modern and performant API to use for games. The problem is, Vulkan is also quite complicated. As the post mentions:

"It seems bonkers to tell people 'write these three lines of code to make a window, and then 2000 more to clear it,' but that's the migration funnel--and meat grinder--that SDL users are eventually going to get shoved into, and that's unacceptable to me." - Ryan Gordon.

What to do it about it then? Make working with Vulkan easier, by upgrading SDL to have a "simple, cross-platform, hopefully pleasant-to-use interface that Just Works and finds the best way to get things done with what it finds on the end-user's system" - Ryan Gordon.

Speaking to me on Twitter to spell it out even clearer, Gordon said:

"It’s going to be new SDL APIs that expose the functionality of Vulkan but do it with whatever API behind the scenes (Vulkan, Metal, Direct3D etc). There will be some limitations, but I think it will make the next-gen APIs way more accessible to people that aren’t AAA engine devs."

"In the same way that SDL currently provides functions to say 'get this window on the screen and this sound to the audio device and I don’t care how you _actually_ do it.'"

This sounds like a really great project, and hopefully something game developers will appreciate.

Article taken from GamingOnLinux.com.
45 Likes
About the author -
author picture
I am the owner of GamingOnLinux. After discovering Linux back in the days of Mandrake in 2003, I constantly checked on the progress of Linux until Ubuntu appeared on the scene and it helped me to really love it. You can reach me easily by emailing GamingOnLinux directly. You can also follow my personal adventures on Bluesky.
See more from me
The comments on this article are closed.
All posts need to follow our rules. For users logged in: please hit the Report Flag icon on any post that breaks the rules or contains illegal / harmful content. Guest readers can email us for any issues.
21 comments
Page: 1/2»
  Go to:

jordicoma Nov 12, 2021
Icculus it's god. When we didn't have steam, he brings us many ports we own him a lot.
Hope this update goes well. And I understand that if anyone wants to use opengl/vulkan in raw, they will be able to use it, like the other parts of sdl.
Shmerl Nov 12, 2021
Isn't there gfx-rs for that? It provides a simpler API than raw Vulkan but it's built on top of Vulkan. I hope SDL won't start making a new one with the same idea.


Last edited by Shmerl on 12 November 2021 at 8:37 pm UTC
Samsai Nov 12, 2021
Isn't there gfx-rs for that? It provides a simpler API than raw Vulkan but it's built on top of Vulkan. I hope SDL won't start making a new one with the same idea.
gfx-rs went into maintenance mode and the Rust ecosystem seems to be moving towards wgpu. Either way, it's not very helpful for people that insist on writing in C or C++, and I guess for that purpose an SDL wrapper would be useful.
WorMzy Nov 12, 2021
Happy to see more of Epic's ill-gotten gains going to a worthy cause. Not interested in giving them any of my money until they properly commit to supporting Linux though.
Grogan Nov 13, 2021
There's a name I haven't heard in a long time, I'm glad he's still working on Linux gaming. Back in the good old days, he was the guy for porting Linux games. I played a lot of them.

Some of his work still runs perfectly to this day, even if the Loki installers don't. For example, Unreal Tournament 2004... in one of his patches he included a 64 bit build. I still run that SAME game (with the directory copied to new computers over the years) on a pure 64 bit system simply by dropping some older 64 bit libraries in the program directory. (e.g. libstdc++.so.5)
gbudny Nov 13, 2021
Great!

I still have some digital and boxed versions of games like Postal 2 (LGP), Eric's Ultimate Solitaire, Heavy Metal: FAKK 2, Candy Cruncher, and so on. I don't even count how many times I played Postal 2 and Lugaru on Linux.

It's such a shame that he probably didn't get paid to finish the Linux version of Medal of Honor. It's an excellent game, and I know the Linux version is buggy. However, I don't regret that I spend about 17$ to buy an old computer to run Medal of Honor for Linux without any crashes. It was a great game when kernel 2.4 was popular on PCs, and I highly recommend it.
slembcke Nov 13, 2021
View PC info
  • Supporter Plus
write these three lines of code to make a window, and then 2000 more to clear it

Hrm, I'm kind of annoyed with the persistence of this mindset. My entire Vk renderer is ~1200 sloc compared to my GL3 renderer at ~900 sloc. Yes, it's more complicated, and I would have been pretty lost if it was my first rodeo. It doesn't take thousands of lines of code to draw a triangle with Vulkan though, and I'm kind of annoyed that people keep saying so and discouraging others to even try it. :(

That said, there's a good 200-300 sloc of any Vk renderer that's just sort of "free" with GL. You don't have to carefully initialize a device to get sane defaults, and you need very little effort to get a framebuffer + sync. Khronos could make a reasonable library to simplify those parts of the API for 99% of the use cases I feel.


Last edited by slembcke on 13 November 2021 at 2:45 am UTC
elmapul Nov 13, 2021
"This sounds like a really great project, and hopefully one game developers will appreciate."
one or some?
one developers?
elmapul Nov 13, 2021
write these three lines of code to make a window, and then 2000 more to clear it

Hrm, I'm kind of annoyed with the persistence of this mindset. My entire Vk renderer is ~1200 sloc compared to my GL3 renderer at ~900 sloc. Yes, it's more complicated, and I would have been pretty lost if it was my first rodeo. It doesn't take thousands of lines of code to draw a triangle with Vulkan though, and I'm kind of annoyed that people keep saying so and discouraging others to even try it. :(

That said, there's a good 200-300 sloc of any Vk renderer that's just sort of "free" with GL. You don't have to carefully initialize a device to get sane defaults, and you need very little effort to get a framebuffer + sync. Khronos could make a reasonable library to simplify those parts of the API for 99% of the use cases I feel.

afaik the whole point of vulkan is that openGL was abstracting too much stuff, while on vulkan you have to understand what is happening behind the scenes, because those assumptions that the driver/compiler/library did for you, werent the best options in terms of performance.

if we gonna abstract everything again, we might as well just go back to openGL instead.

the same goes for dx12 against 11 and the previous ones.
elmapul Nov 13, 2021
so epic donate to SDL or to ryan specifically?
GustyGhost Nov 13, 2021
I've always found SDL programs to just work without fuss or any tinkering. If this can entice more projects to use it then great.
CatKiller Nov 13, 2021
View PC info
  • Supporter Plus
"This sounds like a really great project, and hopefully one game developers will appreciate."
one or some?
one developers?
There's an implicit that.
"...hopefully one (that) game developers will appreciate."
Whitewolfe80 Nov 13, 2021
There's a name I haven't heard in a long time, I'm glad he's still working on Linux gaming. Back in the good old days, he was the guy for porting Linux games. I played a lot of them.

Some of his work still runs perfectly to this day, even if the Loki installers don't. For example, Unreal Tournament 2004... in one of his patches he included a 64 bit build. I still run that SAME game (with the directory copied to new computers over the years) on a pure 64 bit system simply by dropping some older 64 bit libraries in the program directory. (e.g. libstdc++.so.5)

He still does porting work he did the turok ports to linux for nightdrive
DrMcCoy Nov 13, 2021
It doesn't take thousands of lines of code to draw a triangle with Vulkan though, and I'm kind of annoyed that people keep saying so and discouraging others to even try it. :(

A few years ago, I did write a simple Vulkan renderer just to get a hang of Vulkan, starting with getting a triangle to work. I loosely followed https://vulkan-tutorial.com/Introduction , IIRC.

And yes, it was nearly exactly 1000 lines to get a triangle to show up. Granted, extending it to do more didn't add thousands more, but it is definitely more verbose than OpenGL.
ShabbyX Nov 13, 2021
Ugh, we don't need yet another graphics API. OpenGL is not going anywhere given the available layers (like ANGLE that does the same thing, translating to Vulkan, d3d, metal etc), what's the point of another OpenGL clone?

Also, ok you need 1000 lines to get a triangle to the screen, but then 1005 lines to write your whole graphics engine. No one writes a program to render just one triangle, and the cost of the boilerplate is amortized by the amount of work the game needs anyway.
Shmerl Nov 13, 2021
gfx-rs went into maintenance mode and the Rust ecosystem seems to be moving towards wgpu. Either way, it's not very
helpful for people that insist on writing in C or C++, and I guess for that purpose an SDL wrapper would be useful.

Oh, too bad. I think gfs-rs was promising.
Purple Library Guy Nov 14, 2021
"This sounds like a really great project, and hopefully one game developers will appreciate."
one or some?
one developers?
No, the grammar's OK. "One" here refers back to the most recent noun, "project", so the meaning is "and hopefully (a project) game developers will appreciate"
elmapul Nov 14, 2021
"This sounds like a really great project, and hopefully one game developers will appreciate."
one or some?
one developers?
No, the grammar's OK. "One" here refers back to the most recent noun, "project", so the meaning is "and hopefully (a project) game developers will appreciate"

dammit, it would be so much easier to figure out if it was in my native lang...
slembcke Nov 14, 2021
View PC info
  • Supporter Plus
if we gonna abstract everything again, we might as well just go back to openGL instead.

the same goes for dx12 against 11 and the previous ones.

Yeah, I kinda agree. It's not like the old APIs are going away any time soon. They are still good for learning concepts, and being able to tackle them one at a time.

A few years ago, I did write a simple Vulkan renderer just to get a hang of Vulkan, starting with getting a triangle to work. I loosely followed https://vulkan-tutorial.com/Introduction , IIRC.

And yes, it was nearly exactly 1000 lines to get a triangle to show up. Granted, extending it to do more didn't add thousands more, but it is definitely more verbose than OpenGL.

Well, to expand on some of my thoughts. I do think Vulkan probably will make for a terrible first introduction to graphics APIs. The joke that it takes 1000 lines of code to draw a triangle in Vulkan and 1001 for a whole engine is not far off. Joking aside, I think it was about 500 until I could clear the screen, 800 to draw a triangle, and 1200 for my whole renderer. So it's definitely front loaded with the complexity, and that's kinda what I mean that It's frustrating that Khronos doesn't just make a swapchain + init library. 99% of GL programs shared the same "default" init and nobody really complained about that. There was always EGL if you needed something more complicated, and Vulkan is even worse than that. :p

Also, I think Vulkan-tutorial had it's place and served it well, but I do find it sort of frustrating that it's still around, basically unmodified many years later. I also started with that when learning Vk, and it pretty quickly became obvious that it was teaching you to implement a tutorial in the "hello world" sense. It made you structure your renderer in an extremely rigid and awkward way that was basically unusable for a real project. I gave up about 1/3 of the way through, restructured what I already had and filled in the rest from other docs/sources. Bah! Unfortunately I'm not sure I have anything truly constructive to say here. It's not as though I'm spending my time writing a better tutorial, and don't want to spend too much effort tearing down someone who did. I do think it needs some updates though.
elmapul Nov 14, 2021
It's frustrating that Khronos doesn't just make a swapchain + init library.

but i think there is a boilerplate code for it =p
not made by khrnos, i think it was lunarG or something like that.

Bah! Unfortunately I'm not sure I have anything truly constructive to say here.

lol, amusing, i know that feel, when i'm trying to write my stories.


Last edited by elmapul on 14 November 2021 at 7:05 am UTC
While you're here, please consider supporting GamingOnLinux on:

Reward Tiers: Patreon. Plain Donations: PayPal.

This ensures all of our main content remains totally free for everyone! Patreon supporters can also remove all adverts and sponsors! Supporting us helps bring good, fresh content. Without your continued support, we simply could not continue!

You can find even more ways to support us on this dedicated page any time. If you already are, thank you!
The comments on this article are closed.