Splitting up execution

[rb6502]

I've recently started working on updating MAME from SDL2 to SDL3. The first pass will be a direct port, but SDL3 optionally supports a "split main loop" concept that fits how macOS/iOS, Emscripten, and Wayland all prefer to operate and that will be a second pass.

When this is enabled, SDL takes over main()/WinMain() and calls 4 callbacks defined by us over the lifetime of the program.

1. SDL_AppInit() is called first with argc and argv. This is expected to set everything up and return. If it returns failure, the program ends.
2. SDL_AppIterate() (another callback we define) is called repeatedly for the lifetime of the program (basically per-frame). It returns a "keep running or quit" flag.
3. SDL_AppEvent() (a third callback) is called when SDL events occur; you do not need to call SDL_PollEvent() or whatever.
4. SDL_AppQuit() is called when SDL is shutting down.

SDL_AppInit() returns a pointer which is then passed to the other 3 callbacks (for instance a this so you can trampoline up into C++).

I'm opening this to hash out how best to modify MAME for this. My initial thoughts are:

1. emulator_info::start_frontend() will need to create the frontend object in a way that doesn't de-scope it, and the frontend object will be the magic pointer returned from SDL_AppInit().
2. mame_machine_manager::execute() and running_machine::run() will need to be split into separate startup and per-frame calls.
3. In order to avoid OSD needing to know more about the core, we'd define a new call in emulator_info:: that takes the frontend object pointer and does the right thing for SDL_AppIterate().
4. We'd provide a wrapper that makes everything look like the status quo for the Win32 OSD. It would be possible to rework the Win32 OSD to work directly with the split main loop as well, and we may wish to long-term, but there's no immediate benefit that I'm aware of.

[cuavas]

Changing the event model is going to require some fairly major changes, particularly to the video manager, as it’s currently where the event loop effectively happens.

MAME needs input updates and UI events to only appear when it expects them to, and when that is exactly depends on the -lowlatency option. So if we’re getting “pushed” events, the OSD modules will need to be able to accumulate/queue stuff until told it’s time to update. The UI input manager queues events, and there’s kind of crude support for this with analog axes already to deal make UI latency suck less while also allowing the -lowlatency option to work.

The video manager will need to be changed so instead of sleeping, it returns with an indication of how soon it needs you to call it back.

This is all stuff that would need to be changed to allow support for features like rollback netplay, anyway. The current architecture is a mess.

I don’t think trying to make a wrapper to support the current Windows OSD as-is is a good idea. The current way it handles events looks like something out of an ’80s Mac application. There’s a bunch of weirdness caused by the debugger and OSD both polling for events when you’ve broken into the debugger (this prevents implementing debugger keyboard shortcuts in a sane way, for example).

It eventually needs to be dragged into the 21st century. The trouble is, changing any of this stuff is a minefield, and always turns into a far bigger job than you expected.

[cuavas]

Further to this, if we’re going to SDL3 as the primary SDL target, what does that do for Linux distro support? What’s the oldest Ubuntu, Fedora, etc. with SDL3 included (and a usable version, not a horribly buggy version like early SDL2)?

It also means I’ll have to rebuild my environment for testing Windows release candidates and building releases to a much newer MinGW for SDL3 support. That means things potentially breaking, although we’re a lot better with catching breaking changes in compilers and runtimes than we used to be.

And if I’m updating the build environment anyway, is it time for a radical change? Do we switch to clang for x86-64 releases, like we’re using for AArch64? Do we switch from the ageing MSVCRT to ucrt, dropping support for everything before Windows 10? I mean, Windows 10 is already out of support anyway.

[rb6502]

The current SDL3 release is 3.2.28.

For major Linux distros:

• Fedora 42 and 43 both have 3.2.24 in the official updates, which is fine. Most of the RHEL derivatives are similar or newer.
• Debian Sid has 3.2.28, Trixie is at 3.2.10. I don't love 3.2.10, but it might be possible to get newer unofficial packages?
• Ubuntu Plucky (25.04) is at 3.2.8 and Questing (25.10) is 3.2.20. PPAs are available to get newer versions.
• Ubuntu Noble (24.04 LTS) doesn't have it at all, which is why Github's CI image includes Homebrew. The CI rules in the sdl3 branch install the latest SDL3 and SDL3_ttf with Homebrew and compiling works fine from there.
• OpenSuSE 15.6 and 16.0 both have latest, 3.2.28.

