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
