Upgrade to SDL3 #578

[kanthoney]

Upgrade to SDL3 #578

This pretty much works on my machine, so I figure it's close enough to ready to be tested on a wider range of setups.

I haven't been able to resolve the Linux/Wayland splash screen problem where the game screen ends up largely off screen due to Wayland not allowing programatic window placement, so we'll have to continue with the separate splash screen program work around for now.

On Windows, Oolite starts with the window underneath the command prompt I'm launching from - I'm not sure what's causing that.

[phkb]

It does! Why would it be different running the app from Explorer?

[mcarans]

It does! Why would it be different running the app from Explorer?

I'm guessing a missing dll.

This is a busy week for me - I hope to look at this PR in the weekend.

[kanthoney]

I wondered whether something still required the old SDL dll. But it's not listed when I run ldd oolite.exe and copying it manually into oolite.app didn't resolve things, so I guess it's not that.

[mcarans]

Compiling on Linux, I got this error:

Compiling file src/SDL/MyOpenGLView.m ...
src/SDL/MyOpenGLView.m:1717:6: error: call to undeclared function 'SDL_SavePNG'; ISO C99 and later do not support implicit function declarations [-Wimplicit-function-declaration]
 1717 |         if(!SDL_SavePNG(tmpSurface, [pathToPic UTF8String]))
      |             ^
src/SDL/MyOpenGLView.m:1717:6: note: did you mean 'SDL_SaveBMP'?
/usr/include/SDL3/SDL_surface.h:576:34: note: 'SDL_SaveBMP' declared here
  576 | extern SDL_DECLSPEC bool SDLCALL SDL_SaveBMP(SDL_Surface *surface, const char *file);
      |                                  ^

I read that SDL_SavePNG is not in the core SDL3 library so I installed:

sudo apt install libsdl3-image-dev

However, it still failed. I then tried adding the include and lib:

#include <SDL3_image/SDL_image.h>

 -lSDL3_image

However, it still didn't build successfully.

[mcarans]

Now got it to build, run, make png snapshot and fly around with:

MyOpenGLView.h:

#include <SDL3/SDL.h>
#include <SDL3_image/SDL_image.h>
#define SDL_SavePNG(surface, path) IMG_SavePNG(surface, path)

and

GNUmakefile:

    ADDITIONAL_OBJC_LIBS         += -lGLU -lGL -lX11 `pkg-config sdl3-image --libs` -lgnustep-base -l$(LIBJS) -lopenal -lz -lvorbisfile -lpng `nspr-config --libs` -lstdc++
    ADDITIONAL_OBJCFLAGS         += -DLINUX -DXP_UNIX `pkg-config sdl3-image --cflags`
    ADDITIONAL_CFLAGS            += -DLINUX `pkg-config sdl3-image --cflags`

Great work @kanthoney !

NB: It's better to rename all the SDL_SavePNG to IMG_SavePNG unless Windows specifically expects the former.

[kanthoney]

That's weird. It compiles fine on my Fedora laptop.

The documentation says the SDL_SavePNG function is in SDL3/SDL_surface.h. What happens if you include that header file instead?

[kanthoney]

It turns out the SDL_SavePNG function was added in version 3.4, and some distros (e.g. Debian) are still on 3.2

[mcarans]

I'll see if I can build 3.4 from source then. Actually probably better I just upgrade to 26.04LTS which has 3.4.

[mcarans]

I've made a PR to the kja_sdl3 branch: #643

sdl-config is a SDL1.2 command so build flags need updating. I've taken the opportunity to clean them up for Linux. A similar fix is needed for Windows (and flag cleanup is desirable too).

ADDITIONAL_CFLAGS are automatically added to C++ flags but not ObjC flags so some flags are superfluous.

[kanthoney]

I've merged the pull request, and tidied up the Windows build a little bit. Somebody with more Windows/MSYS2 knowledge than me should have a proper look at it, and also try to find out why it's not running from outside the MSYS2 environment.

[kanthoney]

It seems that the reason for the startup crash in Windows when run outside the MSYS2 environment is that the SDL_getenv function is case sensitive in SDL3. Under MSYS2, the variable is PATH and works fine, whereas for Windows it's Path, so Oolite can't find the path in the main function and crashes. I guess I'll try one and if that doesn't work try the other.

[phkb]

OK, latest patch allows the app to be run generally. I build the app and copied the results over an existing installation that has a full set of OXP's installed (both in AddOns and ManagedAddOns), and an existing OoliteDefaults.plist in the default location. A couple of things I noticed:

1. The default log file location has changed from "C:\Oolite\oolite.app\Logs" to "C:\Users\{username}\Logs"
2. The default location for ManagedAddons has changed from "C:\Oolite\oolite.app\GNUstep\Library\ApplicationSupport\Oolite\ManagedAddOns" to "C:\Users\{username}\GNUstep\Library\ApplicationSupport\Oolite\ManagedAddOns", even when the original folder was present and populated with OXZ files.
3. The default location for "OoliteDefaults.plist" has changed from "C:\Oolite\oolite.app\GNUstep\Defaults" to "C:\Users\{username}\GNUstep\Defaults", even when an existing file was present in the original location.

I'm assuming these defaults can be tweaked in OoliteDefaults.plist, but if the defaults file itself in now centralised, how can we have different setups for different installations?

[kanthoney]

@phkb the problem with default locations should be fixed with the latest push

[oocube]

I'm assuming these defaults can be tweaked in OoliteDefaults.plist, but if the defaults file itself in now centralised, how can we have different setups for different installations?

Take a look at https://bb.oolite.space/viewtopic.php?p=305556#p305556, which redirects to https://oolite.readthedocs.io/en/latest/. There are environment variables documented - I am just not sure what OS they apply to.

[phkb]

Not sure what's going on, but...
YouTube Flickering textures in 1.93 sdl3 build

In the linked YouTube video, I've used the Test Ship Model oxp and selected one of the Generation Ships, generation-ship-1 specifically. I haven't zoomed in or out or moved the model in any way yet. I have just opened the Test Ship Model screen, and entered generation-ship-1. For some reason the texture along the frame is flickering. Zooming in and out alternatively stops and restarts the flickering.

Generation ships are using the default shaders, with diffuse, normal, specular and illumination maps. I'll experiment with various combinations of these to see if any particular map is the culprit. This is also with my (rather large) suite of OXP's installed. I've run a test with just the Generation ships and the Test Ship Model OXP's and the flickering is the same.

[kanthoney]

Looks like the flickering is also in master, and was introduced when #153 was merged. I'll investigate but it's nothing to do with this PR

[kanthoney]

@phkb I've opened a separate issue for the flickering issue (#646)

[mcarans]

FYI I've spent some time trying to get the test to work with an Ubuntu 26.04 container (long list of failed attempts here: https://github.com/mcarans/oolite/actions). GitHub is currently still on 24.04 so like Fedora and Arch, a container must be used, but something is different about it compared to running locally on Kubuntu 26.04 where the test works.