qbismSuper8 builds

[ceriux]

thats a lot of hellknights.

[qbism]

It's negke's amazing Ascending And Descending, first map in at least a year, but there's so much mapping going on that the news is already knocked off func_msg front page.
http://home.arcor.de/negative/

[Baker]

I don't know if you are still having buffer over-run issues, but concept this *might* help you.

Code: Select all

byte* base = [Insert where you are writing]
void* sentry0 = &base[0];
void* sentry1 = &base[sizeof(base) - 1] or &base[high - 1];

.
.
#ifdef _DEBUG
    if (  (sentry0 <= writepos && writepos <= sentry1) == 0)
      Con_Printf ("$FUNCTION_NAME:  writepos out of bounds\n");
#endif

You could probably set this up in some of the key areas in less than an hour. Just a thought, I used this technique yesterday out of paranoia against some lightmap changes I made.

[qbism]

Thanks, I may try it with my friend rowptr[] in D_WarpScreen to see if it's behaving.

[leileilol]

I'd suggest dropping the current strange z-reading fog method for the fogmap-on-the-spans method if you're wanting speed.

[qbism]

Indeed fog is taking 30% framerate hit. It is a post-process effect with an if statement for every pixel.

[qbism]

...but putting it in spans trades the overhead of looping through the buffer with the overhead of overdraw. And we do like to put a lot of particles on the screen. Dithered fog is an expensive alpha/dither/depth filter which makes overdraw a killer. Regardless of the delivery method this algorithm really wants to get more efficient.

[leileilol]

You could calculate the particle's fog before the drawing and intercepting swapping the particle color with the fogged color instead so you could even fog up the assembly particles

The hardest will be trying to fog the model spans

I don't really see the huge overdraw issue for performance when doing it along in the spans' z. Is your fog table even 64 rows? You could prototype your spans fog first with the colormap (going from overbright to black) and then attempt to make a fogmap function which is just generating a colormap that blends to a fog color from the given fog parameters (and generate this on every fog command)
This is what i've done and it seems to work well for me. I don't see fogged spans worse than getting lighting on a model, and trust me, I really like to put a lot of particles on the screen (my particle limit right now is 16384)

[qbism]

This is the guts of "post-process dithered fog". I pulled more math out of the inner loop since the previous version, which reduced the framerate cost to about 25%. Can't seem to escape float multiplication and range check. Expensive, but it really blends the fog nicely within the 256-color limitation. Likely the bulk of the cost would remain even if it moved to a different strategy such as ditherspans.

Code: Select all

        for (yref=r_refdef.vrect.y ; yref<(r_refdef.vrect.height+r_refdef.vrect.y); yref++)
        {
            pbuf = r_warpbuffer + d_scantable[yref];
            pz = d_pzbuffer + (d_zwidth * yref);
            for (xref=r_refdef.vrect.x; xref<(r_refdef.vrect.width+r_refdef.vrect.x); xref++)
            {
                //qb:  [edit to original post] wrong place!  pbuf++;
                //qb:  [edit to original post] wrong place!  pz++;
               
                if(*pz) //qb:  0 is sky.  Assumption is that mapper's sky selection looks appropriately foggy
                {
                    level = (int)(*pz * ditherfog[dither++ % DITHER_NUMRANDS]);
                    if(level <31)
                        *pbuf = fogmap[*pbuf + vid.colormap[fogindex + level * 256]*256];
                }
               pbuf++; //qb: [edit] right place!
               pz++;//qb: [edit] right place!
            }
        }

So we're looping through the screen buffer (pbuf) and the depth buffer (pz). Sky pixels are discarded. 30 usable fog levels, or depth slices, are available to pixels that remain. After z-dithering, pixels above the 30 limit (weak fog near the viewer) are discarded. Finally if we made it this far, we look up the fogmap color index and replace the screen buffer pixel with it. Because this is a post-process referencing only color index and z-depth, it doesn't matter how each pixel was created, whether world geometry, models, sprites, particles, or transparency.

[leileilol]

The blocky fog is the spans fog (which is relatively fast *nudge nudge nudge nudge*) while the sharp accurate fog is zbuffer-reading fog (which is horribly slow and is similar to your fog). In more subtle fogged maps you won't even notice the blocky imprecision of spans fog. I have also dithered the fog, but not with noise. You can easily tell this is DrawSpans16 i've put fog on given the 16 pixel step of the depth

and fyi this zbuffer reading fog is a reworked version of the elusive unused ApplyFog function from FTEQW's abandoned software renderer to use with my fogmap that I use with spans fog. I tried to make Laser Arena-esque improvements to it with dither. Considering Laser Arena's performance I believe they also have slow Z-reading fog, plus their sky is fogged.

Plus with spans fog, if you don't want to fog the sky, then simply don't edit the sky spans!

Another thing that can be tried is dithering the model's shading. It can be done effectively, though that has no relevance on supporting new features for mappers

my point is since you have an engine with a mission for more without heavy performance compromise (weird colored lighting method withstanding) I suggested spans fog like here as an alternative. It might work out for the heavily unrolled c loops you have going more than it does for me

[mankrip]

Here's a more brutal method: rewrite large portions of the renderer to make it draw the scene in "slices". And then draw each slice over each other, in a way similar to the translucent water overdraw.

Each slice would correspond to a certain fog level. This way, nothing would have to be calculated during the rendering - all the renderer would have to do is to get the fog color of the current slice and blend with the color of the pixels during the rendering.

I do believe this is the fastest method that could ever be possible. But it would require a significantly deeper understanding of the renderer as a whole.

[Spike]

you mean spans?

[mankrip]

No, not spans. I mean actually cutting the 3D scene several times. The software renderer has the potential for that.

It's been a little while since I've worked on the BSP renderer, but it should be doable by setting up a "minimum distance" plane and a "maximum distance" plane to define the limits of each slice. The BSP renderer already cuts the scene's polygons in real time to avoid overdraw, so we would be just making it cut more.

[edit] By the way,

all the renderer would have to do is to get the fog color of the current slice and blend with the color of the pixels during the rendering.

... this color blending could be done in the color shading map itself, thus also eliminating this step. The turbulent spans drawing functions would have to be modified to use a fog color map, though.

[Spike]

it should be easy enough to move the far clip plane to be the distance at which the fog is considered fully opaque (assuming you use a fog formula where that distance is well defined, or at least sufficiently opaque that it is within rounding errors). that would reduce the number of spans etc needed.
splitting the world up into depth-based 'slices' is likely going to result in terrible looking fog. I'm not sure you'd save much.
as spans are drawn in 8 or 16 pixel chunks, you can just use a single fog factor for each chunk, so you go from one depth check per pixel down to one per 8 pixels.
the down side, of course, is that there's a lot of different parts of the engine that write to the screen, and you have to find every single one of them for consistant fog.

[mankrip]

splitting the world up into depth-based 'slices' is likely going to result in terrible looking fog. I'm not sure you'd save much.

That would depend on the number of slices. 32 slices should provide about the same quality of the sharp undithered fog leileilol posted.

as spans are drawn in 8 or 16 pixel chunks, you can just use a single fog factor for each chunk, so you go from one depth check per pixel down to one per 8 pixels.

That seems to be what leileilol did for the blocky dithered fog.