Full Screen Mode locked at 1024x768

[phkb]

Don't often post here, but I just installed Ooltie from the FlatHub on a brand new install of AnduinOS, and I've hit a snag. I can't get Oolite to play iusing the full graphical width of my screen. It plays in full screen mode, but when I go to the options, it says the Full Screen Mode is 1024x768, which means my 16:9 4K display (3840x2160) has two black bars on either side of the screen. Hopefully this screenshot illustrates the issue:



Not sure what I should add/edit/remove from the config file to fix this. I tried setting the window_height and window_width properties, to no avail.

Suggestions?

[MrFlibble]

Don't often post here, but I just installed Ooltie from the FlatHub on a brand new install of AnduinOS, and I've hit a snag. I can't get Oolite to play iusing the full graphical width of my screen. It plays in full screen mode, but when I go to the options, it says the Full Screen Mode is 1024x768, which means my 16:9 4K display (3840x2160) has two black bars on either side of the screen. Hopefully this screenshot illustrates the issue:



Not sure what I should add/edit/remove from the config file to fix this. I tried setting the window_height and window_width properties, to no avail.

Suggestions?

Which version of AnduinOS?
Bare metal, or Virtual?
(Grabbing 1.4 so I can try on a spare PC)
Just tried with AnduinOS 1.4 ToGo mode.

If you use left and right cursor keys on the "Full Screen Mode" item, you should be able to flip resolutions.

Oddly, the Flatpak version shows "Oolite v1.92.1 Nov 11 2011" on the window head. Static date string in build?

Also, I found that in flight, switching back to windowed mode with F12 has the quirk that the mouse gets 'trapped' in the Oolite window, unless one uses alt-tab to switch to another window.

[phkb]

Which version of AnduinOS?

Bare metal. I'm exploring the option of one day making some version of Linux my daily driver.

[cbr]

cursor keys left/right to change resolution? (worked for me, mint)

[phkb]

cursor keys left/right to change resolution? (worked for me, mint)

Ah! That did it! Thanks! (And I should have thought of that... *kicks self for being blind*)

...

Oh...err...

At 3840x2160 resolution, I get an FPS of <10, with a vanilla Oolite installation. I know I played Oolite successfully at this resolution on this laptop when I had Windows installed on it. Specs are HP Elitebook 1050 G1, Intel Core i7-8850H, 32GB ram, 1TB HDD. I've got the NVIDIA drivers installed (I think...at least, I can see the NVIDIA X Server Settings app, which appears to show various details of the GPU). What should I be looking for?

[mcarans]

cursor keys left/right to change resolution? (worked for me, mint)

Ah! That did it! Thanks! (And I should have thought of that... *kicks self for being blind*)

...

Oh...err...

At 3840x2160 resolution, I get an FPS of <10, with a vanilla Oolite installation. I know I played Oolite successfully at this resolution on this laptop when I had Windows installed on it. Specs are HP Elitebook 1050 G1, Intel Core i7-8850H, 32GB ram, 1TB HDD. I've got the NVIDIA drivers installed (I think...at least, I can see the NVIDIA X Server Settings app, which appears to show various details of the GPU). What should I be looking for?

I'm not familiar with Gnome, but I believe the Driver Manager is common to all Ubuntu variants (I'm on Kubuntu). You should be able to see what NVIDIA drivers are loaded in that tool. I see "Using NVIDIA Driver (open kernel) metapackage from nvida-driver-590-open (proprietary, tested)" in mine.

[mcarans]

Oddly, the Flatpak version shows "Oolite v1.92.1 Nov 11 2011" on the window head. Static date string in build?

I've looked into that. It seems that the __DATE__ within a Flatpak environment returns an old date. AI claims "This is the most likely culprit. To ensure that builds are reproducible (meaning the same code always results in the exact same binary file), many build tools—including those used by Flatpak—set an environment variable called SOURCE_DATE_EPOCH...When GCC (the compiler) sees this variable, it stops using the "real" current date for the __DATE__ macro. Instead, it uses a fixed timestamp."

This ultimately requires a major rethink of how version info enters the build, but I'm trying to think of a short term fix to begin with.

[Lone_Wolf]

I've looked into that. It seems that the __DATE__ within a Flatpak environment returns an old date. AI claims "This is the most likely culprit. To ensure that builds are reproducible (meaning the same code always results in the exact same binary file), many build tools—including those used by Flatpak—set an environment variable called SOURCE_DATE_EPOCH...When GCC (the compiler) sees this variable, it stops using the "real" current date for the __DATE__ macro. Instead, it uses a fixed timestamp."

This ultimately requires a major rethink of how version info enters the build, but I'm trying to think of a short term fix to begin with.

https://reproducible-builds.org/specs/s ... ate-epoch/ might help to set a correct value for that variable.

[mcarans]

I've looked into that. It seems that the __DATE__ within a Flatpak environment returns an old date. AI claims "This is the most likely culprit. To ensure that builds are reproducible (meaning the same code always results in the exact same binary file), many build tools—including those used by Flatpak—set an environment variable called SOURCE_DATE_EPOCH...When GCC (the compiler) sees this variable, it stops using the "real" current date for the __DATE__ macro. Instead, it uses a fixed timestamp."

This ultimately requires a major rethink of how version info enters the build, but I'm trying to think of a short term fix to begin with.

https://reproducible-builds.org/specs/s ... ate-epoch/ might help to set a correct value for that variable.

AI advises not changing SOURCE_DATE_EPOCH and although it doesn't specifically say so in the doc you sent, I get that impression from reading it. I will investigate passing in a build date to the build.

[Lone_Wolf]

