odd choice of engine; please specify engine in description

[jmtd]

I was curious to discover that the Freedom flathub apps bundle GZDoom, pre-compiled by others. This is a curious choice, for a couple of reasons

1. the binary builds that are shipped include anonymous analytics submission to the builder
2. GZDoom does not support (vanilla format) demo playback

(2) in particular suggests another engine would be a better choice, IMHO, such as Crispy Doom (which also supports runtime resolution changes via window being resized by window manager, which is more friendly than in-game menus, especially if the default resolution choice ends up being unreadable. This is what brought me to investigate the flatpak, actually, someone reporting exactly that to me, and not knowing what engine it was they were actually running)

[jmtd]

Another consideration from the flatpak POV is how to reconfigure controls. GZDoom supports in-engine, but crispy-doom doesn't, one must invoke crispy-doom-setup separately. I'm not sure if that would work in the flatpak model. Eternity Engine supports all of demo playback, in-engine control redefinition, but I'm not sure about window-resize resolution switching.

[Calinou]

In this Flatpak, GZDoom is built from source; its official binaries are not used.

I think GZDoom is a pretty sensible choice for this Flatpak — having to use a separate program to configure things quickly becomes tiring and breaks the immersion.

We could disable the analytics system in this Flatpak though (it might involve patching the source code, I'm not sure).

[TingPing]

This package doesn't have network access, analytics won't go anywhere anyway.

[Calinou]

Specifying a NO_SEND_STATS [1] preprocessor macro is enough to disable it completely, though I haven't found the cmake option for that yet, which was mentioned on the GZDoom forum.

It looks like there's a standard CMake option for defining a macro via the command line. Something like this could possibly work:

cmake -D CMAKE_CXX_FLAGS=/DNO_SEND_STATS=1

[jmtd]

Hey folks, thanks for the constructive replies!

@Alexander-Wilms wrote:

I chose what's recommended on the Freedoom homepage.

I didn't realise upstream was recommending GZDoom, which came as a surprise to me. It makes perfect sense for this flatpak to follow upstreams' recommendation (I started a discussion upstream about the recommendation upstream since that's the place to discuss it)

Re the analytics; I mistakenly interpreted the analytics nag-screen as suggesting that the flatpak must be using prebuilt binaries, which is not what I would normally have expected, so I'm pleased to learn it's not; the no-network capability on the flatpak is great. Finding and setting the flag to disable the screen even better, thanks!

To expand on what led me to file this in the first place: A friend of mine decided he wanted to give "Doom" a try, so he installed this flatpak, but found the result was a window too small for him to read, and he couldn't resize it by dragging, so he gave up. My first debugging question was to ask "what engine was that then"; so I still humbly suggest that this is worth a mention in the flatpak description. My experience of running it is different: the default window size is fine. I am also able to drag-to-resize it without having to use the in-game menus (which were illegible at the small size for my friend). Were that not the case, I would have probably pursued the resizing issue upstream, having identified the engine; but given it already works, I'll just drop the enquiry.

As regards the in-game or ext-game setup: I agree, it's much more convenient to have it in-game. The Chocolate Doom is a bit of a special case since it tries to reproduce vanilla which didn't do it in-game; but this trickles to its derivatives. I've got some things in the pipeline for Choco which might make it much easier for derivative engines to have more in-game configuration, and also to make it easier to run on things like flatpaks, or embedded systems like Nintendo 3DS. But that's totally tangential to here, and I definitely would not recommend Choco as the engine for this. I just thought you might be curious to know :>