qbismSuper8 builds

Discuss programming topics for the various GPL'd game engine sources.
qbism
Posts: 1236
Joined: Thu Nov 04, 2004 5:51 am
Contact:

Re: qbismSuper8 builds

Post by 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:
Image
Image
Baker
Posts: 3666
Joined: Tue Mar 14, 2006 5:15 am

Re: qbismSuper8 builds

Post by Baker »

sock wrote:
qbism wrote:Also the files are smaller after this.
Updated progs mdls zip: https://qbism.com/download/file.php?id=29
Baker wrote:You might let Sock know about that
Qbism, seriously man this is not how you fix stuff!
qbism's will is good, engine modification and engine support often involves mistakes. It's sad, but true. Even very conservative engine modders like myself --- or hell even metlslime --- FitzQuake used to have some nasty bugs and MH (mostly) and myself (less than MH) managed to track them down.

So consider supporting your well-intentioned engine modder! He cares! And probably has very limited time and holiday obligations and such.

And Sock, congrats on the monster release! Unbelievable! And shockingly huge in scope! :!:
The night is young. How else can I annoy the world before sunsrise? 8) Inquisitive minds want to know ! And if they don't -- well like that ever has stopped me before ..
sock
Posts: 137
Joined: Thu Aug 23, 2012 7:16 pm
Location: Wandering Around
Contact:

Re: qbismSuper8 builds

Post by 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 amazing stuff 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 QME and Noesis 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
Well he was evil, but he did build a lot of roads. - Gogglor
Baker
Posts: 3666
Joined: Tue Mar 14, 2006 5:15 am

Re: qbismSuper8 builds

Post by 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).
The night is young. How else can I annoy the world before sunsrise? 8) Inquisitive minds want to know ! And if they don't -- well like that ever has stopped me before ..
Baker
Posts: 3666
Joined: Tue Mar 14, 2006 5:15 am

Re: qbismSuper8 builds

Post by Baker »

sock wrote: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 amazing stuff 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 QME and Noesis 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.
A. Baseline -- great choice

Bengt Quake is probably the best "base-line" to use. It's a pretty standard WinQuake that can do enhanced limits. It's a bit crusty, but might very well load almost any modern map due to the Bengt's protocol 10002. (Ironically, Mark V can play back 10002 demos. Warpspasm's startdemos were protocol 10002 and I wanted them to play.)

B. Models

qbism is the guy that knows. When I get time --- but this could be many months out --- I know I'm interested in fixing this issue in WinQuake and posting the fix here, but I just don't have any time right now.

So either mankrip or qbism or someone else would be the only option for a timely manner fix in the engine code. (And the software renderer is like a maze, it's not like GLQuake or FitzQuake where things are nice and simple).

Probably the best option is to look at qbism's newest model fixes for a quick and dirty solution.
The night is young. How else can I annoy the world before sunsrise? 8) Inquisitive minds want to know ! And if they don't -- well like that ever has stopped me before ..
qbism
Posts: 1236
Joined: Thu Nov 04, 2004 5:51 am
Contact:

Re: qbismSuper8 builds

Post by 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
Posts: 3666
Joined: Tue Mar 14, 2006 5:15 am

Re: qbismSuper8 builds

Post by Baker »

qbism wrote: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.
It isn't a very good tutorial engine, unlike the original Mark V. However, it does a CodeBlocks project, a vc6 one and a VS2008 one and does ASM in all 3!

It does have several dozen new features, but the engine is so conservative it is almost impossible to notice them.

For instance, it has context aware auto-completion of everything in a way not even Spike has including in-line multiple commands (i.e. after a semi-colon for example) and has undo and cutting/pasting in the console (hold down shift and select text and do CTRL-X, etc.) ALT-ENTER toggles full-screen with memory, entirely rewritten video and input code. Has automatic underwater transparency detection. Has .png screenshots, but no external dependencies. Plays .dz demos but has no external dependencies. Has cutscene protection, you'd have to play Zerstorerer or Nehahra in another engine first and then try them in Mark V. Any fov your gun looks the same. The frame interpolation is reversible, I know you have demo rewind. :lol: It loads skyboxes and palettizes them instantly, doesn't matter if the skybox is stupid big like 1024 x 1024. Loads Half-Life maps. Applies your brightness and contrast settings to all the screenshots and provides a command "showfile" to show the file in Windows Explorer (or the Finder on the mac).

There is a levels menu in single player, a demos menu in multiplayer and they both look built-in. Has auto-demoing, automatic save games. There is a Mac version.

It actually can install mods. Like type "install honey" or "install zendar1d" in the console, then do -game honey and then single player new game (it has automatic start map detection too).

You can load another engine, exit it stomping config.cfg Mark V wrote. You start up Mark V, it stills load your last config :lol:

It's a totally insane engine. But it's so incredibly conservative and deceptive about it. It's the ultimate trojan horse engine.
The night is young. How else can I annoy the world before sunsrise? 8) Inquisitive minds want to know ! And if they don't -- well like that ever has stopped me before ..
sock
Posts: 137
Joined: Thu Aug 23, 2012 7:16 pm
Location: Wandering Around
Contact:

