SDL3 port

[jaydg]

I also worked on a SDL3 port a while ago and recently got to finish it.
The demos all seem to work as expected.

I do not use MSVC and only mechanically translated the Makefile for that. That really needs some checking.

Closes #271

[GitMensch]

Thanks for taking the time to create this PR and sharing your code under public domain!

The most important question here is the one in the originating issue: Do we need an SDL3 port at all - or is the code similar enough to SDL2 (= where does it differ?). A very rough look at README.md didn't answer that question for me.

[Bill-Gray]

I second @GitMensch's thanks. I'm quite happy to see this; you probably noticed the issue in question started 3.5 years ago.

I'm currently up over my eyeballs in $WORK, and probably will be for at least a week... looking forward to playing with this, though!

[jaydg]

Here's the diff between the two directories. I must say, the SDL3 developers did a great job touching almost every API this project uses :) Especially input handling is quite different, so working with #if #elif #end blocks would make the code very ugly!

To reduce the amount of code I'd propose to drop SDL1 support. That library is really dead (last release 2013) and most likely doesn't even compile anymore.

sdl2_vs_sdl3.patch

[GitMensch]

SDL1 is useful for old environments - where you may not even have SDL2 in the first place... after all we support DOS ;-)
Is there any reason that you've dropped vt0?

[jaydg]

Err, I think I've started the port before that was added? I cannot remember touching it.

[Bill-Gray]

I see what you mean about it being a "significant" difference. There are some other differences caused by divergence after you started the fork (the vt0 terminal emulator pointed out by @GitMensch , the revised handling of blinking in commit f6657a3, a couple of others... nothing that can't be fixed with minimal effort, though.)

If nobody has an objection/suggestion for improvements, I'll pull this "as is", then make suitable changes to bring it into alignment with what's happened recently in SDL2.

After that, the SDL2 vs. SDL3 diff will be much smaller, and I might return to the possibility of seeing if we can make the difference just a matter of #ifdefs... ask me again after we've got them in sync. We now have lots of redundancy between SDL1, SDL2, SDL3, and OpenGL. At the very least, I'd like for them all to use the "common" mouse logic found in common/mouse.c; that makes debugging "bad" mouse behavior immensely less painful.

Re SDL1.2 : yes, we support old and unusual environments. But DOS is covered by the DOS and DOSVGA ports, and OS/2 by both a console and a GUI port. Losing SDL1 for those would not (I think) be a major inconvenience. But more likely, we'd only attempt to combine SDLs 2 and 3 and OpenGL, where the differences are less different, leaving SDL1 "as is".

[GitMensch]

Sounds all reasonable to me (get in, adjust recent SDL2->SDL3, try to move parts out to common for the code that is only relevant to the three non-archaic SDLs)!

[jaydg]

I think I can find time the next days to add the changes I missed to the SDL3 version.

When the SDL3 version is totally up to date and the delta between is exclusively the modified SDL APIs I'd day it would even be possible to separate the APIs with ifdefs.

I wouldn't be of any help though with figuring out whether to use SDL3 or SDL2 in the CMake files. I hardly managed to adapt the beast!