VOGONS


Reply 20 of 26, by digger

User metadata
Rank Oldbie
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?

Reply 21 of 26, by leileilol

User metadata
Rank l33t++
Rank
l33t++

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.

apsosig.png
long live PCem

Reply 22 of 26, by digger

User metadata
Rank Oldbie
Rank
Oldbie
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.

Reply 23 of 26, by LightStruk

User metadata
Rank Member
Rank
Member
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.

Reply 24 of 26, by Jo22

User metadata
Rank l33t++
Rank
l33t++

+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//

Reply 25 of 26, by hail-to-the-ryzen

User metadata
Rank Member
Rank
Member

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.

Reply 26 of 26, by ViTi95

User metadata
Rank Member
Rank
Member

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.