Arch, Fedora tester needed

[mcarans]

Please can someone with Arch or Fedora (or other distro in which SDL3 is called via sdl2compat and sdl12compat) build and test Oolite from this branch: https://github.com/mcarans/oolite/tree/ ... aintenance

Relates to: https://github.com/OoliteProject/oolite ... 3988227651

[Commander_X]

Please can someone with Arch or Fedora (or other distro in which SDL3 is called via sdl2compat and sdl12compat) build and test Oolite from this branch: https://github.com/mcarans/oolite/tree/ ... aintenance

Relates to: https://github.com/OoliteProject/oolite ... 3988227651

(unasked for) I tried it on my Slackware 15.0. No SDL3, just SDL2 (2.0.20), and two monitors, each of 1920x1080.
No centering.
It seems somehow that getWin (GetWindowFromID) doesn't do its job.
Wrapping some extra printfs around, this is what comes out:

Code: Select all

Will try centering window ...
... through SDL3 (unlikely as it's not installed) ...
... through SDL2 (why wouldn't it?!) ...
... ok, handle initialized ...
... both getWin and setPos ...
getWin step 1
getWin step 2
getWin step 3
getWin step 4
getWin step 5
getWin step 6
getWin step 7
getWin step 8
getWin step 9
getWin step 10
Shouldn't reach here!

[hiran]

I heard (and suspect it is true) that Oolite creates a window (which at that time has width and height equal to zero), ask for centering, then resizes the window to show the splash screen (which just moves the bottom right corner).

That at least is what I perceive on my triple monitor setup.

Also I am happy to see the window gets "centered" on the primary screen. It was annoying to see Oolite always start up in the middle of my dual screen desktop which meant each of the monitors would display half of the logo.

[Commander_X]

[...] which just moves the bottom right corner [...]

That's what I observe too, the splash and game window are started in the bottom right, not entering the setPos branch at all.
On the other hand I just noticed the SDL2compat and SDL12compat (which I'd have to install) references in the github message.
This means (and checks, i.e. tried and confirmed that it still doesn't get a good result from the getWin call) that the info.x11.window I was trying to grab from GetWMInfo as an ID is also not what SDL2 needs for the GetWindowFromID.

Oh, well!

[Commander_X]

[...]
Oh, well!

Well indeed -- didn't even need to install sdl12-compat, just LD_LIBRARY_PATHed it!

[mcarans]

[...]
Oh, well!

Well indeed -- didn't even need to install sdl12-compat, just LD_LIBRARY_PATHed it!

Please try my latest changes on the branch.

I have implemented making splash window same size as main and it seems to work reliably without the SDL2/SDL3 code (which didn't seem to work with SDL12compat->SDL2compat->SDL3 setup). For example this appimage works fine for me: https://github.com/mcarans/oolite/actio ... 5750380267

I also tried on Ubuntu (SDL2), Fedora in distrobox (SDL3), Flatpak (SDL3).

[Commander_X]

[...]
Please try my latest changes on the branch.

I have implemented making splash window same size as main and it seems to work reliably without the SDL2/SDL3 code (which didn't seem to work with SDL12compat->SDL2compat->SDL3 setup). For example this appimage works fine for me: https://github.com/mcarans/oolite/actio ... 5750380267

I also tried on Ubuntu (SDL2), Fedora in distrobox (SDL3), Flatpak (SDL3).

I'm not able to run (without thrashing my uptime) the binary packages (still on glibc 2.33). Also the only binary package I'd test would be the AppImage (works by downloading and running, no extras needed for it). Due to not having a github account, I cannot fetch artifacts.

But I pulled your latest changes, compiled, and:
- it ran right away with the sdl12-compat (in LD_LIBRARY_PATH)
- it segfaulted with my local/slackware 15.0 SDL (version 1.2.15). It notified an Exit Code: 139, with this message in the console:

Code: Select all

./run_oolite.sh: line 35: 19087 Segmentation fault      "$@"

The splash window shows (on the other screen, but with the game window size, though) prior to the segfault.

[mcarans]

[...]
Please try my latest changes on the branch.

I have implemented making splash window same size as main and it seems to work reliably without the SDL2/SDL3 code (which didn't seem to work with SDL12compat->SDL2compat->SDL3 setup). For example this appimage works fine for me: https://github.com/mcarans/oolite/actio ... 5750380267

I also tried on Ubuntu (SDL2), Fedora in distrobox (SDL3), Flatpak (SDL3).

I'm not able to run (without thrashing my uptime) the binary packages (still on glibc 2.33). Also the only binary package I'd test would be the AppImage (works by downloading and running, no extras needed for it). Due to not having a github account, I cannot fetch artifacts.

But I pulled your latest changes, compiled, and:
- it ran right away with the sdl12-compat (in LD_LIBRARY_PATH)
- it segfaulted with my local/slackware 15.0 SDL (version 1.2.15). It notified an Exit Code: 139, with this message in the console:

Code: Select all

./run_oolite.sh: line 35: 19087 Segmentation fault      "$@"

The splash window shows (on the other screen, but with the game window size, though) prior to the segfault.

I'm not sure about the segfault with the old SDL1.2 version - could be that there have been bug fixes to the SDL since then or maybe some sort of clash if different SDL versions are somehow pulled into the build. Glad it worked with sdl12-compat. Thanks for testing!

[Lone_Wolf]

I'm not sure about the segfault with the old SDL1.2 version - could be that there have been bug fixes to the SDL since then or maybe some sort of clash if different SDL versions are somehow pulled into the build. Glad it worked with sdl12-compat. Thanks for testing!

sdl 1.2.15 release was in january 2012 and hasn't seen any releases since .

sdl12-compat on the other hand is now at version 1.2.78 and had its last release one month ago.

Edit : In a few days I may have time to test if it's still needed.

[Commander_X]

[...]
I'm not sure about the segfault with the old SDL1.2 version - could be that there have been bug fixes to the SDL since then or maybe some sort of clash if different SDL versions are somehow pulled into the build. Glad it worked with sdl12-compat. Thanks for testing!

The same old "SDL1.2" version is what I've used earlier yesterday, when I didn't know about the *-compat counterparts, and was chasing window centering. It didn't segfault, and it's what the game is using here on a regular basis.

[hiran]

I am wondering why we still discuss sdl1, sdl2, sdl3 and various compatibility layers. On linux the distribution format is now flatpak and appimage. Was not the whole switch intended to provide application plus libraries so that the OS libraries do not matter any longer?

Or is it that just half the libraries are in the package and the other half is system dependent stuff like kernel, drivers but also the graphical desktop and friends?
If the latter, where is decided what gets used when?

[mcarans]

I am wondering why we still discuss sdl1, sdl2, sdl3 and various compatibility layers. On linux the distribution format is now flatpak and appimage. Was not the whole switch intended to provide application plus libraries so that the OS libraries do not matter any longer?

Or is it that just half the libraries are in the package and the other half is system dependent stuff like kernel, drivers but also the graphical desktop and friends?
If the latter, where is decided what gets used when?

You are correct. The idea of the flatpak and appimage is to overcome the heterogeneity of Linux systems, a problem that doesn't exist for Windows (or Mac). Those packages contain everything needed for the game to run so local libraries should not be needed.

It would be an endless task to try to support all Linux flavours, but developers need to be able to compile and run Oolite so I made builds for the major distro families - Debian, Fedora and Arch - covering a good percentage of the Linux systems out there. It is up to others to work out how to support other systems.

[hiran]

You are correct. The idea of the flatpak and appimage is to overcome the heterogeneity of Linux systems, a problem that doesn't exist for Windows (or Mac). Those packages contain everything needed for the game to run so local libraries should not be needed.

It would be an endless task to try to support all Linux flavours, but developers need to be able to compile and run Oolite so I made builds for the major distro families - Debian, Fedora and Arch - covering a good percentage of the Linux systems out there. It is up to others to work out how to support other systems.

Ah, so in this case we still talk about builds neither packaged as flatpak nor appimage.
Whatever we learn, it may be reused inside those packages. Makes sense.

BTW, the heterogenity on Mac does exist as well. I goes from graphics interface OpenGL -> Metal up to switching CPU architecture. Apple performed Motorola -> Intel -> Arm. Such stuff requires a major rework that noone has attempted on Oolite yet.

Windows? It also changed over time. I loved to play Siedler III, and not even installing Windows 98 ME, for which I still hold the install CD and license can deal with it.

[mcarans]

You are correct. The idea of the flatpak and appimage is to overcome the heterogeneity of Linux systems, a problem that doesn't exist for Windows (or Mac). Those packages contain everything needed for the game to run so local libraries should not be needed.

It would be an endless task to try to support all Linux flavours, but developers need to be able to compile and run Oolite so I made builds for the major distro families - Debian, Fedora and Arch - covering a good percentage of the Linux systems out there. It is up to others to work out how to support other systems.

Ah, so in this case we still talk about builds neither packaged as flatpak nor appimage.
Whatever we learn, it may be reused inside those packages. Makes sense.

BTW, the heterogenity on Mac does exist as well. I goes from graphics interface OpenGL -> Metal up to switching CPU architecture. Apple performed Motorola -> Intel -> Arm. Such stuff requires a major rework that noone has attempted on Oolite yet.

Windows? It also changed over time. I loved to play Siedler III, and not even installing Windows 98 ME, for which I still hold the install CD and license can deal with it.

The difference is Mac and to Windows change at specific points in time on version upgrades but at any one point in time, the current version is a single flavour (more or less) eg. the current version of Windows is Windows 11 2025 Update (Version 25H2) and there are no other current flavours, whereas with Linux there are many current flavours at any given moment.

[hiran]

The difference is Mac and to Windows change at specific points in time on version upgrades but at any one point in time, the current version is a single flavour (more or less) eg. the current version of Windows is Windows 11 2025 Update (Version 25H2) and there are no other current flavours, whereas with Linux there are many current flavours at any given moment.

True, all the different linux distros have a different current each. And all that multiplies into how many OS, distributions and version one decides to support.

There could be some educated decision documented somewhere. I believe it would make life easier.