AI advises not changing SOURCE_DATE_EPOCH and although it doesn't specifically say so in the doc you sent, I get that impression from reading it. I will investigate passing in a build date to the build.

Did the AI answer differentiate between setting this environment value and changing it ?

If not, you need to rephrase the prompt. It would also be a good idea to add https://reproducible-builds.org/ as authorative source for this prompt .

[mcarans]

AI advises not changing SOURCE_DATE_EPOCH and although it doesn't specifically say so in the doc you sent, I get that impression from reading it. I will investigate passing in a build date to the build.

Did the AI answer differentiate between setting this environment value and changing it ?

If not, you need to rephrase the prompt. It would also be a good idea to add https://reproducible-builds.org/ as authorative source for this prompt .

The AI pointed me to this from the reproducible builds website (https://reproducible-builds.org/docs/timestamps/):
"If a date is required to give users an idea on when the software was made, it is better to use a date that is relevant to the source code instead of the build: old software can always be built later. Like version information, it’s best to extract such a date from the revision control system or from a changelog."

If you use the compilation flag -Werror=date-time you get errors like error: macro "__DATE__" might prevent reproducible builds [-Werror=date-time] (https://askubuntu.com/questions/593566/ ... ucible-bui), so it's clearly a good idea to move away from using that macro in modern builds.

It is part of the build process of FlatHub that sets SOURCE_DATE_EPOCH to 2011-11-11 11:11:11 UTC as mentioned here: https://github.com/apache/buildstream/issues/1580,

AI gave this summary:
"Summary Recommendation for Flathub

Don't use __DATE__ or time(): These will either break reproducibility (causing Flathub's linters to complain) or will be forced to 2011.

Treat the date as Metadata: View the date as a piece of version information, not a side-effect of the build.

Pass it via Build Args: The most robust "Flathub way" is to have your build script (Makefile/CMake) accept a variable (e.g., -DVERSION_DATE="2024-05-20") and set that variable in your Flatpak manifest's config-opts or env section."

I will try to extract the date from Git and pass it as a build variable for the maintenance branch. This will need to be done properly on master for 1.93 including extracting the version from Git as well.

[Commander_X]

[...]
Oh...err...

At 3840x2160 resolution, I get an FPS of <10, with a vanilla Oolite installation.[...]

Besides the other suggestions/comments, nowadays I'd guess there is also the question of what underlying server you're running under? Is it X Window System, or Wayland?
While NVidia proprietary drivers are quite dependable on the X server side, their Wayland support is still an ongoing process. E.g. I was told to downgrade my attempt at latest NVidia drivers while I was struggling to get HDR under Wayland. It still didn't get me there, but helped with solving one of the requirements.

The NVidia X Server Settings app, is usually showing a lot more stuff when run under X Window System (that is, a lot of display/monitor/screen info, besides the GPU), than when run under Wayland (where it mainly knows only about the GPU).

So, unless you're lucky enough to get some decent tweaking advice for your specific environment, the first thing I'd recommend is to make sure you're running in under X server, and take it from there.

[MrFlibble]

[...]
Oh...err...

At 3840x2160 resolution, I get an FPS of <10, with a vanilla Oolite installation.[...]

Besides the other suggestions/comments, nowadays I'd guess there is also the question of what underlying server you're running under? Is it X Window System, or Wayland?

AnduinOS uses Wayland by default, at least on my Intel test lump.

Code: Select all

$ set | grep -i way
QT_IM_MODULES='wayland;ibus'
WAYLAND_DISPLAY=wayland-0
XAUTHORITY=/run/user/1000/.mutter-Xwaylandauth.SXA0K3
XDG_SESSION_TYPE=wayland

[Commander_X]

[...]

AnduinOS uses Wayland by default, at least on my Intel test lump.

Code: Select all

$ set | grep -i way
QT_IM_MODULES='wayland;ibus'
WAYLAND_DISPLAY=wayland-0
XAUTHORITY=/run/user/1000/.mutter-Xwaylandauth.SXA0K3
XDG_SESSION_TYPE=wayland

That would explain it.
On my Slackware 15.0, under X server (and NVidia driver 570.172.08), I did some FPS testing, using my own 1.93 build. This is on a NVidia GeForce GTX 970, 3 displays, 2 of them at 60 Hz, one at 144 Hz.
My regular 1600x900 window run on the "main" display @60 Hz (although the driver doesn't have "Sync to Vblank" enabled) showed cca. 60 FPS, pinned. (I'd guess the game does vsync regardless, unless the option to disable it is set in its "defaults" plist).
I tested a 5760x1080 full screen over all the displays, and I got a minimum of 23 FPS while having the main planet quite closely on my screen (i.e. with also a visible, close station).
The only AddOns component is the custom shader I'm trying to tweak as part of my BPlanets attempt (and it's associated planetinfo and material-defaults plists) -- and this might impact quite a bit the performance.

[MrFlibble]

On my Slackware 15.0, under X server (and NVidia driver 570.172.08), I did some FPS testing, using my own 1.93 build. This is on a NVidia GeForce GTX 970, 3 displays, 2 of them at 60 Hz, one at 144 Hz.
My regular 1600x900 window run on the "main" display @60 Hz (although the driver doesn't have "Sync to Vblank" enabled) showed cca. 60 FPS, pinned. (I'd guess the game does vsync regardless, unless the option to disable it is set in its "defaults" plist).
I tested a 5760x1080 full screen over all the displays, and I got a minimum of 23 FPS while having the main planet quite closely on my screen (i.e. with also a visible, close station).

Jealous!!!

(Waddles into the sunset muttering about the need to invest in better hardware)