sdl12-compat 1.2.66 Gets More Games/Software Working On This SDL2 Portability Layer

[timofonic]

Software, by definition, is a tool which should serve you and not the opposite. FOSS is not a religion and not an excuse for mediocrity and lower level user experiences. If you, personally "loved" FOSS, then you would want to be as useful as possible. That would mean only removing APIs that should never have existed in the first place or that you are unable to feasibly maintain adequately. Compatibility layers are good for FOSS end users. They do however demotivate developers from porting to new APIs. This means that if you don't find compatibility layers in a FOSS project, then that project cares little about its users and favors developers over them. Users will always want compatibility layers.
The sad state of FOSS today is that it favors developers over end users. You should already know that at least from GTK3/4 and Gnome3.

GTK and GNOME are bad both for developers and users. It's not a good example at all. It's also governed by a corporatocracy disguised as community project.

Weasel attitude is destructive, not constructive at all. If he do, he should code what's better instead whinning all time on forums and such.

APIs need to evolve. SDL uses compatibility layers to remedy this.

[Weasel]

I love your positivity! You should be next FOSS leader!

Thanks, I agree. The world will be far better off if I was.

Do you hate FOSS? If yes...

Why do you participate here? What's the reasoning of your trollish attitude?

Where's Phorodows for people such as Weasel?

