sdl12-compat 1.2.54 Pre-Release Gets More Games Running On This SDL2 Compatibility Layer

[phoronix]

Phoronix: sdl12-compat 1.2.54 Pre-Release Gets More Games Running On This SDL2 Compatibility Layer

The sdl12-compat is a SDL 1.2 compatibility layer implementation atop SDL 2.0. This sdl12-compat project allows for old, out-of-date games and other applications relying on the old SDL 1.2 interface to in turn run via the modern SDL2 library for better compatibility with input devices, Wayland support (assuming no direct X11 hard dependencies), support for PipeWire audio, improved input controls, and various other enhancements only found in SDL 2.0 and not the unmaintained SDL 1.2...

https://www.phoronix.com/news/sdl12-compat-1.254

[theuserbl]

Is sdl-compat only API-compatible to sdl 1.2 or also ABI-compatible?

Similar to the Athena Widgets libraries libXaw.so and libXaw3d.so .
Replacing libXaw.so with libXaw3d.so, all appliations (like xman) have then 3d-controls.
So with the same ABI, sdl1.2 could simple replaced with more features for already existing binary programs, whithout having the source code of them.

[nanonyme]

I suppose it has to be ABI-compatible if intent is it is a drop-in replacement.

[Chewi]

ABI. API wouldn't be much use when it's mainly intended for old commercial games that will never be updated.

[Awesomeness]

I suppose it has to be ABI-compatible if intent is it is a drop-in replacement.

Depending who you ask there are two different meanings of that term: Either the binary is a drop-in replacement or it's a drop-in replacement at compile-time.

[brad0]

ABI. API wouldn't be much use when it's mainly intended for old commercial games that will never be updated.

It's definitely for more than just old commercial games. All of the programs / games listed in the article are not binary only or old commercial games. As an OS developer ABI compatibility does not matter for our use case, but API does. I can pretty much guarantee when switching from the old SDL 1.x ports to these shim layers they would not be 100% ABI compatible.

[schmidtbag]

That's really cool - helps make modern Linux gaming just a little bit easier.

[oiaohm]

ABI. API wouldn't be much use when it's mainly intended for old commercial games that will never be updated.

That mistake. API compatible is required.

https://github.com/libsdl-org/SDL/blob/main/docs/README-dynapi.md

Issue here is there are SDL1 and SDL2 games that static link SDL1 SDL2 into themselves. Its the SDL2 and later that can use SDL_DYNAMIC_API in the static case to force a new SDL version. SDL1 if static linked to use sdl12-compat is rebuild.

Also this sdl12-compat is being used with open source games so API compadible is important as well.

So both ABI and ABI compatible is required.

[Quackdoc]

time to go back and enjoy some old games, maybe I can even find a real cheap CRT monitor somewhere to plug into my hd 4350

[theuserbl]

Issue here is there are SDL1 and SDL2 games that static link SDL1 SDL2 into themselves. Its the SDL2 and later that can use SDL_DYNAMIC_API in the static case to force a new SDL version. SDL1 if static linked to use sdl12-compat is rebuild.

Static linking is in this point no problem.

SDL versions < 2.0 are licensed under the LGPL.
For static linking the LGPL is like the GPL: The created program have to be publised under an LGPL-compatible OpenSource license. So anybody can then rebuild the program with sdl12-compat.
If the program is not static linked, then there existing commercial closed source programs. But if ABI compatiblity exists, that is not a problem.

SDL version >= 2.0 are licensed under the zlib license, which is similar to the MIT-license and the BSD-license. That allow also static linking, without publishing the source code.
But sdl12-compat wants to replace SDL 1.2.