qbismSuper8 builds

probably not. Throwing fog into D_DrawZSpans would break fog on models, requiring fog to be calculated there too.
That said, calculating fog with a single depth value is generally unreliable if you have something transparent shown (and thus logically two depth values for a single pixel), so it might be something you want to do anyway. But it likely won't be faster.
That said, doing fog as part of the span might allow interpolating the depth value across the span, instead of recalculating for every pixel. With a planar line of pixels, depth is a little more predictable.

I tried doing the z-buffer post-process fog trick in hardware, but it ended up being slower there and the alpha issue existed there too.

String comparisons. Here's a trick for you.

An awful lot of these come from looking up commands and cvars in their respective lists. Vanilla Quake is awful for this. If something needs to set a cvar directly (through Cmd_ExecuteString rather than through Cvar_Set) it first does a linear walk through the entire list of commands, finds that it's not there, then does a linear walk through the entire list of aliases, finds that it's not there, then does a linear walk through the entire list of cvars (and hopefully finds it). If you've added extra cvars or commands yourself it only adds to it.

When you've finished registering all cvars and adding all commands (somewhere at the end of Host_Init is good) build another list of all cvars, commands and aliases. This list should contain a struct, one member is the name, another member is a pointer to the original. Sort that list by name. When a new alias gets created or an existing one is removed destory, rebuild, resort. In Cmd_ExecuteString do a binary search instead. Retrieve the pointer to the original and push that through to the correct handling function.

Cvar_Command does two linear walks through the list - one in Cvar_FindVar and one in Cvar_Set. You can remove the second - even if you don't do the binary search thing - by making a Cvar_SetDirect that takes a pointer to a cvar_t as it's first arg instead of a string. If you do the binary search then both go away. Cvar_SetDirect is also a good replacement for anywhere else in engine code that issues a Cvar_Set.

The list for binary searching is also great to use for autocomplete partial matching, so you get a double win from this.

probably not. Throwing fog into D_DrawZSpans would break fog on models, requiring fog to be calculated there too.
That said, calculating fog with a single depth value is generally unreliable if you have something transparent shown (and thus logically two depth values for a single pixel), so it might be something you want to do anyway. But it likely won't be faster.
That said, doing fog as part of the span might allow interpolating the depth value across the span, instead of recalculating for every pixel. With a planar line of pixels, depth is a little more predictable.

These are the best alternatives I've ever seen.

Also, for alias models, particles and sprites, you could calculate the fog level only once, based on the entity's origin. For alias models and oriented sprites it wouldn't be as perfect, but would surely work a hell of a lot faster.

This is as efficient as I can get it at the moment. I tried a simple interpolation between an "oldlevel" and "newlevel" in pixel strips, but it made forground objects jaggy and didn't improve performance. Interpolation would look better while drawing spans (as Spike mentioned) because we know where the edges are. Even there, it might be difficult to improve performance, counters/fractions vs. look-up tables. In R_RenderView:

  Code:

    static float previous_fog_density;
    if (fog_density && r_fog.value)
    {
        dither=0;
        if(previous_fog_density != fog_density)
            FogDitherInit(); //dither includes density factor, so regenerate when it changes
        fogindex = 32*256 + palmapnofb[(int)(fog_red*164)>>3][(int)(fog_green*164) >>3][(int)(fog_blue*164)>>3]; //qbism -fractional value, bright fog is harsh
        for (y=0 ; y<r_refdef.vrect.height; y++)
        {
            pbuf = r_warpbuffer + d_scantable[y+r_refdef.vrect.y];
            pz = d_pzbuffer + (d_zwidth * (y+r_refdef.vrect.y));
            for (x=0 ; x<r_refdef.vrect.width; x++)
            {
                xref = x+r_refdef.vrect.x;
                level = (int)( *(pz + xref) * ditherfog[dither++ % DITHER_NUMRANDS]);
                if (level < 32 && level >= 0)
                    *(pbuf + xref) = fogmap[*(pbuf + xref) + (int)vid.colormap[fogindex + level*256]*256];
            }
        }
        previous_fog_density = fog_density;
    }

