The Steam Frame probably has to be an ARM processor, because you don’t want to have to wonder about space and price constraints with an x86-64, and whether an eyeball makes a good heat sink.
And it probably doesn’t matter much, but that’s one less thing to worry about when porting from the Oculus Quest.
But unlike Proton’s Faustian bargain (the catalog all works! …why port at all?), in VR, the user tends to convert low framerate into vomit, so a real native port could be _crucial_.
(You can also download the entire wiki as static HTML pages for offline viewing, or even peruse them as Unix manpages. We're taking documentation very seriously in SDL3!)
If you liked the Quake 3 video, this one goes into more detail about new and advanced SDL3 features! Porting DirkSimple from SDL2 to SDL3: https://youtu.be/V_MWXDr3Nu4
And I plan to do some YouTube videos to show how to migrate your game. It took me about an hour of poking around to get ioquake3 ported last night, I'm going to do it from scratch tomorrow and record it, explaining the details as I go. Stay tuned. :)
@vv221@Conan_Kudo We learned a lot from sdl12-compat, among the lessons was that it was useful to a much wider audience than we expected--not just hacker hobbyist types, but literally entire Linux distros--and also that waiting years to start it was a massive mistake, because we had to figure out incompatibilities as we worked on it.
For sdl2-compat, whenever we broke compat in SDL3, we had to make a matching commit in the compat library to deal with it.
We're rushing to an official release from here, but what's there has been battle-hardened in Steam and DOTA2 and CS2 for over a year now, across several platforms.
Don't care about the new toys but want your SDL2 program to have the power of SDL3? We built sdl2-compat in parallel with SDL3, so you can just drop a build into your app and go:
@olafurw I'm both honored and deeply humiliated that a lot of these comments are from me, from the original Linux port I did at Loki Software.
The _exit() is there specifically because C++ game code back in the day was loaded with static destructors that usually only did two things: deallocate memory, and crash. Since one was unnecessary and the other disastrous, we'd clean up just the crucial pieces and _exit() at the end to kill the process without running them.