(Low prio/future) 'Nice to have' would be more user-friendly control over fullscreen

[davidjoffe]

E.g. in-game menu option under "Settings" could have a few radio options like:

Fullscreen mode:
(*) Use commandline (default windowed)
( ) Always full-screen (overrides commandline)
( ) Always windowed (overrides commandline)

This could be a user-local preference, eg saved together with the volume.

HOWEVER, it's not quite so simple. As we want to target many platforms, it may be that on some platforms we ALWAYS want fullscreen only, and on some platforms we may NEVER want fullscreen, etc. .... so it should still be possible for game "packagers" implementing the game on some platform to also have options to OVERRIDE this (eg extra commandline line settings similar to the ones we have now) that cause this hypothetical ingame settings menu to be removed for that platform. (I think? So if you're 'packaging' the game for some open source console where there is no windowed mode you may want to force fullscreen always without giving the user the ability to have the option (say). ... e.g. a commandline option like "-nouserfullscreenoption"?)

Finally there should probably be another option like 'emulated fullscreen' that tries to 'emulate' fullscreen by simply having a large window (with no or minimal 'window dressing'), but that tries to be placed as an overlay over the entire screen - but still maintaining the full 'desktop resolution'. (To handle the fact that the aspect ratio probably won't be the same, I suggest 'enveloping' e.g. a black area either above and below, or to the sides - probably not a stretch blit.) (If we're running remote over X window system this might also be useful to get the highest possible resolution, even if say the X window 'desktop' is in a window of its own.)

On some platforms, we could also consider later having the option to by default just ask the user on first-time run, or something, 'Run fullscreen? Yes/No' - IF this isn't overridden by 'packager preferences' or commandline options)

Initial 'quick' implementation could just apply the setting on next run; later could have live switching as a further 'nice to have' (but that is more work)

Likewise for the 'scale' factor.

See also: #113

Also see here, where I explain some of the rationale that went into how the game behaves currently so far this regard: https://portableapps.com/news/2020-04-26--dave-gnukem-portable-1.0.1-released#comment-243662

Me: "The default mode of the game IS in fact windowed (my personal preferred default as fullscreen causes some problems on some platforms, 320x200 resolution can have blurriness issues on some modern hardware, and also if you're doing things like livestreaming when you run it, switching to 320x200 fullscreen can interfere with OBS streaming setup, so the game defaults to windowed mode but allows users to 'opt in' to fullscreen). By default it creates a window as large as possible for your desktop resolution but with view scaling to upscale the game's retro 320x200 resolution* (which is a crucial part of the 'retro experience' - having higher resolution would cause the retro goal to be lost). The game offers several ways to control this behaviour (eg "-f" and "-scale" options), as it's intended for running on many platforms, and for some platforms (eg consoles) fullscreen by default makes more sense. The PortableApps contributors decided to enable the "-f" option to have it run by default in fullscreen mode, but this can be turned off by simply opening Data/DaveGnukemPortableSettings.ini in a text editor and removing the "-f", as was helpfully pointed out elsewhere in the comments. For the "retro experience", fullscreen mode is closer to the original, as in 1990s the original Duke Nukem 1 was EGA 320x200 16-color fullscreen only. So from the retro experience perspective it makes sense to prefer fullscreen as default. Most gamers also prefer to run games in fullscreen mode as it makes for a more immersive experience (and I've heard some gamers literally complain loudly when they see games running in a window). So there are many aspects to consider that must all be balanced."
...
"Of course 'live switching' and more user-friendly control over this setting would be "nice to have" in the game, but there are technical and simply time limitation reasons that I hadn't implemented live switching between fullscreen or in-game menu settings (as this is a "spare time" project and was a huge amount of work, it is man-years of work to create even a small game like this - so the choice is between 'no game at all' or 'a release that doesn't have every possible feature anyone might wish for'.) I may do this in future but as this makes no money it's unlikely I'll be able to make time."

(* The 'creates a window as large as possible' then using an upscale blit was basically how I solved the problem of having an incredibly tiny 320x200 1:1 window on modern resolutions like 1920x1080, while still balancing with my 'create windowed by default' desire ... so the 'large a window as possible' still makes for a relatively immersive experience (and closest to retro original) just short of actually going full-screen) ... if this wasn't trying to be a retro game then I would have simply used both a higher actual-in-game resolution, and higher frame rate ... but the same principle would apply even if the game were say 1920x1080 and we're running on a 4K display or whatever.)

[davidjoffe]

I've started working on possible live in-game fullscreen switching - tentatively sort of works (see new config option djEXPERIMENTAL_FULLSCREEN_TOGGLE, disabled by default as it's still a bit buggy)