Fog is generally a fixed-rate hit. It's going to have "x milliseconds per frame" hit that is dependent on screen resolution, not geometric complexity. High-res combined with simple outdoor scenes looks bad in performance, 30% reduction in FPS. saint.bsp in low-res looks good, only a 15% hit. In fact, R_RecursiveClipBPoly consumes more time than both DrawSpans8 and R_RenderView in complex scenes at low resolution. I've uploaded this to SVN for you all to improve!

New build with the global fog from above, MMX,SSE optimizations, and an added bonus, v_gunkick (0 = off, 1 = normal, 2 = double, etc.)
http://super8.qbism.com/wp-content/uploads/2012/05/qbismS8_0079.zip

Framerate independent physics was removed. It caused problems for intentionally low cl_maxfps on fast machines. (Fast in this context is 1.6Ghz dual core) Thanks to physics fixes, should be fine without it. Now set to 72 fps. Probably there was more to be done to complete framerate independence, maybe just shut it down below X fps.

fyi it fails on pentium mmx with a crash during initialization

fyi it fails on pentium mmx with a crash during initialization

no surprise, P2 < P4. Would be nice if exe could detect and use available features or not.

Build 84: http://super8.qbism.com/wp-content/uplo ... 8_0084.zip

Turned off processor optimizations. It will run on an Atom again, maybe also a P2.
vid_stretch_by_2 has returned!
Some particle stuff ripped from Engoo, especially sticking to walls and floors.
A few r_part_* cvars added to adjust particle aspects. r_part_scale is a fun one.
Added sky and wateralpha worldspawn keys, untested. wateraplpha in worldspawn is probably a bad idea

EDIT: Another build coming soon with particle fixes-
Tracer particles (wizard trail) aren't showing.
Offset sticky particles slightly from surfaces to reduce z-fighting.
r_part_sticky_time will work.

Build 85, fixes to the previous build per above:
http://super8.qbism.com/wp-content/uploads/2012/05/qbismS8_0085.zip

http://dl.dropbox.com/u/1776436/quake00.pcx

can see through the map in e1m1 secret area near the megaheatlh in the water.

Dont know if its a known issue.

Let me know if you need more information.

I didn't know about the see-through area, and I wasn't able to duplicate it. Is it visible in that whole general area of the map, or just specific place or direction? Have you noticed this effect on other maps? Could you tell me your computer type/CPU/OS? And if you have the time, a demo file might help. Thanks!

You guys should check this flQuake engine. It has bilinear-filtered software rendering.

That's pretty standard when you're crossing a waterline - happens in GLQuake too, it's an old old old content bug.



If you re-vis your maps for translucent water it will go away.

It's possible to sorta-kinda fix it with some jiggery-pokery engine-side (merging visibility for two viewleafs if you detect a contents change between them) but I'm not certain how robust it is.

near clip planes mean you can 'reliably' see both sides of the water line despite being one specific side. The proper solution really is to do some sort of fat pvs with radius equal to the near clip plane.
sadly you'll have the same with certain tracelines/chasecam mods at certain angles/corners, and those involve empty/wall areas.
Many games will clip the viewport to be at least a specific distance from the water plane. This would also be a valid fix. might even work for chasecams too, if you can find a valid empty spot... Either way you're finding all surfaces or leafs or something within a sphere surrounding the viewpoint.
watervis is an alternative, but can potentially be quite expensive in overdraw (on older cards, anyway). it does allow transparent water surfaces too though, so you'd probably want this anyway.

the q2-esque hack where it looks above/below the viewpoint for additional nodes depending on the current water type generally works for regular water, but can fail for the underside/vertical sides of water. in the case of the underside of water, you've a worst-case bug on one frame or so before the player drops right through. in the case of vertical walls of water, generally such water is used only for waterfall type stuff, and always looks wrong anyway. either way, its generally thin (to hide weirdness at the sides) and stuck to another wall so you can't get within the middle of it anyway, so can never see the issue. Also, I don't recall any such vertical water brushes in vanilla content. Just the weird pool on start.bsp
thus the q2-esque hack works just fine for any situations that I can think of.

You guys should check this flQuake engine. It has bilinear-filtered software rendering.

It's too slow, about 10 fps on my main computer. Makaqu runs from >50 to 72 fps on this same machine.

It's a nice experiment, but for actually playing the game, if texture filtering is really desired then I'd recommend using a hardware-accelerated engine instead.