Oolite is still on SDL 1.2

[alugarius]

I want SDL2!
I play Pioneer instead of Oolite because of this.

[sjnewbury]

I'm thinking I'll take look into porting to SDL2.

In #91 it was mentioned there are local changes to the in-tree binary libSDL-1.2, the Gentoo ebuild produces an Oolite binary linked to the system libSDL-1.2.so, maybe that explains the fullscreen vblank sync and performance issues with my build... nope it seems not. Is there any more information on what changes have been made to the in-tree version?

[AnotherCommander]

@sjnewbury Yes. All modifications to the standard libraries are listed here:
https://github.com/OoliteProject/oolite/blob/master/Doc/ExternalLibrariesSourceCodeChanges.txt

[sjnewbury]

I've made a start. Initially I'm just doing the bare minimum to get it working with the same functionality. Later new features and capabilities are possible such as multiple screens OpenGL3/4 core profiles etc.

I don't know if the Windows changes noted above are still necessary with SDL2. I'll create a pull request once I've tested it here on Linux, hopefully somebody with a Windows build setup can test it.

[sjnewbury]

Some thoughts while working on this:

Splash screen could/(should?) be a separate window - I'm leaving the code as is at this stage for minimal invasiveness.

A lot of special casing for Windows is probably not necessary with SDL2. I've removed some, but not all of this code. It will need testing. Probably most of it can be dropped.

There is a lot of code handling screen modes, I'm dropping it all on the floor. The API has improved for SDL2 here and I don't think any of it is needed. Unless I'm missing something...

"Surfaces" are a "compatible" feature with SDL2, to use GL you just need to create a GL context, so I've replaced "surface" with "glContext" thoughout, with the exception of the screenshot handling code, where I'm specifically creating a surface from the window for that function. Hopefully, that will let me get away with leaving all that code alone.

HiDPI support should work on all supported platforms now, but I can't test it. I'm trying not to break it!

[sjnewbury]

I left in the screen mode support largely as is for now. As I mentioned, I just want to alter as little as possible.

I've got the game running with "-nosplash". Obviously buggy, since without "-nosplash" the window fails to appear on screen although it shows up in the window list.

I've still got some of the code I added to replace the screen mode handling which I guess I will revert before creating the (provisional - for testing) pull request.

Good news, fullscreen is now fast and smooth for me.

[sjnewbury]

I am tempted to rip out and replace the splash screen code with a separate window.

[sjnewbury]

@AnotherCommander: Since the splash code has broken I've just ripped it out and left stubs. Perhaps I should copy the SDL directory to SDL2 before making the the pull request and make it a build time option? Preferences? It is working better for me than the SDL1 code in fullscreen. There is still too much code, on the other hand what I have now is working.

I'm also wondering about the fullscreen mode switching generally, do we really want to switch resolutions rather than always use native? I did try to implement the fullscreen mode switch using the viewSize like on Windows but I've now dropped that code for simplicity. It is however mode switching when leaving the game to the desktop (since task switching works with fullscreen SDL2, along with volume controls!) and then still uses that low resolution on return since it's then the desktop resolution!

[AnotherCommander]

@sjnewbury First of all, many thanks for the effort you are putting into this. It is much appreciated.

The SDL2 code should definitely be inserted initially as a compile-time option. Whatever changes you are proposing, we should still be able to build the game using the current SDL. As I am sure you are aware, the transition to SDL2 is not a simple task and is, in fact, very invasive, considering the stability we have managed to achieve to this point. It is changing the functionality of the game at low-level. As a consequence, some very heavy and detailed testing will be required and this could take long, even months, depending on the availability of people and test systems. So it is necessary that, until we are happy with the status of the SDL2 port, we keep the current SDL tree unning in a totally unaffected manner.

