Still need to dive in but looks really promising. I am literally working on the next release of my Speed Mapping Progs and came here for some reference. Great to see the attention to detail here! 

The process is like this right now:
- Find z-fighting spots in the maps, take screens.
- Identify corresponding map structures in QuArK.
- Experiment with different settings until z-fighting disappears during ingame test.

Especially finding out which model ID is used is kinda painful, but it works. 

Try FitzQuake Mark V's "tool_inspector" command, which is a pretty nifty feature I found out about from dumptruck_ds' videos.

By selecting various weapons and pointing at stuff you can see various information, for example the z-fighting door in E2M1:

http://gila.deathmask.net/various/mark_v_tool_1.png

Then type "edict 207" and get detailed information. Maybe this will at least help to identify problematic cases faster?

P.S. "tool_inspector" is available in non-WinQuake version of Mark V. 

Forgot to post screenshot of console with Edict #207 information:

http://gila.deathmask.net/various/mark_v_tool_2.png 

As for the E2M1 Enforcer telefrags: I guess it could be fixed, but the oddity is even mentioned in the wiki as such, and not as a bug. It's a weird thing people kinda expect when playing this map, and if you remove it now, it will feel weird to them - besides increasing difficulty.

I try to be careful when it comes to such kind of changes. I did it in other cases such as the Spike Mines in SoA which spawned too close to walls and exploded prematurely, but here I would say it's rather an iconic moment and should be left as-is. I think KillPixel did not change it, either.

For now, I'll focus on eliminating visual glitches, which is much easier to agree upon. 

@gila That feature of Mark V is awesome, I didn't know about it but I'm definitely going to be using that now.

I do wonder if it would be possible in vkQuake to eliminate z-fighting in the engine itself, since as I understand it you have more control over the rendering pipeline in Vulkan than in DX>12 or OpenGL. Would it be possible in Vulkan to detect when surfaces are co-planar and just render one and not the other?

I mean, z-fighting didn't exist in the software renderer, so is it possible to replicate the software renderer's behaviour? 

Obviously I meant DX<12 :P 

This has come up before.

I can't remember specifics, other than to say that the way the software renderer draws world and bmodel polys (z-sorted spans without depth testing but with depth writing) is completely incompatible with the way GPUs work (rasterized triangles).

Basically, the software renderer doesn't do anything to explicitly remove co-planar polys. Removal of co-lanar polys is just an accidental byproduct of how it works. Implementing that on a GPU would involve rewriting sufficiently large portions of the software renderer that you may as well just use the software renderer and be done with it.

It's always possible to detect co-planar surfaces - it's just number crunching. The problem is that GPU API invariance rules and floating point precision limitations mean that 2 co-planar polys with different positions don't always generate the same depth values (that's what z-fighting actually is - small differences in the generated depth values that shift as you move or look around). So you'd need to introduce some kind of epsilon in your detection, and by the time you've taken that to it's logical conclusions, you've basically just re-invented polygon offset.

If surfaces were co-planar and used exactly the same position values, then the depth test rule would apply and you could solve all cases of z-fighting by using a depth test of e.g. GL_LESS rather than GL_LEQUAL.

Bottom line is that it's a content bug, and should be fixed in content. 

That Mark V tool inspector is indeed really helpful, especially since it's a lot easier than trying to recognize anything in the wireframe clusterfuck you see when you open a map in QuArK. It can still be tricky to identify the correct entity since often the right one isn't shown until you clip into walls or move to the right angle. (Kinda fun playing with the inspector active btw, all entities have these colorful boxes around them, even your projectiles. Disco mode!)

That being said, I am about 50% done with SoA now. HIP2M4 in particular is a z-fighting festival with numerous nasty and really obvious glitches.

Hard to say how much time it'll take, but I won't start DoE before next week to avoid burnout. I realize now why nobody ever wanted to do this since it requires patience and above all: testing, testing, testing. 