Re: qbismSuper8 builds

Post by sock »

qbism wrote: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.
I downloaded/installed Quark and open/saved a model to see if it fixed the polygon tearing issues and no, its still broken. Quark is not the solution it seems. I suspect it might be connected to the way the skin is setup, I used a modern setup and not the original quake model projection method. The old WinQuake client might be expecting the skin/verts to be setup in a certain order.
Baker wrote:It loads skyboxes and palettizes them instantly, doesn't matter if the skybox is stupid big like 1024 x 1024.
When I first loaded Zendar and saw the sky it was perfect! The best WinQuake feature I have seen in a long time, it looked so modern and retro all at the same time. The icing on the cake was the auto-complete everything, so wish more engines had this, it should be a standard for any engine!
Well he was evil, but he did build a lot of roads. - Gogglor
qbism
Posts: 1236
Joined: Thu Nov 04, 2004 5:51 am
Contact:

Re: qbismSuper8 builds

Post by 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:
Image

Image

Image
qbism
Posts: 1236
Joined: Thu Nov 04, 2004 5:51 am
Contact:

Re: qbismSuper8 builds

Post by qbism »

sock wrote:The old WinQuake client might be expecting the skin/verts to be setup in a certain order.
Yes, and there is only minimal error-checking. The goal is to jam the file into memory representation with minimal processing for our 1996 DOS P60 computer. The exporter program has a large burden. This is reason #82 why coding with the quake2 software renderer is so much more smooth... in q2 the skins are separate files.

The gl renderer unpacks the mdl pieces and resorts it for the GPU. Somehow this may be more robust (or is there an example of a mdl that works in SW but not GL?) I don't know the specifics of this. One path may be to incorporate this into software quake, then wash/rinse/dry/repack it. Yet would this unintentionally break some other mdl, maybe something from an ancient mod?

And there are realms of retro some may not know. People using Watcom compilers. People compiling and playing on DOS: http://www.vogons.org/viewtopic.php?f=24&t=39878 The super8 color algorithm is skinny enough for DOS and it looks not-too-bad on a CRT, but nobody appreciates the weak state of overbrights.
Baker wrote:There is a levels menu in single player, a demos menu in multiplayer and they both look built-in. Has auto-demoing, automatic save games. There is a Mac version.

It actually can install mods. Like type "install honey" or "install zendar1d" in the console, then do -game honey and then single player new game (it has automatic start map detection too).
Brilliant and subtle features like contextual key binds (guess that's what it might be called :lol: ). As an example, when playing back demos, rewind/ pause/ ffwd intuitively map to the arrow keys.
Spike
Posts: 2914
Joined: Fri Nov 05, 2004 3:12 am
Location: UK
Contact:

Re: qbismSuper8 builds

Post by 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
Posts: 1236
Joined: Thu Nov 04, 2004 5:51 am
Contact:

Re: qbismSuper8 builds

Post by qbism »

Spike wrote: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.
I added a bounds calculation (below) and also looked at min/max range vs vanilla progs. The range was similar, -72 to +48 looking at all vertices of all models in maps without monsters. I was optimistic because I noticed that ammo boxes and lids would get culled well before hitting the edge of the fustrum. But the crash persisted. Most perplexing bug I ever saw. As far as tris, FTE did not complain in developer mode :wink:

Code: Select all

        near bottom of Load_AliasModel ...
.
.
.
else
        {
            pframetype = (daliasframetype_t *)
                         Mod_LoadAliasGroup (pframetype + 1,
                                             &pheader->frames[i].frame,
                                             pmodel->numverts,
                                             &pheader->frames[i].bboxmin,
                                             &pheader->frames[i].bboxmax,
                                             pheader, pheader->frames[i].name);
        }

//qb: bounds set begin
        for (j=0; j<3;j++)
        {
            mod->mins[j] = 999999;
            mod->maxs[j] = -999999;
        }

        //process verts
        for (j=0; j<pmodel->numverts; j++)
        {
            for (k=0; k<3; k++)
                v[k] = poseverts[i][j].v[k] * pmodel->scale[k] + pmodel->scale_origin[k];

            for (k=0; k<3; k++)
            {
                mod->mins[k] = min(mod->mins[k], v[k]);
                mod->maxs[k] = max(mod->maxs[k], v[k]);
            }
        }
        //bounds set end
    }

    mod->type = mod_alias;
Spike
Posts: 2914
Joined: Fri Nov 05, 2004 3:12 am
Location: UK
Contact:

Re: qbismSuper8 builds

Post by Spike »

I meant frames.bboxmin + frames.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
Posts: 92
Joined: Sat Jan 18, 2014 2:11 am

Re: qbismSuper8 builds

Post by 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
Posts: 92
Joined: Sat Jan 18, 2014 2:11 am

Re: qbismSuper8 builds

Post by 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
Post Reply