Do we need an SDL3 port?

[GitMensch]

While that isn't out yet, at least the header folder changed, so the SDL2 port can likely not be taken "as is".

For more details see the repo at https://github.com/libsdl-org/SDL_ttf

[Bill-Gray]

I've seen occasional references to SDL3 in recent months, but haven't investigated.

If the changes are as minor as changing header folders, we should get by with a -DUSE_SDL3 switch rather than making another port with essentially identical code. (There is already a lot of overlap between SDL1 and SDL2... I've thoughts of moving bits and bobs to the common directory. VT and the framebuffer/DRM ports have lots of overlap, too, and you'll see that I was able to avoid code duplication for the most part.)

[GitMensch]

There is already a lot of overlap between SDL1 and SDL2... I've thoughts of moving bits and bobs to the common directory.

I totally agree that this would be a good idea, should we move that out to a separate issue?

[Bill-Gray]

I'm only reluctant to bring it up as a separate issue because it's likely to at least be some time before it leaves the 'thinking about it' stage. I would do it to make the code easier to maintain; I can't think of any way in which it would add functionality or fix anything.

The most likely motivator for it would be a fix to SDLn (or extension to SDL3) where we say to ourselves : this bit of code needs adjustment in two places; let's pull it into the common directory and fix it once. So I'm not in a great rush to do it.

On a similar level, we have code to read in PSF and some other bitmapped fonts in both the DOSVGA and Linux framebuffer/DRM ports. Ideally, those would be pulled out and put into common to form a bitmapped font subsystem, and that subsystem would then replace the current bizarre font format for SDL1 and SDL2 "narrow" (8-bit character) builds, where the "font" is stored as a Windows .BMP file. That would do a lot more to simplify the code, and would actually add some capabilities in all four platforms (and mean we would have one set of bitmapped font routines instead of three; the DOSVGA and framebuffer/DRM ports have different ways of handling PSF, which in turn bear no real relationship at all to the SDLn .BMP-formatted fonts.)

But again... while it's been in my mind for a while now, basically since I wrote the framebuffer/DRM port, I've obviously not been rushing to actually do it.

[finchco]

Hey all!

I've been working locally on an SDL3 port (based on the SDL2 folder) but from the original PDCurses repo. Oops.

I'm gonna diff /SDL2 from PDCursesMod against the og folder and see how bad it's gonna be.

[GitMensch]

@finchco can you have a look at moving pieces common in the sdl ports to the common subdirectory as well?

[Bill-Gray]

@finchco Glad you came across this repo!

I very much agree with @GitMensch that it'd be great to put the "in common" bits of SDL1, 2, and (when available) 3 into the common folder. There's a lot of redundancy between SDL1 and 2 at present (as discussed above).

But I wouldn't suggest that you worry much about that at present. I have not tackled SDL3 at all yet, am unlikely to do so soon, and haven't heard of anybody working on it. (I'm not all that knowledgeable about the SDL ports; they were mostly done by others before and after the fork from PDCurses.)

So if you get something that works, we'll probably thank you, merge it, and then go back and figure out what needs to be pulled out from the (now three) SDL versions into the common directory.

I get the vague impression, based on what little I know of SDL3, that it's not all that different from SDL2. (Is that what you're seeing?) I retain the hope, as expressed above, that the differences can be handled by #ifdef USE_SDL3 switches, probably resulting in the sdl2 port being renamed to sdl2and3. But I'm prepared to learn that things won't be quite so easy.