On Tue, 13 Jun 2023 at 11:10:41 +0800, Paul Wise wrote: > On Mon, 2023-06-12 at 17:24 +0100, Simon McVittie wrote: > > SDL 1.2 was superseded by SDL 2 several years ago, and no longer receives > > upstream maintenance or releases. Maintained software that uses SDL 1.2 > > should be ported to SDL 2. > > It was pointed out to me on IRC that some SDL 1.2 extension libraries > might not have an SDL 2 equivalent yet, or they might not be in Debian. ... > Looking through the packages, these appear to be missing: > > console kitchensink pango sge sound > > Perhaps there are better equivalents for these in SDL 2 though?
-kitchensink is already a SDL-2-only library, despite its name and version number not containing a 2 (but it appears to have only one reverse-dependency, and is currently orphaned, so I wouldn't recommend relying on it). The SDL extension libraries that I've mainly been looking at are the ones maintained by the same upstream developers as SDL itself: -image, -mixer, -net and -ttf. Those all have maintained SDL 2 equivalents (or semi-maintained in the case of -net, which is IPv4-only and generally fairly obsolete - I believe the recommended replacement for software that wants IPv6 support is to use BSD-style socket APIs directly). Nothing in Debian depended on -console, and that has been true for quite some time, so I've asked for it to be removed from trixie. SDL 2 has a "render" API which might be quite close to being a replacement for -sge. libsdl2-gfx also seems to deal with the same general problem space. I'm not sure how the purpose of -sound differs from -mixer: they both seem to be primarily a convenience API for decoding and playing popular formats like MP3. You seem to have looked at -pango already. > Will the SDL team be packaging available SDL 2 equivalents for > the SDL 1.2 extension libraries that are in Debian? I can't speak for other SDL team members. I don't plan to package third-party SDL extension libraries (those not maintained by SDL upstream) myself, but interested maintainers of games that need them are very welcome to do so. I'm not intending to ask for the SDL 1.2 extension libraries to be removed unless they either get unfixed RC bugs, or reach a situation where no other Debian package depends on them - but I'm also not intending to maintain those myself, and part of the purpose of this MBF is to raise awareness that the whole SDL 1.2 ecosystem has been effectively dead for multiple years. > > For legacy software that cannot be ported, SDL upstream have produced a > > replacement library, sdl12-compat, which implements the SDL 1.2 API/ABI > > by dlopening SDL 2 (and correcting for API/ABI changes). In Debian, this > > is currently available as libsdl1.2-compat-shim. > > I tested hex-a-hop under GNOME Wayland. It segfaults with SDL 1.2 and > SDL_VIDEODRIVER=wayland "Classic" SDL 1.2 never had a Wayland backend, so that is not an interesting test-case: it is expected that games will crash or otherwise exit unsuccessfully when asked to use a backend that doesn't exist. SDL_VIDEODRIVER=wayland is only expected to work with SDL >= 2, either directly or via libsdl1.2-compat-shim. > When using the compat lib via LD_PRELOAD, the X11 mode has > a window title bar and border but those are missing in Wayland mode. libsdl2-2.0-0 Depends on libdecor-0-0, which Recommends libdecor-0-plugin-1-cairo | libdecor-0-plugin-1. If at least one libdecor plugin is available, then you should get a titlebar under native Wayland (in practice usually bold white text on a black background, with minimize/maximize/close buttons that light up orange/green/red on mouseover - that's the cairo plugin). openarena and chocolate-doom in windowed mode are examples of SDL2 games where I've verified that this works, and amoebax is an example of a SDL 1.2 game where this works while using libsdl1.2-compat-shim. If Recommends are not installed, then as per Policy §7.2 you have an unusual installation and can expect to see reduced functionality. smcv