sdl-compat 1.2.52 Debuts As Initial SDL-1.2-Atop-SDL-2.0 Release

[phoronix]

Phoronix: sdl-compat 1.2.52 Debuts As Initial SDL-1.2-Atop-SDL-2.0 Release

In development recently has been sdl12-compat as a compatibility layer that implements the SDL 1.2 interfaces atop SDL 2.0. This effort allows many older Linux games not seeing updates for SDL2 to in turn make use of the newer version by way of this compatibility layer...

https://www.phoronix.com/scan.php?page=news_item&px=SDL-Compat-1.2.52

[Azpegath]

This is really great!

[birdie]

This is really great!

This would have been great if this had been the case for all other libraries in Linux. One out of thousands? Who the f cares?

Where's the compat layers for GTK 1,2,3; Qt 1,2,3,4,5; for glibc for f's sake? For the things that really matter?

[Azpegath]

This would have been great if this had been the case for all other libraries in Linux. One out of thousands? Who the f cares? Where's the compat layers for GTK 1,2,3; Qt 1,2,3,4,5; for glibc for f's sake? For the things that really matter?

Are you trolling? It doesn't cure cancer either, but it doesn't make it less great for its use case.

[Chewi]

I've been meaning to get this into Gentoo for a while (where it will probably replace the original library), but I got sidetracked. Will try to get it done soon.

[waxhead]

Where's the compat layers for GTK 1,2,3; Qt 1,2,3,4,5; for glibc for f's sake? For the things that really matter?

Amen to that, these days things that WORK and in many cases work better than the so called modern "improvements" tend to get obsoleted by a misconception that old software turns bad and rot over the years. Software is NOT milk or food in your fridge, as long as the darn thing has the same checksum as it did when it was written it does NOT magically accumulate bugs or worsen.

If only people tried to improve on what was already good instead of deciding to rewrite the entire universe every decade or so. As I have nagged about for quite a while now the "dark mode" epidemic is a prime example of insanity. Each application implements a "dark mode" theme that is NOT consistent with other applications except being dark to look at. Things like that USED to be done in a global preferences / theme configuration. The only mistake with that old approach was that it should have been possible - in that global preferences - to set themes pr. application. That way one could have improved on what was already there and supported a unified look across applications, plus the ability to tune individual applications to your own taste.

Rather simple to understand... And something I miss...

Also in the good old days when Amiga computers ruled there was great stuff like the XPK library that handled just about any compression method thrown at it. All your application needed to do was to support the XPK library and it would magically read all kinds of compressed data transparently - all that was needed was a "plugin" installed globally for to make all applications that used XPK support a new compression routine. Datatypes worked much the same way.

This too is missing. And yes we get a lot of cool things these days too by all means , but we are missing bits of pieces of the essentials.

On topic again: I have done a little bit of programming on SDL1 and SDL2, it is really a great framework so not all things gets worse it seems

[birdie]

Are you trolling? It doesn't cure cancer either, but it doesn't make I less great for its use case.

Where the hell did you notice trolling in my post? Go check with a shrink if raw solid facts skew your perception so much you call them "trolling".

Also, the hell you mentioned "cancer"? API compatibility is probably the biggest curse and bane of Linux. It basically doesn't exist in any shape or form.

A new day? Go effing recompile your software again and again. Of course, if it's API compatible and of course if GCC is happy about it.

[kpedersen]

This would have been great if this had been the case for all other libraries in Linux. One out of thousands? Who the f cares?

Where's the compat layers for GTK 1,2,3; Qt 1,2,3,4,5; for glibc for f's sake? For the things that really matter?

The intended use-case for this is things like Neverwinter Nights, a closed-source blob utilising SDL 1.2 for the windowing system that can't be recompiled or relinked. Instead the SDL it uses can be replaced with this "compat" version (almost like a drop-in DLL replacement common on Windows) and then it will benefit from the SDL2 features underlying it. I.e standing a chance at running natively on Wayland, new gamepad APIs, etc.

I do actually agree with you for the Gtk+ compat stuff though. In particular internally at work we maintain a Gtk+2 that sits ontop of SDL2 because we prefer the stability and functionality of Gtk+2, especially when it comes to theme engines. An official compat strategy would have saved a bit of work. There are also loads of great Gtk+2 tools that will start to rot unless Gtk+2 gets maintained.

As for Qt, MOC and the non-standard build system already makes that awkward. Screw it, someone else can deal with that; I avoided Qt for that reason.

[Vistaus]

Are you trolling?

He's always trolling. Everyone around here knows that.

[PluMGMK]

Well, this seems to have fixed that weird issue I had where Dosbox on Sway wouldn't recognize the arrow keys (forcing me to use the numpad)

Also, I guess it's just continuing the SDL versioning scheme, but that's a pretty weird "initial" version number! :P