HDR, haptic on SDL3 Win+Linux

[mcarans]

I was curious about the state of HDR and haptic feedback on Linux and it turns out it is now possible with SDL3. The good news is that SDL3 already works with Oolite via compatibility layers.

"For HDR to work properly, you'll need:

A Wayland compositor with color management protocol support (KDE Plasma 6+, GNOME 48+, or Sway with proper configuration)
An HDR-capable display
Recent Mesa drivers (25.1+) or appropriate GPU drivers
SDL 3.2.6 or newer"

"haptic feedback is possible in Linux using SDL3! SDL3 has a full haptic subsystem that supports force feedback on Linux."

On Linux, SDL3 can already be used with Oolite albeit using compatibility layers that go from 1.2 -> 2 and from 2 -> 3. In fact, this is the default setup on Flatpak, Fedora and Arch (while Ubuntu uses SDL2 via 1.2 -> 2).

Windows uses a custom build of SDL1.2. As far as I can tell, the features added to SDL1.2 for Windows are some video changes presumably for HDR and haptic feedback for joysticks. These would need to be reimplemented in SDL3. Have I missed any other features added to SDL1.2?

The upgrade path to SDL3 could be simplified by taking calls to SDL3 via compatibility layers and porting them to go direct to SDL3. This could be done a few calls at a time maintaining a working build (ie. some calls go through compatibility layer, some direct with Oolite still running correctly). When the appropriate calls have been ported, HDR and haptic feedback could be added such that they work on both Windows and Linux (and in future MacOS). Thoughts?

[another_commander]

Windows uses a custom build of SDL1.2. As far as I can tell, the features added to SDL1.2 for Windows are some video changes presumably for HDR and haptic feedback for joysticks. These would need to be reimplemented in SDL3. Have I missed any other features added to SDL1.2?

There is also an improved mousewheel handling implementation and a small fix when resizing the game window.

The upgrade path to SDL3 could be simplified by taking calls to SDL3 via compatibility layers and porting them to go direct to SDL3. This could be done a few calls at a time maintaining a working build (ie. some calls go through compatibility layer, some direct with Oolite still running correctly). When the appropriate calls have been ported, HDR and haptic feedback could be added such that they work on both Windows and Linux (and in future MacOS). Thoughts?

The strategy sounds doable, but I will have to let someone else carry it out on Windows. This project, as described, is long-term and I am not sure I have this kind of time to dedicate. I sure hope SDL3 is in much better shape than SDL2 when I had a look at it a few years ago.

[Lone_Wolf]

Is this an intended change for 1.92 or for 1.93+ ?

As for HDR :
Are there parts of oolite or extensions that benefit from the larger color space provided by HDR monitors ?

[another_commander]

Is this an intended change for 1.92 or for 1.93+ ?

My understanding is post-1.92, otherwise 1.92 will take (more) months or years to arrive.

As for HDR :
Are there parts of oolite or extensions that benefit from the larger color space provided by HDR monitors ?

Yes. The overall image quality is so much better that it is actually very difficult to get back to SDR. If I run the game in HDR and immediately re-run it in SDR I am left wondering how on earth I was playing in SDR all these years. It's tricky to explain, you just have to experience it.

