But Mark V actually has quite a few unique features QSS doesn't have. Quaddicted integration is just one nifty one.

This is kind of like suggesting why make your own mod if AD has all the features you want already? 

thats my point. Qs has a better renderer than MarkV and Qss has better mod support; so port the things you like from markv into qss.
or back port the best of qss into markV 

i mean baker will be back.. he always takes a break.
I am seriously forking qss and porting some quality-of-life things i am used to in Qrack over to it. i think, for my self, ripping code from qss and porting it to my engine just perpetuates the division of quake clients. Porting into one 'netQuake' code base (even as forks) help the "single-player" engine of choice. 

and ultimately the bumberstick says "just use FTE" but... we are talking about ftizquake variants :D 

*bumpersticker 

Making an updated fork of the Mark V engine (let's call it MarQ W or something) would be good for people who want a software renderer with up-to-date Quake compatibility. IIRC someone told me it doesn't support alphamasked textures properly. 

So with Arcane Dimensions out, is there any chance anybody will take a look at the source code and raise the limits to make sure all new maps are working?

Last time I checked in January, Quakespasm had limits like this: Dynamic lightmaps allocation, BLOCK_WIDTH/HEIGHT 256, MAXALIASTRIS 4096, MAX_STATIC_ENTITIES 4096, MAX_STACK_DEPTH 64, cmd buffer size 256K, MAX_EFRAGS/MAX_MAP_LEAFS limits removed.

I dunno if Spiked went even higher in his port modification, but that's the absolute minimum of what should be done. 

Baker still uses glBegin/glEnd code in MarkV so it will run AD like shite unless the renderer is rewritten. 

Well, maybe AD won't run properly with Mark V any time soon, but at least someone could address the issues with the other addons (still remember last Malice level with its fov warping, that ne_ruins crash with the succubus skin and others). I dunno how some of my reported bugs were fixed and then broke again, but since it is known what was the problem, it should be possible to re-apply those fixes easily.

We have the source for a potential Mark VI uploaded since ages, but sadly nobody seems to be interested in it. Baker surfaces occasionally, teasing how awesome his return will be, only to disappear again for many months without doing a thing. It is frustrating since Mark V is a really good port, but it could be even more if it was continuously updated. I don't want to be forced to use Quakespasm just because anything else doesn't run latest giant maps any more. (And QS/QSS isn't flawless, either, as I recently noticed during a thorough playtesting session.) 

… with most of this post. It would be really nice to have autosave, demo rewind, handy map and demo menus and the countless other features Mark V has in a new updated package.

If it played most releases it would be the best engine hands down. 

I mean, QSS ain't bad. It has the DLLs scattered all around the place instead of having it inside of the exe, but I could live with that.

However, it's missing .vis support, which is a big minus if you don't like to use pre-vised maps. Then there's no Nehahra support - OK, it's just one mod and the rest works, but still. QSS also seems to have some problems with SoA (final cutscene broken) and DoE (lavamen spawning in wrong places). Shrak head gibs are missing their skins (Baker fixed that in Mark V). There's probably more.

Either Mark V development is resumed at some point or at least they port over those features/fixes from Mark V to QS/QSS. 

However, it's missing .vis support, which is a big minus if you don't like to use pre-vised maps.

The hell is this about? 

Jordi's visor? 

http://vispatch.sourceforge.net/

Vispatch support. 

@onetruepurple
Basically .vis files are some kind of diff files which contain information regarding transparent water. If you have those files (which are much smaller than the actual maps), you don't need fully vised maps for transparent water. It's mainly about saving disk space (since usually you don't replace the maps inside of the original pak, but rather load replacements afterwards as some kind of patch). 

I think external .vis files can also contain colored lightmaps. I know there are a few colored lighting packs for Mark V and it's a bunch of maps\*.vis files.

And basically it works like external .ent replacement. 

Colored lights are provided by .lit files, not .vis. I bundled them in my Mark V packs for user convenience. Other than .vis, .lit files are supported by most of the popular ports out there, also QS/QSS. 

Oops, that's right. 

I'm on the fence about translucent water for classic maps. There are cases in id1 where water was used as a vis-blocker, and while performance isn't really an issue with those maps any more, it can be gameplay-affecting. I'm inclined towards the opinion that if a map wasn't designed for translucent water then it shouldn't have it, but on the other hand freely concede the visual improvement. 

Travail was vised without transparent water as an artistic choice. 

Actually Travail looks like crap with vised water. Many structures that reach into the water do not continue below the water surface, making them look cut or floating on top.

Anyway, someone should at least port over some additional functions from Mark V to QS/QSS if Baker's (or anybody else's) development won't resume. 

MarkV isn't my engine although I did contribute code to the D3D renderer.

My own opinion is that MarkV is not the type of engine I'd make or use. I consider it as "collapsing under the weight of it's own feature-bloat", and I'd probably go straight to ripping apart the existing renderers and replacing them with a more modern, single API approach. 

But do you think D3D is the way to go? I don't even know what QS is using. It's certainly fast enough. In QSS, I found PK3 support useful since PAK is really outdated and does not provide any compression at all.

Just a bit disappointed they still didn't get that waterwarp effect working. But I guess many people can live without it if all those huge BSP2 maps out there run properly.

In general, I also prefer ports with simple features. There are many Mark V features I would never use, e.g. QMB particles or AVI capturing. What I like is the level selection via ingame menu.

I dunno if we need yet another port variation for Quake, but then again there can't be enough of them since the preferences are different for a lot of people. Personally, I'd settle for something that
can run most recent AD maps while also being able run all the classics flawlessly, including exotics such as Nehahra, Malice or Shrak, with LIT/VIS support, all limits removed, MP3/OGG soundtrack handling, authentic underwater warp, option for original weapon positioning, PK3 support, external texture support (if you really want to use those HD mods)... I think that's about it, at least for me. 

But do you think D3D is the way to go?

In 2020 I don't think it matters so much anymore. The state of OpenGL drivers is much better than it was 10 years ago, primarily because OpenGL itself has been mostly a static target for a long time now. That also means that you can more reliably depend on features up to version 4.x being widely available.

These days I think the main reasons to use D3D would be if you wanted to be different, or if you just prefer it as an API. Otherwise there's enough tradeoffs between both that it's pretty much 50/50.

In a Quake context, optimizing the shite out of an existing legacy OpenGL codebase pretty much involves a complete rewrite anyway. 

to make at least small adjustments to the code, e.g. prevent resolution change underwater in WinQuake?

I mean, we have the code on Github now since over a year, but nobody seems to be interested in doing anything with it, at least increasing limits or fixing small stuff. Which is sad. I would do it by myself if I could.