I'm more inclined to believe that the 2D GUI gfx were actually designed with a 1:1 mapping of texels to pixels in mind, rather than any specific resolution. 320x200 is just an accident of history.

I did code up aspect adjustment just to see how it looks and as expected it's pretty crap when texture filtering kicks in.

It might be OK as an option but otherwise I'd leave the default alone. 

I'm more inclined to believe that the 2D GUI gfx were actually designed with a 1:1 mapping of texels to pixels in mind

Look at the pentagram icon. It should be a perfect circle, which only happens at 320x200. At 320x240, it becomes oval.

Also, the console background itself was obviously made with a non square pixel aspect in mind, and it has text pasted over it by the engine. With square pixel aspect, that text's aspect becomes different from the aspect of the rest of the engine's texts.

The help screens, which were made to cover the whole screen, are also 320x200.

And lastly, enlarging the 2D art vertically when using square pixels makes more sense than reducing the 2D art vertically when using non-square pixels. If the 2D art was reduced vertically, the help screens wouldn't cover a whole 4:3 screen. 

By the way, non-square 2D pixels should be optional, because several mods uses custom GUI artwork with square pixel aspect.

When rewriting the GUI renderer, I'm going to make it use an optional non-square scaling enabled by default. 

I think about the 2D rendering differences.

As there is no separation between the software renderer vs. the Open GL build -- it is FitzQuake calling the shots and saying what to draw and the location -- using a canvas system that WinQuake never had.

The source code in Mark V doesn't actually trace back to WinQuake, not even for the WinQuake build.

Which is way different than mankrip's engine or qbism super8 or engoo.

It is also why Mark V has immensely more versatile video capability than any other WinQuake. The video code is literally 100% FitzQuakian.

Shorter version: Eventually the aspect ratio thoughts will happen once the engine eventually settles down where there aren't "big leaps forward" looming. 

Eventually the aspect ratio thoughts will happen once the engine eventually settles down where there aren't "big leaps forward" looming.

Same thing here about colored lighting. It would be a pain to implement it now, only to rewrite everything when the new color transformation system gets implemented. 

Just to clarify what I mean: here's som screenshots with various combinations of aspect correction and texture filtering.

The "200 Height" shots are using the old 320x200 resolution but at a 4:3 aspect.

Pay particular attention to the menu slider bars. This is what I mean by a 1:1 mapping of texels to pixels.

http://www.quaketastic.com/index.php?dir=files/screen_shots/200_Height_Tests 

Oh, yeah. Now I know what you mean.

When you said "1:1 mapping of texels to pixels", you didn't limit the meaning to square pixels. A 4:3 320x200 screen will have non-square pixels, but the texels also have the same non-square aspect, so the screen will display the texels in a square ratio to the pixels.
A 4:3 320x240 screen multiplies the rows to compensate for the "non-square texel to square pixel" aspect when necessary.

Yes, such scaling generates notable artifacts at lower resolutions, which is another reason to make the 2D aspect correction optional. But at higher resolutions, the artifacts becomes unnoticeable. Also, some custom texture filters may help. 

You don't really get to do custom texture filters with hardware acceleration though. Well you can, but you have to write them yourself in fragment shaders so a lot of popular engines don't get to play. Otherwise texture sampling is fixed functionality.

Forgot to mention - one thing I really like about Quake's 2D graphics is the fact that they're so crisp and clear, and this is as a result of the precise pixel work that went into creating them. It's something that you might not notice at first, but any kind of texture filtering on them blurs out a lot of the fine detail. 

*shudders*

Would be nice for some maybe to have a gl_hudfiltermode convar. 

If there was a Quake engine that supported temporal antialiasing (TAA), then texture filtering would be completely unnecessary. 

I've cropped your unscaled screenshot to 320x200, and did some tests using The GIMP:
320x200 source

320x240 mockup, nearest scaling

320x240 mockup, bilinear scaling

Bilinear scaling in The GIMP shows that it's possible to scale Quake's 2D GUI in a way that looks good. It may be complicated to get that same quality using hardware rendering, but it's definitely possible. 

This produces sadness deep inside of me :( 

How can I keep Mark V from messing up my Quakespasm cfg? I switch back and forth between these engines and right now I exec a specific config for QS after using Mark V but it's still a bit messy. I gather that this is some kind of anti-cheat thing from some research here.

What am I missing? How can this be more seamless? 

two separate quake directories.
alternatively change all your config.cfg files to readonly so that nothing can overwrite them. 

Meh. Well, at least I have options. 

I gather that this is some kind of anti-cheat thing from some research here.
I don't think it's anti-cheat, what happens is when you exit an engine, it overwrites config.cfg with only the cvars / keybindings that engine is aware of.

So it's more of a limitation of the original quake config system, when extended to engines with diverging sets of cvars/keybindings.

I'm not too familiar with what has been tried to remedy this. 

Would be nice if the engines had their own sub config.cfg for the "new" non-vanilla id, non-standard cvars it has implemented.

config.cfg
config-quakespasm.cfg
config-markv.cfg

...and so on. That way we could keep my vanilla config and each engine looks for that and then loads theirs. Even if there is overlap the engine in question would ignore the others. I assume it's not this simple and would require co-operation to make it a "standard." 

No, it actually is that simple. It's something like 4 lines of code. In Cmd_Exec_f detect config.cfg and write in the engine cfg, in Host_WriteConfiguration write out the engine cfg.

I have no idea why it's not done. I'd love to see it done. 

and write both a config.cfg and config-engine.cfg with the same contents, as encouragement for other engines to follow suit... well, that and so new engines pick up usable defaults too.

however it would also need to be gamedir aware for all those mods that came with a config.cfg provided, so they don't read settings from id1/config-engine.cfg in preference to those in mod/config.cfg.
if engines had done the same with config.cfg vs default.cfg, we wouldn't have mods doing the stupid thing of including config.cfg files!.. 

Is the most recent MkV release capable of running "The Forgotten Sepulcher" from Arcane Dimensions v1.6? 

The main engine-breaker in Sepulcher appears to be the leafs count; this is used for several hard-coded arrays in the engine and even the extended max in Fitz or earlier versions of QuakeSpasm is insufficient for Sepulcher, which needs 73755 leafs.

Personally I think that engines should be dynamically allocating these instead of using big static arrays, because otherwise it's an arms race: an engine will bump the max, a map will overflow it, an engine bumps it again and so on.


Anyway, the latest MarkV bumped MAX_MAP_LEAFS to 65535 for the Rubicon Rumble Pack, so it too is insufficient to run Sepulcher. 

1375 models
368 sounds
193 lightmaps (assuming 128x128)
2877 static ents
4743 efrags

For QS I made efrags dynamic, and was going to do the same with static ents (although 3k is about the upper limit with protocol 666 because of 64k signon) 

Very nice engine. Just one thing. When you set the water to be opaque like the original, the sky is partly visible through it in the hardware renderer. But not in the software renderer. This seems to be the only noticeable discrepancy between the two, apart from affine mapping not being possible in hardware either. How hard would it be to fix this? 

Here is me on E1M2 looking at the sky with opaque water using the hardware renderer. The sky isn't partly visible.

Hardware renderer, opaque water, looking at sky -- none seen

Maybe a screenshot of what you are referring to would help? 

I believe he's referring to the same issue some of us have reported before: shadows and the sky are visible through models (and water surfaces it seems) in the DX9 version. (see #1098 #1206 -- mh knows about it: #1109 ).

I jumped in the pool on e2m1 and saw the effect he's describing.