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

[Raka555]

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.

I suspect the person thinks you want all the compatibility layers you mentioned in this sdl-compat library.

[oiaohm]

And even for old software that hasn't been continuously worked on, there are two other considerations. First, anything still in use is proven by its survival. Second, at some point all your productivity is spent keeping yourself from sliding down the mountain. If random churn forces the entire Linux desktop to be rewritten every 20 years on average, the total amount of software that we have will never exceed 20 years of community effort. For a small community, that's a big problem.

The reality here is the churn is not random. 20 years ago that 2002 we don't have 64 bit x86-64 cpu yet they only get released in 2003. Your first dual core x86 cpu 2004. Yes you first quad core x86 systems is 2007. Then you have the raspberry pi 2012 as one of the items starting to bring arm more into end users. There is the treadmill of computer architecture changes. The reality here is Linux desktop from 2002 does not perform well on 2022 hardware because its not designed to take advantage of 2022 hardware. Please note when I say does not perform well its everything from not working at all to just not using the hardware effectivity.

Yes that 20 year average idea is a real pain. The reality its closer to 15 years than 20 with the major driving force is hardware change. The ABI compatibility stuff is a smaller factor. The reality is Microsoft with its massive ABI compatibility runs into issues support too large of time frame of hardware to the point that Microsoft is looking at displaying a watermark on screen with Windows 11 to display unsupported hardware if your hardware is over 10 years old due to the issues.

yump the reality is how can we be updating the software every 10 years with the least amount of developer effort is a question we need to answer because the hardware treadmill is not going away any time soon. The realities of the hardware treadmill is savage.

[drake23]

Back to topic this is just fantastic news for retro gamers. So thanks to all the Devs!!!!

[jacob]

jacob Software developed since decades ago contains decades of embodied knowledge and experience about the problem domain. When you throw something out and redesign it from scratch, all of that is lost unless the redesign starts with a thorough study of the entire commit history and everything written in bug reports.

This comment has been coming up in various threads, usually raised by people who oppose Wayland, systemd or virtually any change to existing software, but it's patent nonsense. The "decades of embodied knowledge" are very rarely worth anything and especially they very rarely constitute anything other than technical debt. If you were right, then no-one could ever create another kernel or another compiler, and those are examples of software that indeed contain and require extensive knowledge unlike trivial system tools. In the case at hand, there is virtually zero value in preserving the decades of "knowledge", for example, about how to handle private colormaps using xlib.

It is also a fallacy for another reason, which is that the redesign from scratch is often carried out by the very people who built or maintained the previous stack, and they are the ones with the knowledge. Wayland for example is the brainchild of Xorg developers and I would doubt that anyone could claim to possess better understanding of the problem domain than them. Vulkan has been created by the Khronos group, GTK4 has been created by the people who previously developed GTK1, 2 and 3, SDL2 is from the SDL1 developers etc. They are the ones in the best position to learn from the past. Besides, learning from previous experience often consists in learning what to AVOID, that is a lesson that apparently many people seem not to accept.

And even for old software that hasn't been continuously worked on, there are two other considerations. First, anything still in use is proven by its survival. Second, at some point all your productivity is spent keeping yourself from sliding down the mountain. If random churn forces the entire Linux desktop to be rewritten every 20 years on average, the total amount of software that we have will never exceed 20 years of community effort. For a small community, that's a big problem.

That's a total non sequitur. Just because something has been around for a long time doesn't mean it's "proven". People just use whatever is available, even if it means bending backwards and relying on hacks and workarounds that sometimes become so pervasive that people even forget that they simply shouldn't exist if the system was designed correctly in the first place (case in point, PID files). By the same argument, CP/M was undoubtedly "proven", yet no-one sane would argue that we should have stuck with that. OpenGL wouldn't have existed because PHIGS/PEX was "proven", TCP/IP wouldn't exist because there was the "proven" (and "standard") OSI stack, etc etc etc. Once again, the key point is accumulated technical debt.

Besides, if you want to argue that the old X11 for which SDL1 was primarily designed was "proven", then your claim is immediately proven false (pun unintended) by the fact that no OS designed from scratch since X11 appeared actually decided to use it - Windows, MacOS Classic, NextStep (followed MacOS X), BeOS, QNX etc all implemented their own graphics stack instead of using the supposedly "proven" X11. Linux is, at last, following suit, for the same reasons.

[smitty3268]

F it and I'm logging off

If only that were true...

[QwertyChouskie]

It's true that this compatinility layer provides faster rendering under wayland(SDL 1.x is very slow under wayland in comparison to native Xorg on my Intel machines), when using native SDL2 wayland backend(otherwise it's even slower).

But it doesn't change the facts, that's totally useless code(until terminal/web browser is sufficient for somebody), because it still doesn't run "Frogatto and Friends", which is IMHO one of the cutest Rayman clones and FLOSS games available under Linux.

So I call for boycott of this SDL Compat layer, until Frogatto is playable!

The last tagged release was in 2012, but the game is still seeing frequent commits on GitHub: https://github.com/frogatto/frogatto

You could just download the latest code directly from Git and not have to deal with compat layers.

[evil_core]

The last tagged release was in 2012, but the game is still seeing frequent commits on GitHub: https://github.com/frogatto/frogatto

You could just download the latest code directly from Git and not have to deal with compat layers.

I've tried building it again from arch PKGBUILD and building anura-git fails:

Building: src/sound.cpp 
[B]src/sound.cpp:[/B] In member function ‘[B]virtual void sound::{anonymous}::BinauralDelaySoundEffectFilter ::MixData(float*, int)[/B]’: 
[B]src/sound.cpp:1232:40:[/B][B]error: [/B]expected primary-expression before ‘[B]int[/B]’ 
1232 |             const int nsamples_delay = [B]int[/B](std::abs<float>(delay_)*SampleRate); 
     |                                        [B]^~~[/B]
make: *** [Makefile:237: build/sound.o] Error 1
[B]==> ERROR:[/B][B] A failure occurred in build().[/B]

[QwertyChouskie]

I've tried building it again from arch PKGBUILD and building anura-git fails:

Building: src/sound.cpp
[B]src/sound.cpp:[/B] In member function ‘[B]virtual void sound::{anonymous}::BinauralDelaySoundEffectFilter ::MixData(float*, int)[/B]’:
[B]src/sound.cpp:1232:40:[/B][B]error: [/B]expected primary-expression before ‘[B]int[/B]’
1232 | const int nsamples_delay = [B]int[/B](std::abs<float>(delay_)*SampleRate);
| [B]^~~[/B]
make: *** [Makefile:237: build/sound.o] Error 1
[B]==> ERROR:[/B][B] A failure occurred in build().[/B]

It builds fine on my system with GCC 11.2.0, and compiling with Clang lead to a different error (https://github.com/anura-engine/anura/issues/320). That being said, you could try changing the problematic line to:

const int nsamples_delay = int(std::abs<float>(delay_) * float(SampleRate));

Also consider filing a bug report: https://github.com/anura-engine/anura/issues/new