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. 

Hello i have problem with Dissolution of Eternity HUD.
https://www.quaddicted.com/forum/viewtopic.php?id=421
"The armour / ammo icons displayed do not match the actual armour or weapon you have equipped."
This person has the same problem,he is using a PSP port,im using a Mark V.Is the problem on my side or Mark V? How do i fix this? 

What command line are you using to launch it? 

Using -hipnotic the command line? Yes/No?

Probably your problem. Let me know.

@gunter - ok, r_shadows 3 option. Maybe a week later after his post I realized that was likely the issue he was experiencing. 

I meant -rogue, not -hipnotic.

:( 

WinQuake runs with constant stutter but I couldn't find any way to turn on vsync. Can anyone help? 

I don't know of any WinQuake that ever vsync since that is a Open GL feature.

That being said, if you really want a WinQuake with vsync ... here is a slightly older beta with vid_vsync 0|1 capability:

http://quakeone.com/markv/builds/1025_mark_v_beta.zip

It is the WinQuake-GL.exe in that .zip that has vid_vsync because it renders the buffer to an texture and then draws it on the screen through Open GL. 

Thanks Baker, I found that build last night and it's fantastic for playing Quake as authentically as possible.

Is there a reason why this .exe is no longer included or being worked on? It's really the best of both the GL and software modes, since it has no graphic glitches and z-fighting like the GL version, while retaining it's best features such as UI scaling and vsync.

It just makes no sense to me at all. 

The regular WinQuake can hit higher frames per second, doesn't matter much for small resolutions but if someone decides to max out in a very large resolution there is a gap.

It is actually maintained because the Linux and Mac versions of Mark V WinQuake are WinQuake-GL builds, I just don't put a Windows one in the Windows .zip because it would confuse most people. 

Are you planning to put WinQuake_GL.exe's in future builds? 

I could make it available somewhere on the page in the future when new releases happen. 

Also, there have been two longstanding bugs to do with monster spawns that have been around since the original WinQuake - one in e3m3 where the fiend spawns midway in the air in the circular lava room when the final bridge activates and another in e4m7 where the zombies spawn after killing all the underwater zombies in the first circular room. In both cases the monsters are stuck in the air after spawning when they should fall to the ground/water and start attacking. Could you look into fixing these issues? 

Are you sure that these are engine and not QC bugs? My recollection is that they happen in all engines, not just WinQuake. If QC bugs it would be inappropriate to modify this behaviour in the engine. 

There's definitely source ports out there that fix these issues, but I admit that most I've seen don't.

Why would it be inappropriate to modify this behaviour in the engine? They are gameplay bugs after all so shouldn't they be fixed? 

If the bug is due to bad QC code or mapping errors, then changing the behaviour of the engine to work around the bug does carry a risk: some mods may be using this behaviour of the engine intentionally to create a desirable effect. The fix for the bug in vanilla will break those mods in your engine. Which isn't to say that it's never the right choice to make those kinds of change, but you have to be thinking about the potential cost as well. 

QuakeC is game logic in a progs.dat, found in Quake pak0.pak. It exists outside the engine and is the game logic program. It can be compiled with a QuakeC compiler like fteqcc.

Some people (like preach) are really into QuakeC, he is the main author of Quoth and was involved in Arcane Dimensions.

Concise version: QuakeC behavior isn't related to the engine.