Time to go SDL2?

[Stoddard]

SDL2 is pretty much stable at this point. SDL1.2 is on the other hand pretty much obsolete. Staying on it hampers stuff like more mouse bindings, and I think the android port will have a bit more opportunity to gain traction if SDL1.2 stuff goes out of the way.

Problem is, this has to go bottom-up from upstream. I volunteer to present an as clean as humanly possible OXC SDL2 port, so that the changes can then be most painleslly merged downstream.

What do you think?

[Meridian]

What do you think?

I support it, but there's really only 2 people whose opinions matter in such cases.

I suggest to log in to IRC and ask SupSuper and Warboy directly.

[Yankes]

I support it, but there's really only 2 people whose opinions matter in such cases.

I suggest to log in to IRC and ask SupSuper and Warboy directly.

Changing this in master is good idea, but otherwise we could at least update it in our branch only.

[SupSuper]

I probably wanna get OX2.0 out before switching engines, so people that need SDL 1.2 have something to grab onto. It may be "obsolete", but it's still the prime choice for low-end/homebrew hardware. Users aren't really concerned that the backend is "better", they just care that it works.

Anyways sfalexrog has already made a SDL2 port, no need to start from scratch: https://github.com/sfalexrog/OpenXcom/tree/sdl2
I don't know if all the SDL1.2 features made it though, and it relies on weird things like dependency patches and a custom port of SDL_gfx.

[yrizoud]

SDL2 is pretty much stable at this point.

Of course they urge everybody to try SDL2, so that all bugs get discovered; but from my own experience it is really not as stable and feature-complete as SDL1.
Note that they reorganized all key codes (SDLK_*), so any configuration file with keyboard shortcuts can't be converted.

[Stoddard]

I'm sorry, where exactly SDL2.0 as of today lacks features compared to SDL1.2 ?

It's not like I didn't take a part in ensuring the exactly opposite, and that all my personal woes (most due to obscure OpenGL corners) weren't fixed long ago.

It is completely another case that SupSuper mentions, that SDL2 lacks support for some platforms compared to SDL1.2.

I  have completely different experience, in that the need for support of various obscure (IOS, Android at the time) platforms was in fact the driving force for the development and eventual release of SDL2, and thus is sounds a bit strange that there are platforms supported by SDL1.2 but not by SDL2 that are at the same time relevant to the OpenXcom.

But I might have missed some, this subject I did not really track.

I don't deny existence of proprietary forks of SDL1.2, which, theoretically, OpenXCom could be linked against, but should we really descend into this?

I apologize if I came over too harsh or confrontative here.

EDIT:
Yep, if someone relied upon SDLK's not changing, tough luck. They were thought of designed about 15 years ago.

[yrizoud]

SDL1 gave an incredible cross-platformness to a program which I used to develop. It got compiled on Linux and Windows, Haiku , AmigaOS 3, MorphOS, Mac OS X, FreeBSD, SkyOS, Atari MiNT (Running on Atari Falcon!), even the GP2X and Caanoo handheld consoles. I suspect the SDL2 version is certainly not as mature on these platforms (I got confirmation for the Haiku one - and my own experience with the Windows one is painful)

SDL2 basically removes the support of 256-color logical screen "automatically" converted on a high-color screen/window. I've tried several implementations, but none of mine is as fast as what SDL1 was able to do. Thankfully, this doesn't seem to be what OpenXcom requires, otherwise the person who has already tried a port would have seen a big problem, long ago.

I'm bitter after wasting a lot of times troubleshooting, before finding out that a 6-month old stable 2.0.3 had a 100% systematic crash on SDL_FillRect, fixed in the sources repository though no changelog / bugtracker item reported it.

The missing feature which is a roadblock in my case is the support of resizing windows (when user drags window edge or uses maximize/restore icon). The SDL1 version worked perfectly, the SDL2 version destroys the DirectX context, and doesn't even give me any choice or moment to re-allocate and redraw the textures.

[winterheart]

Hello.

I think main reason to move on SDL2 is better support of new platforms such as Android and iOS. AFAIK, sfalexrog did fork for this reason - to bring OpenXcom to Android. Still, SDL1 have more support for old and legacy platforms, where SDL2 not even ported yet.

But we can support both versions and define which one to use during configuration and compilation time. There are plenty projects that come this way: ScummVM, et-legacy, QEMU.