ZDoom

Sounds good. Will you do it? I'll be quite busy with the renderer for at least two more weeks - and I want to get that to a state where I can test multithreading realistically.

The main problem on Windows with an in-game mode change is that it requires a complete teardown of all video resources and rebuilding them afterward. And that's already causing some problems. True fullscreen is so crappy that even Apple recommends to avoid it since ~2010. For once I agree with Apple ...

Scripten wrote:Steam already has a two-week return window

Wanna bet that you'll be kicked out if using that too often?

I don't think that game studios will support this. They are thoroughly happy that they finally have a means to sell games where the consumer has little chance to check out the game before buying and no chance to sell it after having played it. Who cares if they alienate half of their potential user ...

I don't think the current default should be kept. It just sounds wrong.

Jimmy wrote: - A "thermal visor" shader that colors the enemies (and possibly hazards) in red/yellow and the rest of the terrain in blue/purple.

Isn't that just a different color scheme for the existing 'enhanced Nightvision' mode?

In case you ask, why the setup is like this, you'll have to go back 25 years and ask the people who made the original Doom. Changing this stuff to be more intuitive now would only make things worse.

Every time I have to let CMake regenerate the project it will reset XCode's indent to use spaces instead of tabs, so I have to manually reset it. Is there any way to tell it to set it to tabs, as is the default for the GZDoom source? Unfortunately the CMake documentation is no help here, as usual ...

Are you sure that this isn't just a printout mismatch? I guess if this wasn't working it would have been discovered long, long ago, because the consequences would be too obvious.

Gutawer wrote:not mass * velocity - that's momentum.

Not according to vanilla Doom "physics"...

Such a feature does not exist. You can set a color directly but there is no transfer function. Why do you need one?

Dumb question: Have you ever tried the DOS editors with 'cd'ing into their directories? Lots of software of that vintage cannot possibly be run like you tried. If it does not find its data in the current working directory it'll just fail.

One thing I find absolutely necessary here is that switching between simple and advancecd menus should be remembered for the next time the options menu is opened. While I appreciate the effort to make the menus more accessible, I have to admit that I felt completely lost in the simpler ones because ...

My guess is that outright 'no'ing it may be translated into 'Don't hold your breath.'

I see you still have separate entries for Rendering and Truecolor Software. These have been merged in the 2D Refactor branch which the next minor release will probably be based on.