qbismSuper8 builds

[qbism]

OK, I've just removed the newer link with fixed frames as well. All the 'fix' is, though, is to open and resave each mdl in Quark. That's it! Screenshots from MFX's ad_crucial with a custom palette:

[Baker]

[sock]

Its cool I understand that mistakes can happen, please just be careful what everyone releases as a fix/patch because there is a plenty of people just downloading stuff and not understanding what else it does.

I am in the process of creating a second patch to address the WinQuake client issues for the MOD. I am working at the moment with Bengt and his engine and will be testing Bakers winquake client at some point (which I was surprised to learn about, damn as always!)

I know the models I have made don't work well with WinQuake clients and I am trying to find a method I can use to fix the bugs in one update. So I have tried re-saving the models with and and both methods still produce weird tearing on the top of the models. This mostly happens when the model is part out of view. Is this fixable? is this some common problem with WinQuake clients? Does anyone have another method to fix these models?

Another WinQuake related fix: I have enabled a way (via quake.rc) to disable all fog update/trigger functions from the MOD because WinQuake clients usually don't support fog. One of the new features of the mod is fog changes via triggers and I am sure it will cause problems if the trigger is constantly trying to change the fog and the console command does not exist.

If anyone has assets fixes for the MOD, please let me know so I can include it in the next patch. It does not help if everyone is producing different patches and not testing them with all the other stuff in the MOD.

Thanks for any help

[Baker]

Sock: "OMG! WinQuake how could I forget you! MarkV Winquake from Baker, #quake pixel heaven!"

Thanks! I went all out on that to produce an equivalent WinQuake version of Mark V with the entire feature set of Mark V FitzQuake.

Doesn't support: Does not support colored lights or fog (Mankrip, super8 do support those), does not support external textures. Doesn't support alpha entities or alpha masked textures. super8 supports both, I believe.

Does support: Nehahra. So does Mark V FitzQuake. Also should entirely ignore fog messages.

(My goal was different than those of Mankrip and super8, I just wanted standard WinQuake that could play any map Quakespasm and Mark V could play).

[Baker]

[qbism]

MarkV Winquake: Glad someone made this. I haven't looked at it yet, but I expect many players will enjoy it, and the original MarkV thoroughly commented source has been a great reference.

Progs mdls: Problematic files seem to be 'fixed' for winquake derivitives, with all skins intact, by open/save in Quark.

That alone doesn't tell us if it's a file format issue or an engine issue. The fact that winquake explodes rather than self-correcting or gracefully exiting with a message is itself an engine problem.

[Baker]

[sock]

[qbism]

The results below are from re-saving ALL the mdls in Quark 6.6.0 beta 7. The tearing may not come directly from the model in view, although it is a common factor in DM4 and the AD start map. Duplication of ericw's DM4 screenshot, AD start with rocket ammo centered in far distance, and demonstration of multiple skins functioning in ad_test11:

[qbism]

[Spike]

the gl renderer reorders verts to generate strips or fans in order to reduce the amount of vertex processing needed by the gpu. this isn't the bottleneck for gl any more, making it kinda redundant - modern hardware is much happier with a single glDrawElements call with a triangle list than it is with multiple glBegins with random strips and fans, older hardware prefers a glDrawElements with a single strip(with degenerate triangles for discontinuities). the whole strips-and-fans thing is utterly pointless for anyone with access to gl1.1.

the software renderer just transforms them all in one go right at the start, and then has enough cpu cache to not care about order any further. reordering won't do much.

have you tried validating the per-pose bounding boxes that are used for trivial accept/reject checks? you could always just calculate them yourself if you don't trust the exporter, or just set them to their min+max values at load. these and degenerate triangles are the only two things I can think of that might have this sort of issue, q1 mdls are really quite simple if you ignore the whole faces-front thing (yay q2?).
the only other thing would be triangles with invalid verts, but I'd like to think that at least one engine would have complained about that.

[qbism]

[Spike]

I meant frames[i].bboxmin + frames[i].bboxmax

I just added some trivial checks for the bboxes within my own engine. while the frame names are set, the frameinfo->bboxmins.v and frameinfo->bboxmaxs.v values appear to all be 0 with AD's models, while vanilla models like the player model have correct values.
This is exactly the sort of thing that will glitch out software renderers.

[ericw]

Sounds like we're on the right track, but not quite there...

I have been playing with v_shadaxe0.mdl (the axe viewmodel, assuming you don't pick up axe upgrade).
The per-frame mins/maxs are all (0 0 0). However, setting these properly didn't fix the glitching with MarkV Winquake (unless I screwed up somewhere) - but this matches your observation, qbism.

I also confirmed that resaving v_shadaxe0.mdl in the latest version of Quark DOES fix the glitching in MarkV WQ.

I'm confused because:
- QuArK's fixed mdl has the same # of verts and tris as the original broken one.
- I hacked Preach's qmdl python script to check for degenerate tris, and didn't find any. Also, if QuArK was deleting degenerate tris, I'd expect the number of verts or tris to be different.

[ericw]

The problem turned out to be onseam set to 1 instead of 32. This clobbers some internal flags in software quake, messing up the clipping.
http://www.celephais.net/board/view_thr ... &start=755