Nice to see this type of vanilla patch.

I came in to ask if you incorporated the fixes from "Ultimate Regular Quake Patch" and then saw your reference to Quake Info Pool in the readme. Does this mean you fixed "all" of the bugs from QIP... or at least, most of them? 

What was marked as fixed in QIP should be fixed here as well, at least for ID1. That and some more, actually. I implemented as many progs.dat fixes into the mission packs as I was able to, but it's nowhere near the thoroughness of the main game. Then again, many vanilla bugs had already been fixed in the mission packs, and most of them you'll never notice.

More important are the map fixes solving broken spawns. It's beautiful to see SoA's "The Edge of Oblivion" work properly for the first time. That tunnel on the top is a Spike Mine spitter, triggered by up to five touchplates scattered throughout the map. In general, you'll see Spike Mines more often now in SoA since three maps had their spawns so screwed up they basically didn't appear.

Btw, there's going to be an update next week since I realized one of the QTest sounds (drone6.wav) was missing sound looping, preventing it from being played ingame. Fixed that already plus added more map fixes to solve z-fighting, taken from Quakespasm's custom pak. 

Gonna check it out! Meanwhile a bit of useless nitpicking, going through the readme:

> - Note #2: Full E2M6 from QTest was intentionally *NOT* used due to the large amount of entity differences.

I think you mean BETA3/Pre-Release, not QTEST.

> V. 34 better quality sounds taken from QTest (aka Quake Beta3)

And in here I think you DO mean QTEST :) 

Ah cool, I was just about to ask about the z-fighting fixes. I'm not sure the QS pak file has all of them... And can ALL these z-fighting instances be fixed just with .ent files? 

Possibly, but I am not an expert regarding that. There aren't many people around these days who would take the time to do such things. I am sure there are occurrences in the mission packs as well, but apparently nobody ever bothered looking into it.

Anyway, fixing everything is impossible, anyway, and you have to draw the line somewhere. Maybe I find more later on, but right now it's already quite a lot, I would say. 

R2M3: Fix for Lavamen dropping through their pools to the floor below in QSS.
Great! Thanks! 

This is a case that should be handled by the port, though. It isn't happening in regular Quakespasm, for example. Anyway, I doubt it will do any harm to have a map fix in place for the time being. Shouldn't break if QSS ever receives an update for this, either.

BTW regarding z-fighting fixes: Apparently KillPixel had published a project called Z-Fixed Quake back in 2013. According to his own accounts, he found and fixed almost 200 (!) cases of z-fighting in the original ID1 maps. Compared to that, the Quakespasm fixes are barely scratching the surface.
However, both KillPixel and this project have vanished and I gotta work with what I have. I still believe they fixed the most obvious and annoying glitches in the custom Quakespasm pak, so it's better to have that than nothing. 

Wow, that's really cool, I had no idea it existed. It appears he first started it in 2012, then abandoned it for a year, then returned to it. He not only went to fix the z-fighting issues, but also misalligned textures, entity bugs, and some geometry problems. He also did it by editing the id1 .map sources that John Romero released in 2006 and compiling them in new .bsp files.

Luckily someone mirrored that pack and the Dropbox download link still works! Check out this post: https://quakeone.com/forum/quake-mod-releases/finished-works/12797-hgsz-s-retro-quake-glsl-retro-shaders-for-darkplaces?p=245292#post245292

The Dropbox download link: https://www.dropbox.com/s/b0m3dp1kymkabif/KillPixel%27s%20z-fixed%20maps.pk3?dl=0 

Yeah, but the catch is this: KillPixel altered the maps to such an extent that they break online gaming, demos... basically anything vanilla-related. That's not what I want this to be about and we don't have to get EVERYTHING fixed in a totally obsessed manner. A lot of this stuff you won't even notice.

I can take a look still and see if there's anything useful in there, but I will absolutely NOT just blindly integrate this into my project. 

Of course. One useful thing might be numerous .ent fixes for the z-fighting that can be extracted from these .BSP files. 

In the meantime, I found out that my progs.dat fixes broke the walking animation of the Knight and possibly the shaking anim of Shub. Those duplicate frame macros (attackb1, shake12) were there for a reason, shouldn't have removed them. Anyway, it's corrected and will be part of the update.

Right now, I am going through all ID1 maps manually to track down fixable z-fighting occurrences. Found 25+ really visible ones on top of those that come with the custom Quakespasm pak. A lot of testing is involved here, basically I do everything on my own since KillPixel's stuff proved to be almost useless.

Not all cases will be fixable, though. Where brushes instead of entities are screwed up (e.g. a wall from lower floor clipping into the ceiling, such as on the walkway in E2M1), you would have to edit the map and I won't do that. Still, after my ent fixes, z-fighting should be really rare. And yes, I'll also check SoA and DoE. 

> manually to track down fixable z-fighting occurrences

How are you doing that? Using Mark V's tool_inspector?

> E2M1

I always wondered why on Hard skill there's telefragging happenning in that map... Now I know, the trigger activates 4 enforcers and they walk into teleporter one after another, causing this. I wonder if it was done intentionally or just left as is because it was funny. Also, can this be fixed by adding some relay entity to activate two of the four enforcers with a delay? 

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.