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.

[Baker]

[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]

[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 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]

[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]