Support us on Patreon
PayPalLooks 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.
Some you may have missed, popular articles from the last month:
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.
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.
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.
12 Likes, Who?
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
Last edited by Shmerl on 12 November 2021 at 8:37 pm UTC
2 Likes, Who?
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.
3 Likes, Who?
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.
11 Likes, Who?
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)
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)
3 Likes, Who?
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.
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.
2 Likes, Who?
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
4 Likes, Who?
"This sounds like a really great project, and hopefully one game developers will appreciate."
one or some?
one developers?
one or some?
one developers?
0 Likes
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.
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.
3 Likes, Who?
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.
0 Likes
"This sounds like a really great project, and hopefully one game developers will appreciate."There's an implicit that.
one or some?
one developers?
"...hopefully one (that) game developers will appreciate."
4 Likes, Who?
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
0 Likes
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.
1 Likes, Who?
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.
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.
0 Likes
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.
0 Likes
"This sounds like a really great project, and hopefully one game developers will appreciate."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"
one or some?
one developers?
1 Likes, Who?
"This sounds like a really great project, and hopefully one game developers will appreciate."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"
one or some?
one developers?
dammit, it would be so much easier to figure out if it was in my native lang...
3 Likes, Who?
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.
2 Likes, Who?
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
1 Likes, Who?
See more from me