@mh I mean, yes, it's technically a content bug for any accelerated renderers. It's not a content bug for the software renderer for the reasons you've outlined.

As NightFright pointed out, changing the BSP content isn't desirable here; shifting brushes around isn't an option if you don't want to break existing multiplayer and demos.

Reimplementing the Quake software renderer in GPU compute sounds like an interesting challenge for someone with the requisite skills (i.e. not me), like how ParaLLEl N64 took the highly accurate, low-level N64 software renderer "Angrylion" and implemented it in Vulkan compute. 

Update released. This takes care of the broken Knight/Shub animations, the missing sound loop for drone6.wav and should fix (hopefully) pretty much all the z-fighting instances in all ID1 maps + mission packs (unless I missed any, but I tried to be thorough, even checking secrets).

As a bonus, QuakeC source for the progs.dat files are also included.

Download Rev.2 (4.3 MB)
See readme for details 

Nice one!

A very niche bug exists in the ID1 Start map (and others). This map doesn't have a Quad Damage pickup, so if you do an impulse 255 you'll get a "items/damage2.wav is not precached" warning when the Quad wears off, as it's not able to play it's usual sound.

I've worked around this in engine code in the past by just adding this sound to the precache list (if it's not already in it) in SV_SendServerinfo.

I'm not even sure if it should be worked around in QC as it's supportive of a cheat, so I'll leave it up to you. 

Your sndspeed variable would have to be set to "44100" to profit from this. Mark V-WinQuake has a dedicated entry in config.cfg, while for Quakespasm you would have to add this line in your autoexec.cfg: sndspeed "44100" 

Please adjust the download link above (#25) from qvan_fixes-r3.zip to qvan_fixes-r3a.zip. I forgot to include the license from the Quake Remaster which seems to be kinda necessary to be able to redistribute the sound files. 

posted by NightFright on 2021/08/20 08:53:46
Timing is everything! QTest sounds out, Quake Remaster sounds in. Now not just a few sounds are replaced/improved, but all of them - including the mission packs.

Download Rev.3a (38.6 MB)
See readme for details
 

Sorry we don't have a way to edit posts, but i reposted with the correct URL and hid the original post #25 

I am really missing an editing feature here, especially since you cannot update d/l links in the OP like that. But well, that's the way it is. 

This is cool stuff!

Have you looked at this QC solution to the rune loss bug?

https://tomeofpreach.wordpress.com/2015/09/30/fixing-runes-and-restart-with-qc/ 

I have seen it, yeah. Never ran into a situation like that, though. 

Two progs.dat fixes:
- Losing runes when saving and restarting game
- Support for new DOPA ep.5 ending text from Quake Enhanced

Download Rev.4 (4.3 MB)
See readme for details 

I have one report that the silver key in hip1m4 (Research Facility) might not spawn reliably every time with these fixes.

Maybe someone could test that to confirm? Interesting would also be to test with original pak files vs those from the re-release. In general, I do not recommend using this with the re-release since maps and code have been significantly altered. Besides the fact that you simply wouldn't need any fixes, then. 

I just quickly tested this in vkQuake, Quakespasm-Spiked and also Mark V WinQuake. What I did several times was: map hip1m4, notarget, noclip and fly to the room with the silver key.

On Easy it spawned all the time. On Normal it sometimes does not spawn. On Hard it managed to not spawn three times in a row.

Since there's no .ent file for this map, issue is somewhere else? 

Doing the same with the rerelease's hipnotic pak0 file (and obviously without the QVan fixes pak) seems to not have this issue. 

There is a suspicion that QSS introduced this problem between Aug 20 and now in its dev builds, but if it also happens with other ports, the origin of the issue must be the mod. The QuakeC code, to be more specific, since hip1m4 doesn't have a custom ent file.

Maybe someone can check the included source files and see if there is any edit that could cause this issue? I am not aware of any change right now which could cause trouble.

Additionally, other SoA maps should be checked, also for gold key behavior, and DoE on top of that just to be on the safe side.