Regarding dropped features and stub functions: I would not agree with dropping existing features. The fullscreen mode changes may not seem of much use these days, but keep in mind that we are targeting also older machines and those may need the alternative modes for performance reasons. In any case, I would rather not have to pay the price of leaving behind existing features in favor of SDL2. If features do have to be dropped, then we'll have to have internal discussions about how we want to proceed. This is another reason why the existing SDL should remain alive until we are satisfied that the transition will be as transparent as possible.

While we are at that, please test also joystick input. This is very important, almost critical I would say. Joysticks, controllers etc. must continue to function exactly as before, on all platforms. Also, multi-monitor support will have to be tested as well to ensure that it works on Linux or, at the very least, that it does not break the Windows port.

Speaking of which, we'll have to see how to go about testing in Windows once the PR has been submitted. For the Windows port, all support libraries are built by ourselves; we do not use pre-built binaries and this is so that we are able to control any and all aspects of the game's code (we've already had to do plenty of editing into support libraries code, including gcc code in one extreme case - I can provide details if you want, but I'd rather forget about that torture :-)). So, SDL2 will have to be built for Windows, the Windows Dev Environment updated, then proceed with testing as time permits. I can tell you right now that this is going to take a while. I prefer putting time into the game's code rather than into its libraries and time is in short supply. I also don't have ability to test on a 64-bit system currently, so we'll have to see how we'll go about that too.

And last but not least, even the Limux builds we provide may have to change the way they are generated, if SDL2 moves on. I'll let the details of this to our Linux experts, but be aware that the Linux builds we provide are completely independnet of distros and libraries provided by such distros.

In summary, this is a subject that will probably not be resolved immmediately. We'll have to take time with it, test it thoroughly - and I mean that - and proceed only if we are all confident that the change is not causing more issues than it resolves and that the game is still as stable as we expect it to be. Looking forward to the first iteration of the PR when you have it ready.

Thanks again for your work on this.

[sjnewbury]

I'm going to create a pull request with what I have now.

Outstanding issues::

1. Splash screen doesn't work so I have removed the code for now except the switch/config settings.

2. Fullscreen mode switching isn't now supported by the Linux code. Hopefully, the Windows code still works.

3. Initially when going fullscreen there is odd flickering. Switching back and forth "fixes" it. Not sure why. It then works well.

Joystick, mouse, keyboard, sound all seem to be working.

[sjnewbury]

@AnotherCommander, thanks for the feedback. I'll split the SDL directory into an SDL2 directory with the changed files, and make it build time selectable before making the PR.

I'll see if I can get the splash screen going again as well, I was just spending too much time on it earlier today it's going to take a clean approach, I think.

[snipped]

The preferred SDL2 method is actually to always use the native resolution for display and use internal scaling from a lower resolution since not all SDL2 targets support mode switching, for example, native Wayland should be working as is. Android and iphone could work to.

[sjnewbury]

#234

[sjnewbury]

I just tested it under Weston. It works, it's buttery smooth, but it shows some issues with window resizing especially when switching to fullscreen.

[sjnewbury]

@AnotherCommander Many issues addressed. Mode switching works again. The code is back in place for the splash screen, but it isn't quite working due to a problem with the OpenGL bounds/offsets I think. The image often appears shifted down out of the view window. As I mentioned, I tested it under native Wayland (no X server at all), and it works fine. I think the flickering might well be related to the above mentioned OpenGL issues, and is probably due to my lack of experience/knowledge in that area, I'm working on it, but help would be really appreciated. This really clearly shows up when going up screen resolutions in fullscreen mode!

[sjnewbury]

One thing about the mode switching, SDL2 supports refresh rate, so that really needs to be supported properly, where currently it's only partial.

[sjnewbury]

Multi-monitor support is limited to only using the first display, that's where the mode list comes from. SDL2 isn't limited in that regard, and supports multiple windows and displays, it could in theory display a window for each Oolite game screen simultaneously and/or map them to multiple displays when fullscreen. That would be pretty cool IMHO.