Edit to add: Here is a pic of Oolite using "extended" color spaces while in HDR (of course this is an SDR image so you won't be able to experience them, but they are there):

[mcarans]

Is this an intended change for 1.92 or for 1.93+ ?

As for HDR :
Are there parts of oolite or extensions that benefit from the larger color space provided by HDR monitors ?

I think the priority should be to get a 1.92 build released as as soon as is reasonably possible to hopefully spark interest in Oolite particularly if the game is available on the MS Store and Flathub, although releasing on the stores could come some time after releasing on GitHub. This requires on my side completing the Windows modern build in GitHub Actions.

SDL3 would not be for 1.92. I think 1.92 will consist of releasing the modern build on Windows and Linux (in itself a significant milestone given all the changes).

After 1.92, then first change I have in mind is the reformatting of code to modern standards which will make coding much easier as I've found it troublesome matching the indenting in my UI's editor.

I'm also considering finishing the CMake work I got quite far with although still debating if Meson might be better for the future as it is much faster and already used by projects like GNOME, systemd and Mesa. Meson is faster and simpler than CMake with a Python like rather than completely custom syntax.

Meson has what I think is the right philosophy of encouraging shell scripting to be in separate scripts not embedded into the build system. (The recently merged PR already moved a chunk of shell scripting for generating versions out of Makefile as it was needed in the Flatpak build and also duplicated in the GitHub Actions workflow.)

Apparently, including GNUstep libraries in Meson is straightforward because Meson has built-in support for Objective-C and the dependency() function works seamlessly with gnustep-config. Although I got GNUstep to work in CMake, it was with a module I found on the web in just one project.

Looking at SDL3 and JavaScript libraries would be for later.

[mcarans]

I found that the way sdl12compat and sdl2compat work is that they load dynamically so that there aren't symbol clashes, so a call by call port is not straightforward. One way could be to make an Oolite specific sdl12compat that gradually morphs from sdl12compat to sdl13compat (cutting out sdl2compat) and then to SDL3. Another could be dynamically loading SDL3 in Oolite, gradually switching to the dynamically loaded functions instead of SDL 1.2 ones.

While these approaches might work, they might in the end be harder than just moving to SDL3 in Oolite itself. There is a migration guide on how to go from SDL 1.2 direct to 3: https://wiki.libsdl.org/SDL3/SDL12MigrationGuide

On HDR, AI suggests this which sounds like a possible shortcut to HDR support:
"SDL3 has a specific API for this (SDL_SetWindowSurfaceColorspace)...you can use dlopen to access these SDL3 functions and enable HDR on your window, even if the rest of the game is written in SDL 1.2"

EDIT: Turns out that dynamic calling has been made easy by a jumptable so maybe function by function porting is reasonable after all. Calls would be gradually ported using the jumptable and once completed, could be changed to direct calls to SDL3. Here is enabling HDR when using sdlcompat12, sdlcompat2 and SDL3 according to AI (after which outputting actual HDR data would be needed in code or via ReShade on Windows or Gamescope on Linux):

Code: Select all

// Define the structure of the jumptable
typedef struct SDL_DYNAPI_table {
    #define SDL_DYNAPI_PROC(rc,fn,params,args,ret) rc (SDLCALL *fn) params;
    #include "SDL_dynapi_procs.h" // You get this from the SDL3 source code
    #undef SDL_DYNAPI_PROC
} SDL_DYNAPI_table;

static SDL_DYNAPI_table sdl3_table;

typedef Sint32 (SDLCALL *SDL_DYNAPI_ENTRY_FUNC)(Uint32 apiver, void *table, Uint32 tablesize);

void InitializeSDL3Jumptable() {
    void *handle = dlopen("libSDL3.so.0", RTLD_LAZY);
    SDL_DYNAPI_ENTRY_FUNC dynapi_entry = (SDL_DYNAPI_ENTRY_FUNC)dlsym(handle, "SDL_DYNAPI_entry");

    if (dynapi_entry) {
        // 1 is currently the only valid version
        // We pass our table and its size; SDL3 will fill it up.
        if (dynapi_entry(1, &sdl3_table, sizeof(sdl3_table)) != 0) {
            // Error: Table size mismatch or version incompatible
        }
    }
}

/* In your sdl3_bridge.c (which sees SDL3 headers) */
#include <SDL3/SDL.h>

bool SDL3_EnableHDR(void *sdl12_window_ptr) {
    // 1. Cast the generic pointer to an SDL_Window
    SDL_Window *window = (SDL_Window *)sdl12_window_ptr;

    // 2. Set the HDR property on the window
    // This tells the backend to allow high-bit-depth buffers
    SDL_PropertiesID props = sdl3_table.SDL_GetWindowProperties(window);
    sdl3_table.SDL_SetNumberProperty(props, SDL_PROP_WINDOW_CREATE_HIGH_PIXEL_DENSITY_BOOLEAN, true);

    // 3. Set the Colorspace
    // SDL_COLORSPACE_SRGB_LINEAR is common for HDR (scRGB)
    // SDL_COLORSPACE_HDR10 is used for 10-bit ST2048
    if (!sdl3_table.SDL_SetWindowSurfaceColorspace(window, SDL_COLORSPACE_SRGB_LINEAR)) {
        // Log error via sdl3_table.SDL_GetError()
        return false;
    }

    return true;
}