No I hate the open source userland libraries, not because they're open source, but because of the brain damaged "design" they have. It's not related to open source, it just happens to be that way (you know, mostly cultural thing that's hard to "change" because of expectation roots).

Not all libraries though. glibc for example is backwards compatible, for the most part. The kernel is also open source but it has a stable userland-facing API/ABI which is great. However the kernel has no stable in-kernel ABI, which is another can of worms.

macOS is closed source and yet it also breaks backwards compatibility even worse than Linux userland libs and I hate it a lot more.

Windows just happens to care about backwards compatibility which makes it by default superior in this aspect (this aspect only). And I use Wine precisely for this reason: to get away from the rest of the Windows garbage while keeping its API/ABI platform available to me. Best of both worlds.

So take your pseudo religion and shove it somewhere where it doesn't shine.

[timofonic]

Thanks, I agree. The world will be far better off if I was.

No I hate the open source userland libraries, not because they're open source, but because of the brain damaged "design" they have. It's not related to open source, it just happens to be that way (you know, mostly cultural thing that's hard to "change" because of expectation roots).

Not all libraries though. glibc for example is backwards compatible, for the most part. The kernel is also open source but it has a stable userland-facing API/ABI which is great. However the kernel has no stable in-kernel ABI, which is another can of worms.

macOS is closed source and yet it also breaks backwards compatibility even worse than Linux userland libs and I hate it a lot more.

Windows just happens to care about backwards compatibility which makes it by default superior in this aspect (this aspect only). And I use Wine precisely for this reason: to get away from the rest of the Windows garbage while keeping its API/ABI platform available to me. Best of both worlds.

So take your pseudo religion and shove it somewhere where it doesn't shine.

How polite you are. Also, your message isn't homophobe at all.

You repeat the API and ABI mantra all time, yet you never provide detailed examples. It seems you even have zero clue about programming, so unable to provide proof of your accusations

Do it better next time, troll. I'm sure you can improve your trolling efforts!

[Weasel]

How polite you are. Also, your message isn't homophobe at all.

You repeat the API and ABI mantra all time, yet you never provide detailed examples. It seems you even have zero clue about programming, so unable to provide proof of your accusations

Do it better next time, troll. I'm sure you can improve your trolling efforts!

LMFAO who the hell are you again? Absolute no name.

You asked for example, here's one, I've repeatedly provided it along with many others in the past, and I believe one of them was even for you, bird brain: https://blog.hiler.eu/win32-the-only-stable-abi/

Summary gist:

I think this whole situation shows why creating native games for Linux is challenging. It’s hard to blame developers for targeting Windows and relying on Wine + friends. It’s just much more stable and much less likely to break and stay broken.

BTW just so you know, the guy who wrote that blog post is the Proton maintainer.

Some more questions and food for thought for you:

Can you run apps compiled against gtk2 with gtk3 or gtk4?
Can you run apps compiled for qt3 with qt4, qt5 or q6?

And the topic at hand:

Can you run apps compiled for SDL1 with SDL2 before this project existed (which was the whole point of my post)?

No?

Stay salty loser.

[ClosedSource]

GTK and GNOME are bad both for developers and users. It's not a good example at all. It's also governed by a corporatocracy disguised as community project.

Weasel attitude is destructive, not constructive at all. If he do, he should code what's better instead whinning all time on forums and such.

APIs need to evolve. SDL uses compatibility layers to remedy this.

1. GTK and GNOME developers seem very happy about these respective projects despite the historical user uprising. Everything requiring a lot of effort will obviously require funding whether corporate or through donations. The Linux kernel is basically the largest corporate project you have and it has the same issues as GTK and GNOME. The end user has no say in what gets in and what gets out.
2. I don't know who this Weasel is, who you are, and what you two have together. It's none of my business
3. APIs can evolve without removing them. You can just break signatures and ABIs. People will adapt their code.

[ClosedSource]

Again, only remove APIs that you don't want anyone touching ever again for very good reasons. Otherwise, just break ABI and function signatures. Adding better_api() and removing older_api() is just lame. Just fix your API instead. Even if it breaks client code, people can always fix their code or use an older version of the library.
if I understand correctly, SDL split older_api() into a wrapper over better_api(). I don't condone this because it means developers will keep using older_api() and never port to better_api(). I don't know the games industry so I can't faily judge but what exactly is the reasoning here? Are there too many old closed source games requiring SDL1.2?

[billyswong]

Again, only remove APIs that you don't want anyone touching ever again for very good reasons. Otherwise, just break ABI and function signatures. Adding better_api() and removing older_api() is just lame. Just fix your API instead. Even if it breaks client code, people can always fix their code or use an older version of the library.
if I understand correctly, SDL split older_api() into a wrapper over better_api(). I don't condone this because it means developers will keep using older_api() and never port to better_api(). I don't know the games industry so I can't faily judge but what exactly is the reasoning here? Are there too many old closed source games requiring SDL1.2?

You are taking a mindset that every software should have and can have a developer or a team of developers forever maintaining them. This is false. Even in a parallel universe where every software are open source, I don't see where come the resources for programmers to port and debug each old games across API versions perpetually. And it is costly for one to make sure the ports don't introduce deviated game behaviour. It is far more economic to write this sdl12-compat once and for all.

[SingularityCat]

Before you get too excited about Trine, you're already better off playing the Enchanted Edition, which was a revamp based on the second game's engine, and that uses SDL 2.

The funny part is that Trine 2 itself uses the mythical SDL 1.3. It's the only game I know of that does. Still works well enough, although it does crash when fullscreen unless /usr/bin/gnome-screensaver-command is present. Gentoo patches this out to call /bin/true instead.

FWIW, I made a SDL 1.3 compat library specifically to get multi-monitor fullscreen on Wayland working well in Trine 2. It's a bit of a hack, but it worked last time I used it: https://github.com/SingularityCat/sdl1.3-compat

[arQon]

Not keen on getting into this, but:

[LIST=1][*]GTK and GNOME developers seem very happy about these respective projects despite the historical user uprising.

You're... agreeing with him here. You know that, right?

> The Linux kernel is basically the largest corporate project you have and it has the same issues as GTK and GNOME. The end user has no say in what gets in and what gets out.

Except that by "same issues" you actually meant "corporate ownership" only, and you're very wrong on even just that part. No *one* corporation owns the kernel - and because of that, bad decisions still have to get through maintainers who aren't being paid to eat your shit. That's very different from having a PM who can just say "I don't like having two windows at once: it confuses me. We shouldn't support that" and it happens.
Also very different, especially given the compatibility issues at the heart of (part of) this screed, is that the kernel never breaks userspace; but GNOME's *scripted* extensions can't even survive a single release.
So in reality there's basically nothing in common between your two examples other than "they're funded". If that was all you were trying to say, great - but I don't think it was.

>[*]APIs can evolve without removing them. You can just break signatures and ABIs. People will adapt their code.

On a practical basis, that gets very debatable very quickly. "Can" is the word there, not "should", and you don't get to to do it often unless your downstream isn't actually professional developers.