On Windows with MSYS2 ClangARM64 I was able to just drop the SDL3 and SDL3_ttf packages into an existing working setup and it was fine. I don't think any compiler updates are strictly necessary, although if we want to bump everything I'm not opposed. As far as MSVCRT vs. ucrt I would gate that on how close Moogly is to being able to check in -video d3d11. If we're going to require Windows 10, I'd like to demote -video d3d9 so MAME by default will run on a clean Win10 or 11 install without the now-ancient DX9 runtime.

[cuavas]

Dropping support for Linux distros less than two years old wouldn't be viable. We've always provided support for Linux much older than that.

FWIW, MAME with D3D9 video works out-of-the-box on Windows 11 Pro Arm64 on a Lenovo notebook. I kind of doubt Lenovo would be going out of their way to pre-instal the DirectX 9 runtime, so it seems MS may have decided to start including it again.

[rb6502]

I mean, we can support older distros, it just may be a case of "you need to compile SDL3 yourself". (Eventually all distros are Gentoo?) I'd really rather not drop it into 3rdparty though.

[cuavas]

For quite a while, I’ve set the benchmark for Linux support at “can build with only packages from the main official repo in two most recent Ubuntu LTS releases”. Last time I bumped the compiler requirements to GCC 10.3 and the SDL requirement to 2.0.14 (mamedev/mame@fe923e9 in 0.265, released in April 2024), I had to fight objections that it dropped support for Ubuntu 20.04 which was “only four years old”.

Not even working out-of-the-box with packages from the main official repo in the most recent Ubuntu LTS seems way too aggressive, given our historical positions on OS support.

Windows is a pain because of the Python packages needed for building documentation, etc. The MSYS people never do proper version dependencies, so if you just update everything, you usually end up with broken Python packages, because the current latest version of one won’t work with the current latest version of another, and you have to go selectively downgrading things until you get a working setup again (and of course you downgrade one thing, then discover that requires you to downgrade something else, and it multiplies).

There’s also the general risk of something breaking when updating the versions of any of the MinGW runtime libraries in releases. We’ve been using mostly the same library versions for Windows releases for four years now (I’m conservative on updating things, favouring stability over bleeding on the bleeding edge).

Also, the MSYS people are reducing the number of things they provide i686 packages for. There’s an i686 sdl3, but no i686 sdl3-ttf, so it would necessitate gradually winding down Windows i686 support and testing.

[rb6502]

What about making SDL3 optional (OSD=sdl3) until the distro landscape improves? On macOS it could be the default since it's equally easy to compile both ways there and that would get us CI coverage until Ubuntu catches up (new LTS in April will definitely support it).

Maybe we also drop Windows support for SDL builds. You and I are likely the only people who've built Windows with OSD=sdl in recent memory. The benefits of that configuration that once existed are long gone with the improved Windows native OSD modules since then.

If it wouldn't be such a mess with GENie I'd advocate for Windows going full native with the official Python for Windows distribution and MSVC Community Edition as the compiler. That would be drastically easier to set up and maintain. But I think that's basically hard gated on CMake.

[cuavas]

If we're serious about untangling the event loop, will we still be able to keep basic SDL2 support? If we keep the option to use SDL2 around for a while, that will be OK.

VS Community Edition still sucks for building on Windows. Even with CMake I'd do releases with GCC or clang and probably ninja as the build tool. Still need the MinGW environment for building documentation, etc. on Windows as well, unless you want to go to separately installing TeXLive, Python, rsvg, and a pile of other stuff, then messing with paths, and so on. It's a lot easier to just use pacman to install everything.

I don't have a Linux system with a multi-touch display, so Windows with OSD=sdl is the only way I have to test touch input support with SDL.

[rb6502]

I'm serious about untangling the event loop, but I'm also OK with waiting until closer to when we're comfortable with getting rid of SDL2. It should be possible to adapt SDL2 to work with it, but it would also be dead code walking and we have enough to do without writing something that's deprecated from day 1.