Reply 20 of 26, by digger
- Rank
- Oldbie
Wouldn't it make more sense to spend those efforts on backporting SDL2 to those older platforms instead of keeping SDL 1.x alive? Are there any technical reasons why that would be infeasible?
Wouldn't it make more sense to spend those efforts on backporting SDL2 to those older platforms instead of keeping SDL 1.x alive? Are there any technical reasons why that would be infeasible?
I'd think SDL2's design for absolute 3d accelerated surfaces on any video output gatekeeps older video cards, and that's before going into possible 'modern code' vs. old gcc politics.
leileilol wrote on 2022-02-25, 23:33:I'd think SDL2's design for absolute 3d accelerated surfaces on any video output gatekeeps older video cards, and that's before going into possible 'modern code' vs. old gcc politics.
It should still be possible to implement SDL2's API on older hardware, since not all of the graphics API pertains to 3D animation. And such an implementation could also be written using "old style" C /C++ code. And even if more modern code were used, that should still not necessarily be a problem, as long as you could still link it with the upstream DOSBox code base and other such projects that make use of older development toolchains.
Yes, I understand that it would become a separate project from upstream SDL2 at that point ("SDL 2 Legacy"?), but it would serve the same purpose: the ability to target the SDL2 API without losing compatibility with older hardware and older operating systems.
Although I absolutely don't want to belittle the effort required for this, this still makes a lot more sense to me than keeping SDL1 on life support.
digger wrote on 2022-02-25, 22:33:Wouldn't it make more sense to spend those efforts on backporting SDL2 to those older platforms instead of keeping SDL 1.x alive? Are there any technical reasons why that would be infeasible?
Keeping SDL 1.x alive has value for the same reasons I was advocating not ripping libSDL 1.x out of DosBox. If SDL starts working on a new platform, then hundreds or thousands of applications have the potential to work there. Bringing SDL 2.x to another platform has value for that reason, obviously, but it doesn't magically update existing SDL 1.x applications to the 2.x API.
+1
In German, ironically, there's a saying..: Nichts hält länger als ein Provisorium
Which translates to "Nothing is more permanent than a temporary solution."
The French people may know it as "Rien ne dure que le provisoire."
It's about the paradox, that quick&dirty solutions made in a crisis sometimes
last very long or even longer than the "real thing".
Just think of DOS, XP or a temporary tooth fill.
Because, these solutions ("things") weren't planned that way, rather, they are lively, evolving, adopting to new situations each times.
That's why these hacky solutions last so incredible long. They are open-ended, they outlive their creators sometimes.
"Time, it seems, doesn't flow. For some it's fast, for some it's slow.
In what to one race is no time at all, another race can rise and fall..." - The Minstrel
//My video channel//
https://github.com/libsdl-org/sdl12-compat
From the readme:
This code is a compatibility layer; it provides a binary and source compatible API for programs written against SDL 1.2, but it uses SDL 2.0 behind the scenes.
Also porting SDL 1.x code to SDL 2.0 isn't that hard, I've done it for the SDL1 port of Clanbomber2 and it wasn't much code to change at all. And the benefits were incredible, hardware acceleration made it go much faster.