Settings App Portability

[BenjamenMeyer]

A new Python-based Settings Application was introduced for 0.10.x and later.

1. This needs to be more portable so we can integrate it into the various other games (PCWU, PrivGold, VSU:BP). This will need to be ready for 0.10.x to be released.
2. Eventually this needs to be turned into an in-game screen that is also portable for the games. No milestone target for that yet.

Question: For the new independent Python App, once we get the bugs ironed out should we move it to be part of Assets-Masters so we don't tie it too closely with VS:UtCS? Does it make sense to turn it into a Python Package that can be pip installed outside of how we currently package it?

[evertvorster]

Please allow me to weigh in here as well.

This app is mis-detecting my screen resolutions, as I am on Wayland. (Python's screeninfo reads Xwayland)

It uses python's screen info to detect screen resolutions, but the game itself uses SDL to display. This using of another tool to detect something that is natively supported in SDL generates the opportunity to have mismatches between what is detected and what is used.

SDL is portable, and has mechanisms for detecting screen resolutions.
Using SDL directly carries with it the benefit that we don't have to translate from one tool to another, and has the benefit of being easier to port into the game at a later stage.

Here are two AI generated ways of getting screen resolutions:
Pysld3:

import sdl3

sdl3.SDL_Init(sdl3.SDL_INIT_VIDEO)

count = sdl3.SDL_GetDisplays  # pysdl3 may expose a ctypes wrapper; see note
# Typical pysdl3 usage:
displays = sdl3.SDL_GetDisplays()

for display_id in displays:
    name = sdl3.SDL_GetDisplayName(display_id)
    mode = sdl3.SDL_GetDesktopDisplayMode(display_id)

    print(f"{name} (ID {display_id}): {mode.w}x{mode.h} @ {mode.refresh_rate:.0f}Hz "
          f"(density {mode.pixel_density:.2f}, "
          f"{int(mode.w * mode.pixel_density)}x{int(mode.h * mode.pixel_density)} px)")

    nm = sdl3.SDL_GetFullscreenDisplayModes  # returns list of SDL_DisplayMode
    modes = sdl3.SDL_GetFullscreenDisplayModes(display_id)
    print(f"  {len(modes)} modes")
    for m in modes:
        print(f"  {m.w}x{m.h} @ {m.refresh_rate:.0f}Hz")

sdl3.SDL_Quit()

And raw SDL in C:

gcc -x c -o /tmp/sdlres - $(pkg-config --cflags --libs sdl3) <<'EOF'
#include <SDL3/SDL.h>
#include <stdio.h>
int main(void) {
    SDL_Init(SDL_INIT_VIDEO);
    int n = 0;
    SDL_DisplayID *ids = SDL_GetDisplays(&n);
    for (int i = 0; i < n; i++) {
        const SDL_DisplayMode *cur = SDL_GetDesktopDisplayMode(ids[i]);
        printf("%s (ID %u): %dx%d @ %.0fHz (density %.2f, %dx%d px)\n",
               SDL_GetDisplayName(ids[i]), ids[i],
               cur->w, cur->h, cur->refresh_rate, cur->pixel_density,
               (int)(cur->w * cur->pixel_density), (int)(cur->h * cur->pixel_density));
        int nm = 0;
        SDL_DisplayMode **modes = SDL_GetFullscreenDisplayModes(ids[i], &nm);
        printf("  %d modes\n", nm);
        for (int j = 0; j < nm; j++)
            printf("  %dx%d @ %.0fHz\n", modes[j]->w, modes[j]->h, modes[j]->refresh_rate);
        SDL_free(modes);
    }
    SDL_free(ids);
    SDL_Quit();
    return 0;
}
EOF
/tmp/sdlres

Both of these output this on my system:

BNQ BenQ EX3210U (ID 3): 3072x1728 @ 120Hz (density 1.25, 3840x2160 px)
  28 modes
  3840x2160 @ 120Hz
  3200x1800 @ 120Hz
  3072x1728 @ 120Hz
  2880x1620 @ 120Hz
  2560x1600 @ 120Hz
  2560x1440 @ 120Hz
  2048x1536 @ 120Hz
  2048x1152 @ 120Hz
  1920x1440 @ 120Hz
  1920x1200 @ 120Hz
  1920x1080 @ 120Hz
  1680x1050 @ 120Hz
  1600x1200 @ 120Hz
  1600x900 @ 120Hz
  1440x1080 @ 120Hz
  1440x900 @ 120Hz
  1400x1050 @ 120Hz
  1368x768 @ 120Hz
  1280x1024 @ 120Hz
  1280x960 @ 120Hz
  1280x800 @ 120Hz
  1280x720 @ 120Hz
  1152x864 @ 120Hz
  1024x768 @ 120Hz
  864x486 @ 120Hz
  800x600 @ 120Hz
  720x480 @ 120Hz
  640x480 @ 120Hz
Built-in Screen (ID 4): 1920x1080 @ 240Hz (density 1.33, 2560x1440 px)
  23 modes
  2560x1440 @ 240Hz
  2048x1152 @ 240Hz
  1920x1440 @ 240Hz
  1920x1200 @ 240Hz
  1920x1080 @ 240Hz
  1920x1080 @ 240Hz
  1680x1050 @ 240Hz
  1600x1200 @ 240Hz
  1600x900 @ 240Hz
  1440x1080 @ 240Hz
  1440x900 @ 240Hz
  1400x1050 @ 240Hz
  1368x768 @ 240Hz
  1280x1024 @ 240Hz
  1280x960 @ 240Hz
  1280x800 @ 240Hz
  1280x720 @ 240Hz
  1152x864 @ 240Hz
  1024x768 @ 240Hz
  864x486 @ 240Hz
  800x600 @ 240Hz
  720x480 @ 240Hz
  640x480 @ 240Hz

The game resolution picker does not show the correct resolutions available on my machine:

As for making it a pip package, it seems not necessary.
In the WC games, you hit Ctrl+O, and then you can set options. In my mind, the simpler and more future-proof way would be to move configuration into the engine, and make it available with a hotkey. Most of the options set are really engine options.

There is, of course the consideration that if you want to use the vegastrike engine in another game that there are some things you want to change as to how the engine runs. This could be an overlay that the engine reads from Assets, and then it would be a minimal file, just changing the few things that are needed.

[BenjamenMeyer]

There is, of course the consideration that if you want to use the vegastrike engine in another game that there are some things you want to change as to how the engine runs. This could be an overlay that the engine reads from Assets, and then it would be a minimal file, just changing the few things that are needed.

I think that's likely the long term. We need to figure out how to balance this. the Engine need to have some configuration settings and the assets need to have their own configuration settings and the two need to merge together seamlessly in an in-game configuration tool

[BenjamenMeyer]

@evertvorster SDL3 is 0.11.x; certainly needed but we need an SDL2 version too for 0.10.x

[stephengtuggy]

There is, of course the consideration that if you want to use the vegastrike engine in another game that there are some things you want to change as to how the engine runs. This could be an overlay that the engine reads from Assets, and then it would be a minimal file, just changing the few things that are needed.

I think that's likely the long term. We need to figure out how to balance this. the Engine need to have some configuration settings and the assets need to have their own configuration settings and the two need to merge together seamlessly in an in-game configuration tool

I like this idea a lot. The sooner we can implement it, the better, as far as I'm concerned.

[evertvorster]

There is, of course the consideration that if you want to use the vegastrike engine in another game that there are some things you want to change as to how the engine runs. This could be an overlay that the engine reads from Assets, and then it would be a minimal file, just changing the few things that are needed.

I think that's likely the long term. We need to figure out how to balance this. the Engine need to have some configuration settings and the assets need to have their own configuration settings and the two need to merge together seamlessly in an in-game configuration tool

I like this idea a lot. The sooner we can implement it, the better, as far as I'm concerned.

The first thing we need is a list of configuration options that other games that use the same engine would set. We can convert this into a discussion so it can be tracked.

[evertvorster]

@evertvorster SDL3 is 0.11.x; certainly needed but we need an SDL2 version too for 0.10.x

We could, but SDL2 differs from SDL3 in a few important ways and would require two different code paths.
Adding a fallback will needlessly cause work later on to remove the SDL2 stuff. Assets does not seem to have a 0.10 branch, and maybe it should.

I'll make a PR that has the SDL2 stuff, but ideally that should be merged to a 0.10.x branch in Assets, leaving main SDL3 only.

vegastrike/Assets-Production#261

On my machine I have SDL2 installed, so I could test it, but of course the Windows and MacOS paths are untested.

[royfalk]

I see three issues here

1. Screen/Resolution detection is bad - Evert has this well in hand.
2. No support for PUWC in the settings app - for now we should just modify it in the PUWC assets repo.
3. Move to engine - I think this would actually be sooner than we think. Daniel is clearing most of the obstacles to this.