@@MattieBW That's great. Download livesplit, make splits like "Game is bootable", start the timer and go. Keep the timer between sessions I gotta do that when programming stuff too lol
very pleasant and informative video! Thank you very much for making these! The great thing about videos is that you see someone else's workflow :) I love the old school editor and font, it feels very cosy.
I'm mostly a golang hacker these days, but I kind of enjoyed watching this. Thanks for all the Free Software work that you do! Gaming on Linux is important =D
Thanks a lot for this kind of video, very instructive! And you explaining why certain things were done that way in SDL2 brings so much light on so many questions haha. Thanks a lot. Welcome to Quake 3 Arena !
00:00:00 "SDL3 (starting with v3.1.3) is now officially at ABI lock." 00:00:40 Quake 3 Arena & ioquake3. 00:01:31 Fork ioq3 & switch to new branch. 00:01:40 SDL3 Migration Guide Wiki. 00:02:50 Semantic Patching via Coccinelle code matching & transformation tool. 00:07:00 Begin Porting 01:26:49 Build success, verify build only uses libc+libm+SDL3 shared libraries, run Quake 3, and create patch. 01:32:35 Conclusion. 01:32:59 "... Steam and Steam Link, all of Valve's stuff, Dota 2, CS2 ... have been using (SDL3) for a while ... so it's battle-tested and hardened and ready to go."
oh hey, didn't know you had a UA-cam channel! I've used PhysicsFS a lot and it's been very helpful. I really appreciate that it's easy to modify, I was able to add hash buckets to the search path conflict check in around an hour (had to mount ~15k files). Didn't even realize you were involved in game ports & SDL until I was reading about Quake derivatives on Wikipedia.
Stumbled across this in my recommended and as i'm watching, i remembered that i still have the 4 classic quake games installed from when i had PC Game Pass. Apparently Microsoft does exactly nothing to restrict those files in case your Game Pass sub ends and you're free to copy all the necessary files to use a source port like ioquake3 or whatever is applicable for the game in question to play it without Game Pass.
Obviously way beyond the scope of this video, but would be cool to see a port to the new SDL3 GPU api instead of opengl, great work as usual ryan!
2 місяці тому
Ooh! Ty for this, I just found my next project (porting my "just for fun" game engine from 2 to 3)! I haven't visited c++ for a while, would be a good time to refresh my skills
Nice work on the porting, thanks for this very interesting video! I think you made one small mistake: At 1:00:10 you specify sdlCaptureDevice, but shouldn't it be sdlPlaybackDevice? In the end, you would want to reduce the gain on the output, not the input, right? Are there plans to mainline this port to ioq3? Also, overall, does SDL3 come with performance improvements over SDL2 or is ist just more about better consistency in terms of API and possible race conditions?
You're totally right, that should be sdlPlaybackDevice. Good catch! SDL3 has a bunch of good stuff over SDL2--including better consistency, more performance, and less race conditions--and you can get a quick overview of Cool New Stuff at wiki.libsdl.org/SDL3/NewFeatures !
I hope that Spearmint will also be ported to SDL3. Spearmint is a modified version of the Quake 3 Engine with some improvements (like bullet marks on moving platforms).
interesting video! i wonder if the migration patch script could also replace those integer != 0 checks with the correct boolean ones, but maybe that would be too slow/complicated if it has to check every SDL function name which work that way
That's not a bad idea, but I do suspect it _would_ make spatch even more brutally slow. The compiler catches most of these, since most things either compare `< 0` or `== -1` ... but the comparison against zero will definitely need to be cleaned out.
That's where everyone starts, but we all learn a little more every day. You will, too. The nice thing about C is that there isn't much to the language itself--it's all in what functions you call in other libraries, for the most part--so you've already got a lot of it down. :)
53:10 "capture" is actually better, because "recording" means the data is being saved somewhere. But capture - is just capturing a stream of data, without necessarily saving it.
@@AlistairLynn silence for U16 audio is 0x8000. You can use memset with 0x80, which sets each sample to 0x8080, which is _almost_ silent, and indeed what we did in SDL2 for lack of a better option. DC offset aside, it adds imperfection in an audio format that was largely unused anyhow, so we dropped U16 for SDL3.
@ zero for U16 is 0x8000 but my point is that any value which is the same for every sample is also silence, including full negative saturation at 0x0000, because that’s pure DC
Congrats. I've used SDL2 in hobby projects for years but will think about 3 soon. Is it usable today by people on 5 y/o Debian computers? I'm on Windows but try to be considerate of people who don't have the latest libraries
It is! It has support for newer things (like PipeWire, Wayland, etc), but it looks for those things at runtime and chooses what to use based on what's available on the system (if not PipeWire, maybe PulseAudio, if not PulseAudio, maybe ALSA, etc). The only thing SDL3 links directly against is the C runtime (and even that is optional on some platforms!). This is true on all platforms. On Windows, we support back to Windows XP, and someone is maintaining some small patches outside of our repo to get Windows 95 up and running.
So we've built something called sdl12-compat ( github.com/libsdl-org/sdl12-compat ) which makes SDL-1.2-based games work with SDL2, and this contains support for the idTech4 functions that were added to their fork of SDL 1.2. We've _also_ built sdl2-compat to make SDL2 games work with SDL3, and it explicitly works to chain all this together...so you drop a few new libraries into your idTech4 game folder and they're running on SDL3 without even recompiling the games. For games that aren't getting updates, this is the right thing to do. I chose quake3 for this video because ioquake3 is still actively maintained, so it makes sense to modernize its source code to use SDL3.
I really can't recommend something specific, since these things are such personal choices (and as FTE demonstrates, it's 100% okay to find something imperfect you love and use it for 30+ years). I'd tell you to try lots of things--vscode, Qt Creator, Lite XL, heck, maybe even Emacs, I don't know--each for a little while, and then decide what you like best. And once you make a choice, commit to it for a little while unconditionally, and the small things you don't like will probably be papered over by muscle memory quickly and the big things you like will dominate. But for me, what I like about FTE is that it does one thing well and doesn't try to manage my whole life...it's a text editor, not an IDE...and while that is a minor inconvenience from time to time, it's nice to jump to other useful tools for specific tasks instead of trying to figure out how to coerce my One And Only Tool to work for me. I have no idea if any of this helps, but that's my advice.
I may, but the patch in the video needs more work before it would be PR-ready (for example, I skipped all the non-Linux pieces of the Makefile). They also have to decide if they're willing to drop PowerPC Mac support (as they seem to have SDL2 headers specifically for that), and maybe other ancient platforms, or keep a _lot_ of ifdefs to continue to support SDL2 in parallel.
I did some SDL2 in 2018-2019. I found the interfaces quiet nasty. Been waiting for this. Now I got a MSC in computer science and math, and 3 more years in the industry as a programmer/data scientist. Lets make some games!
Quake 3 is a fixed-function pipeline game*, so it would be non-trivial to move it to the GPU API...more than I could do in a reasonable UA-cam video. * technically, q3a offered the world a first look at the concept of vertex shaders...done in software, backed by fixed-function OpenGL. But the point still stands. (Also, there _is_ an OpenGL2 renderer in ioquake3 that uses GLSL, but I have no experience with it and I think even with that infrastructure in place, a GPU port would probably take some hard work. But maybe later!)
@@RyanGordon Mmm I have a project that's basically some old abandonware 32bit dx9 game that is mostly leaked code(they don't care) and some dx9 that I cobbled together. It's really simple, only basic pixel shaders. The rest is just uploading a mesh and DrawIndexedPrimitive. I assume this would also be hard to port to SDL GPU since it's still mostly a state-machine. (I am not a graphics engineer.)
Heya, I've seen your Steamworks presentation, "Game Development with SDL 2.0" it's called, and now that I've seen the capabilities of SDL 3.0, you have my interest piqued! I read a Medium article a while back on GLFW vs SDL 2.0 and I stuck with GLFW because of it but now with the release of SDL 3.0, are there any clear victories for SDL 3.0 over GLFW that make it worth the switch? I'm currently writing a custom engine and one of my concerns is a possible performance overhead due to the bloat of SDL over GLFW.
So, generally SDL/GLFW isn't really where the performance hotspots will be, as both libraries mostly just abstract away the heavy lifting the OS might do for various things but aren't CPU-heavy themselves. Even the parts that can chew up processor time--image format conversion, audio mixing--are either completely optional or can be avoided. I'm pretty happy with how SDL3 is turning out, but I will always encourage you to use what makes you _happy_. And if you're enjoying GLFW, there's nothing wrong with continuing to use it. Take a look at the examples at examples.libsdl.org/ (which is still under construction right now, so excuse the jankiness of it), and maybe build something small with it to see if you like it enough to switch. Library features are one thing, but programmer happiness is way more crucial, and only you can decide how SDL or GLFW makes you feel. And either choice is 100% okay!
@@RyanGordon Thanks for replying! I'm happy performance won't be an issue, and I'm sure I'll be glad with whatever library I'll use. If the cross-platform experience(Linux, Windows, Android) is much easier on SDL than on GLFW, I think i'll make the switch sometime soon and also enjoy some of the miscellaneous features that I heard on that Steamworks presentation(filesystem stuff and retrieving machine information). Again, much appreciation for getting back to me!
BLESS the improved documentation library-wide.
You should make a twitch channel and speed run porting games
i actually love this idea lol, gotta have a speedrun clock too
@@MattieBW That's great. Download livesplit, make splits like "Game is bootable", start the timer and go. Keep the timer between sessions
I gotta do that when programming stuff too lol
very pleasant and informative video! Thank you very much for making these! The great thing about videos is that you see someone else's workflow :)
I love the old school editor and font, it feels very cosy.
Fantastic video. I was not expecting such a good commentary.
Not only helping us understanding the porting process but also the rational!
That was a blast, thank you for the guide!
I'm mostly a golang hacker these days, but I kind of enjoyed watching this. Thanks for all the Free Software work that you do! Gaming on Linux is important =D
This was an amazing watch! Would watch again :) Need more of these! Unreal needs the same makeover
Thanks a lot for this kind of video, very instructive! And you explaining why certain things were done that way in SDL2 brings so much light on so many questions haha. Thanks a lot. Welcome to Quake 3 Arena !
00:00:00 "SDL3 (starting with v3.1.3) is now officially at ABI lock."
00:00:40 Quake 3 Arena & ioquake3.
00:01:31 Fork ioq3 & switch to new branch.
00:01:40 SDL3 Migration Guide Wiki.
00:02:50 Semantic Patching via Coccinelle code matching & transformation tool.
00:07:00 Begin Porting
01:26:49 Build success, verify build only uses libc+libm+SDL3 shared libraries, run Quake 3, and create patch.
01:32:35 Conclusion.
01:32:59 "... Steam and Steam Link, all of Valve's stuff, Dota 2, CS2 ... have been using (SDL3) for a while ... so it's battle-tested and hardened and ready to go."
oh hey, didn't know you had a UA-cam channel! I've used PhysicsFS a lot and it's been very helpful.
I really appreciate that it's easy to modify, I was able to add hash buckets to the search path conflict check in around an hour (had to mount ~15k files).
Didn't even realize you were involved in game ports & SDL until I was reading about Quake derivatives on Wikipedia.
"You can also give it more than it wants" (in relation to audio streams)
Top work bro!
Incredible, you did something in 1 hour that I would take months or weeks... =(
Very educational! Looking forward to trying SDL3.
That was nice to watch, thanks!
Stumbled across this in my recommended and as i'm watching, i remembered that i still have the 4 classic quake games installed from when i had PC Game Pass. Apparently Microsoft does exactly nothing to restrict those files in case your Game Pass sub ends and you're free to copy all the necessary files to use a source port like ioquake3 or whatever is applicable for the game in question to play it without Game Pass.
Ryan C Gordon when Ryan C++ Gordon enters the room
Obviously way beyond the scope of this video, but would be cool to see a port to the new SDL3 GPU api instead of opengl, great work as usual ryan!
Ooh! Ty for this, I just found my next project (porting my "just for fun" game engine from 2 to 3)! I haven't visited c++ for a while, would be a good time to refresh my skills
Very interesting and captivating experience
Incredibly useful information. Looking forward to moving to SDL3!
I fucking love SDL, it's amazing
Subscribed. You are awesome
Nice work on the porting, thanks for this very interesting video!
I think you made one small mistake: At 1:00:10 you specify sdlCaptureDevice, but shouldn't it be sdlPlaybackDevice? In the end, you would want to reduce the gain on the output, not the input, right?
Are there plans to mainline this port to ioq3?
Also, overall, does SDL3 come with performance improvements over SDL2 or is ist just more about better consistency in terms of API and possible race conditions?
You're totally right, that should be sdlPlaybackDevice. Good catch! SDL3 has a bunch of good stuff over SDL2--including better consistency, more performance, and less race conditions--and you can get a quick overview of Cool New Stuff at wiki.libsdl.org/SDL3/NewFeatures !
@@RyanGordon Thanks for your quick response and pointing to this very helpful overview on SDL3! Happy coding!
@@RyanGordon Addendum: I created a pull-request in your GitHub-fork-repository for the change.
congrats on stable abi
I hope that Spearmint will also be ported to SDL3. Spearmint is a modified version of the Quake 3 Engine with some improvements (like bullet marks on moving platforms).
Amazing video
interesting video! i wonder if the migration patch script could also replace those integer != 0 checks with the correct boolean ones, but maybe that would be too slow/complicated if it has to check every SDL function name which work that way
That's not a bad idea, but I do suspect it _would_ make spatch even more brutally slow.
The compiler catches most of these, since most things either compare `< 0` or `== -1` ... but the comparison against zero will definitely need to be cleaned out.
I dont understand nothing but looks great, I just can write some variables and for loops in C that's all my knowledge.
That's where everyone starts, but we all learn a little more every day. You will, too. The nice thing about C is that there isn't much to the language itself--it's all in what functions you call in other libraries, for the most part--so you've already got a lot of it down. :)
yes
53:10 "capture" is actually better, because "recording" means the data is being saved somewhere. But capture - is just capturing a stream of data, without necessarily saving it.
by that logic, recording fits as well, since you are saving the data on the heap
What is the font you use in text editor? Looks fine
It's 9x15.bcf from XFree86, from the early 1990s. Newer isn't always better. :P
Why wouldn't setting all zeros work as silence for U16 audio? Silence with a DC offset is still silence no?
@@AlistairLynn silence for U16 audio is 0x8000. You can use memset with 0x80, which sets each sample to 0x8080, which is _almost_ silent, and indeed what we did in SDL2 for lack of a better option.
DC offset aside, it adds imperfection in an audio format that was largely unused anyhow, so we dropped U16 for SDL3.
@ zero for U16 is 0x8000 but my point is that any value which is the same for every sample is also silence, including full negative saturation at 0x0000, because that’s pure DC
Congrats. I've used SDL2 in hobby projects for years but will think about 3 soon. Is it usable today by people on 5 y/o Debian computers? I'm on Windows but try to be considerate of people who don't have the latest libraries
It is! It has support for newer things (like PipeWire, Wayland, etc), but it looks for those things at runtime and chooses what to use based on what's available on the system (if not PipeWire, maybe PulseAudio, if not PulseAudio, maybe ALSA, etc). The only thing SDL3 links directly against is the C runtime (and even that is optional on some platforms!). This is true on all platforms. On Windows, we support back to Windows XP, and someone is maintaining some small patches outside of our repo to get Windows 95 up and running.
How about SDL1.2 games? Also, has id Tech 4 patches for ETQW and Quake 4 carried on to SDL3?
So we've built something called sdl12-compat ( github.com/libsdl-org/sdl12-compat ) which makes SDL-1.2-based games work with SDL2, and this contains support for the idTech4 functions that were added to their fork of SDL 1.2. We've _also_ built sdl2-compat to make SDL2 games work with SDL3, and it explicitly works to chain all this together...so you drop a few new libraries into your idTech4 game folder and they're running on SDL3 without even recompiling the games. For games that aren't getting updates, this is the right thing to do. I chose quake3 for this video because ioquake3 is still actively maintained, so it makes sense to modernize its source code to use SDL3.
what do you recommend instead of fte? i'm so slow in vscode..
I really can't recommend something specific, since these things are such personal choices (and as FTE demonstrates, it's 100% okay to find something imperfect you love and use it for 30+ years). I'd tell you to try lots of things--vscode, Qt Creator, Lite XL, heck, maybe even Emacs, I don't know--each for a little while, and then decide what you like best. And once you make a choice, commit to it for a little while unconditionally, and the small things you don't like will probably be papered over by muscle memory quickly and the big things you like will dominate.
But for me, what I like about FTE is that it does one thing well and doesn't try to manage my whole life...it's a text editor, not an IDE...and while that is a minor inconvenience from time to time, it's nice to jump to other useful tools for specific tasks instead of trying to figure out how to coerce my One And Only Tool to work for me.
I have no idea if any of this helps, but that's my advice.
Would you make a PR with the port to ioquake3 repo?
I may, but the patch in the video needs more work before it would be PR-ready (for example, I skipped all the non-Linux pieces of the Makefile). They also have to decide if they're willing to drop PowerPC Mac support (as they seem to have SDL2 headers specifically for that), and maybe other ancient platforms, or keep a _lot_ of ifdefs to continue to support SDL2 in parallel.
What TUI editor is that at the end? It's a bit hard to google "edit". A link to source would be much appreciated!
I was curious also, but I found it - it's the FTE text editor.
Foldable Text Editor - FTE
@@xusdom Thanks... but it crashes with anything bigger than 1080p. Unusable for me >
@@bparker06 It's my fork of FTE, which has a bunch of fixes and uses SDL! github.com/icculus/fte
I did some SDL2 in 2018-2019. I found the interfaces quiet nasty. Been waiting for this. Now I got a MSC in computer science and math, and 3 more years in the industry as a programmer/data scientist. Lets make some games!
no sdl gpu?
Quake 3 is a fixed-function pipeline game*, so it would be non-trivial to move it to the GPU API...more than I could do in a reasonable UA-cam video.
* technically, q3a offered the world a first look at the concept of vertex shaders...done in software, backed by fixed-function OpenGL. But the point still stands. (Also, there _is_ an OpenGL2 renderer in ioquake3 that uses GLSL, but I have no experience with it and I think even with that infrastructure in place, a GPU port would probably take some hard work. But maybe later!)
@@RyanGordon Mmm I have a project that's basically some old abandonware 32bit dx9 game that is mostly leaked code(they don't care) and some dx9 that I cobbled together. It's really simple, only basic pixel shaders. The rest is just uploading a mesh and DrawIndexedPrimitive. I assume this would also be hard to port to SDL GPU since it's still mostly a state-machine. (I am not a graphics engineer.)
Do you work on SDL3?
I do! I'm one of the lead developers on it.
Heya, I've seen your Steamworks presentation, "Game Development with SDL 2.0" it's called, and now that I've seen the capabilities of SDL 3.0, you have my interest piqued! I read a Medium article a while back on GLFW vs SDL 2.0 and I stuck with GLFW because of it but now with the release of SDL 3.0, are there any clear victories for SDL 3.0 over GLFW that make it worth the switch? I'm currently writing a custom engine and one of my concerns is a possible performance overhead due to the bloat of SDL over GLFW.
So, generally SDL/GLFW isn't really where the performance hotspots will be, as both libraries mostly just abstract away the heavy lifting the OS might do for various things but aren't CPU-heavy themselves.
Even the parts that can chew up processor time--image format conversion, audio mixing--are either completely optional or can be avoided.
I'm pretty happy with how SDL3 is turning out, but I will always encourage you to use what makes you _happy_. And if you're enjoying GLFW, there's nothing wrong with continuing to use it. Take a look at the examples at examples.libsdl.org/ (which is still under construction right now, so excuse the jankiness of it), and maybe build something small with it to see if you like it enough to switch.
Library features are one thing, but programmer happiness is way more crucial, and only you can decide how SDL or GLFW makes you feel. And either choice is 100% okay!
@@RyanGordon Thanks for replying! I'm happy performance won't be an issue, and I'm sure I'll be glad with whatever library I'll use. If the cross-platform experience(Linux, Windows, Android) is much easier on SDL than on GLFW, I think i'll make the switch sometime soon and also enjoy some of the miscellaneous features that I heard on that Steamworks presentation(filesystem stuff and retrieving machine information). Again, much appreciation for getting back to me!
I don’t know why I watched this(yup all of it), didn’t work on any SDL app in my life 😂
i know this OS! is Ubuntu linux
Good stuff!
SDL 3 API is super icky.
Tries to be C++ but falls flat.
Okay.
Make sdl3 vulkan