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.

[oocube]

Strange. While the first three startups of the game were distorted as above (it took me that long to make the screenshots), I ran it again to see whether in combat you also need to aim elsewhere. And all of a sudden the complete behaviour is normal again. Not sure where the effect came from but I cannot reproduce it.

[mcarans]

Guess we're good to merge then?

[mcarans]

@kanthoney Please go ahead with merge if you're ready

[kanthoney]

@phkb Can you check something for me with the non-US keyboards? I think SDL3 just knows what keyboard layout you're using so I don't think the keyboard layout setting in game options is doing anything any more. If it's not doing anything I might as well remove that option

[oocube]

I have an international keyboard with german layout. It looks pretty much like this one:
https://en.wikipedia.org/wiki/German_keyboard_layout#General_information

With oolite_dev-1.93.1-PullRequest620.174-x86_64.AppImage I went to the keyboard settings and assigned the 'y' key to a function. It was properly acknowledged as 'y' on the screen. Then I assigned '#' to the same function. Again that was properly acknowledged as '#' on the screen. In the game I could use the function with that key.

Any specific test that you are after?

[kanthoney]

What I want to know is, if you change this setting to, say, Greek, does it have any effect or does it still think the keyboard is German? I think it'll still think the keyboarrd is German, in which case I can safely remove the setting altogether

[oocube]

Oh, I overlooked the first line. My german keyboard first of all is detected as Default (US).

Then I switched to german keyboard and checked for some function on e.g. # and Shift+Z.

But although the configuration shows to use # and Shift-Z to zoom and unzoom, I had to use # and Shift-Y.
So something is still fishy.

[oocube]

Comparison to oolite_dev-1.93.1-70-x86_64.AppImage:

I can zoom correctly using the indicated keys. So this PR introduces the fishy behaviour. Do not take any offense. The PR is massive, and almost everything works. :-)

[mcarans]

@oocube What happens if you change your keyboard setting in the OS - does Oolite use the correct keys?

If I understand correctly, the behaviour change you see is expected: with SDL3, the "Current keyboard layout" setting in the game is no longer needed (and should be removed) because Oolite instead uses the OS setting.

[mcarans]

@kanthoney I have tried switching to the English Dvorak keyboard in the OS and launching the game.

The key P on a Dvorak keyboard is where R is on a Qwerty keyboard. In Oolite, I had to press R (Dvorak P) to pause.

Accelerating is W in the Oolite key configuration. Pressing Dvorak W (which is on the bottom row of keyboard) accelerated (not Qwerty W).

Presumably this is what you expect?

[phkb]

The current keyboard setting changes which section of the keyconfig2.plist Oolite will use. Keyconfig2.plist has a bunch of tweaks to various keys so that each keyboard type matches the OoliteRS.pdf file, and so there is consistency in player experience, without having to manually tweak the keyboard layout themselves. It doesn't have anything to do with SDL or what keyboard is set in the OS.

[phkb]

I won't have a chance to explore this in more detail until tomorrow. I'll report back then

[mcarans]

The current keyboard setting changes which section of the keyconfig2.plist Oolite will use. Keyconfig2.plist has a bunch of tweaks to various keys so that each keyboard type matches the OoliteRS.pdf file, and so there is consistency in player experience, without having to manually tweak the keyboard layout themselves. It doesn't have anything to do with SDL or what keyboard is set in the OS.

By this do you mean that if I play on a Dvorak keyboard, the key positions should be the same as on a Qwerty keyboard eg. accelerate which is W on a Qwerty keyboard is instead mapped automatically by Oolite to , (comma) on a Dvorak keyboard because comma on Dvorak is in the same position as W on Qwerty (ie. below 2 and 3)?

[kanthoney]

@mcarans I'm expecting P to pause on any keyboard layout, regardless of where the P key is located, so that sounds right to me

[oocube]

When I hacked my first PC with MS DOS and assembly language, there were two ways to access keyboard input:

1. Go for the make and break codes. Every key, when pressed emits a make code. When released it sends a break code. When held for long it would generate multiple make codes. With this pattern software can detect multiple keys being pressed simultaneously although there were only specific groups where this would work. Make and break codes would differ by little as they both would be based on the key's scan code. The disadvantage was that these keys could be mounted in different locations on the keyboard depending on the keyboard hardware's layout.
2. Go for the characters emitted by the keyboard driver. That means the keyboard driver would react to the make/break codes and generate the characters that were typed. It takes away the wondering where a key is on which layout - that is in the keyboard driver configuration. Also some national specific characters require a sequence of keys to be pressed to get one character. Just look at these french accentuated characters, or japanese keyboard input.

With the keyboard driver in the loop you could now distinguish raw (make and break codes) and cooked modes.

Why am I mentioning all this? Even today, when looking at libraries that abstract away the hardware there are traces of this behaviour: As an example, mind the keyPressed, keyReleased (both raw) and keyTyped (cooked) methods in Java AWT. And I suspect SDL is no different here.

That means we should not only look at what the user does but also how the application processes these events. How is that implemented in Oolite?

Edit: https://wiki.libsdl.org/SDL3/BestKeyboardPractices
This is a worthy read to have a quick overview.

[kanthoney]

@oocube is the keyboard layout in your OS set to German? If I set my keyboard layout to German in my OS everything works as I'd expect, i.e. to zoom I have to press where the Z key would be on a German keyboard

[oocube]

@oocube What happens if you change your keyboard setting in the OS - does Oolite use the correct keys?

If I understand correctly, the behaviour change you see is expected: with SDL3, the "Current keyboard layout" setting in the game is no longer needed (and should be removed) because Oolite instead uses the OS setting.

@oocube is the keyboard layout in your OS set to German? If I set my keyboard layout to German in my OS everything works as I'd expect, i.e. to zoom I have to press where the Z key would be on a German keyboard

Answering both:
i see little use in twiddling OS wide settings back and forth just to start one or the other application. I know today's OSes allow changing the driver per window - I use that at work on a US keyboard when exceptionally writing german text and need the special characters. Back to home...

My Ubuntu is configured for german keyboard, and I do not switch the layout just to write english. Thus, Oolite always perceives the german input driver settings. In my above experiments I just switched the keyboard inside Oolite. Note my comment before I switched: At that time Oolite was displaying "Default (US)", and the keys behaved well. To me it looked like Oolite tried to apply some mapping for the keyboard which SDL may have covered already.

[oocube]

Oh rats. Now that I started fooling around the keyboard combinations, I no longer can request the docking clearance or perform the fast docking. Shift+L and Shift+C are no longer effective despite they are mentioned in the UI and I tried both within Oolite on Default (US) and German. What is going on here?

After all the autoilot activates when pressing "c".

[kanthoney]

@oocube Can you try the latest commit?

[oocube]

I tested based on oolite_dev-1.93.1-PullRequest620.175-x86_64.AppImage.
Now I was able to go back into the station using Shift+L and Shift+C.
Also I verified this now works regardless whether I am on German or Default (US).

Well done!