News | Forum | People | FAQ | Links | Search | Register | Log in
Vanilla Quake Fixes Pack
Your starter pack for a smoother and (hopefully at least more or less) bug-free vanilla experience has arrived! This is a large collection of fixes for vanilla Quake and its mission packs, covering models, maps, code (progs.dat) and sounds.

Contains quite a few fixes that have never been published before (personal highlights: Floating zombies in E4M7 start area, broken Spike Mine spawner in HIPDM1, music fix for HIPDEMO1).

UPDATE Aug 30, 2021: Rev.4 released

Download Rev.4 (4.3 MB)
See readme for details
First | Previous | Next | Last
 
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. 
KillPixel's Z-fixed Pack 
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. 
Yeah 
Of course. One useful thing might be numerous .ent fixes for the z-fighting that can be extracted from these .BSP files. 
Status 
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? 
Congratulations 
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. 
#14 
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. 
Doh 
Forgot to post screenshot of console with Edict #207 information:

http://gila.deathmask.net/various/mark_v_tool_2.png 
E2M1 Telefrags 
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. 
Thoughts 
@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? 
Signage 
Obviously I meant DX<12 :P 
Z-Fighting Fixes 
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. 
Progress 
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. 
Content Bug 
@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. 
Rev.2 Released 
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. 
Small Note 
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" 
If Anybody Can Edit Posts 
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. 
Rev.3 Released 
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
 
Nightfright: 
Sorry we don't have a way to edit posts, but i reposted with the correct URL and hid the original post #25 
Alright 
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. 
Rune Loss Fix? 
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/ 
1 post not shown on this page because it was spam
First | Previous | Next | Last
You must be logged in to post in this thread.
Website copyright © 2002-2024 John Fitzgibbons. All posts are copyright their respective authors.