qbismSuper8 builds

You could easily add more than 4 miplevels and use C functions for miplevels after the 4th (the textures would be so small that not using asm should have minimal perf impact). You would need some form of linear filtering between miplevels too, and wot mankrip said about resolutions kind of kills the idea. The depth buffer post-processing method seems best for software to me.

I'm still tempted enough by the 3 buffers idea to give it a try sometime. I suspect that it would run a good deal better than one-third too, as it's only surface cache building and the final write out to the dest buffer that would need to be done 3 times - everything else is common.

  Code:

//r_main.c
.
.
.
//added to r_init   
for (i=0; i<DITHER_NUMRANDS; i++)
        ditherfog[i] = (float)(rand()%20000)/100000.0;
.
.
.

     // Manoel Kasimier - fog - begin
    if (fog_density && r_fog.value)  //qbism - adapt for global fog
    {
        dither=0;
        fogindex = BestColor(fog_red*128, fog_green*128, fog_blue*128, 0, 232); //qbism - half value, bright fog is harsh
        for (y=0 ; y<r_refdef.vrect.height/*vid.height*/ ; y++)
        {
            for (x=0 ; x<r_refdef.vrect.width/*vid.width*/ ; x++)
            {
                pz = d_pzbuffer + (d_zwidth * (y+r_refdef.vrect.y)) + x+r_refdef.vrect.x;
                level = (int)(*pz * (0.9 - ditherfog[dither++ % DITHER_NUMRANDS])); //- ditherfog[(x*y+x+dither++)%41]; //qbism - ditherish
                if (level < 32)
                {
                    if (level < 1) level = 1;
#ifndef _WIN32 // Manoel Kasimier - buffered video (bloody hack)
                    if (!r_dowarp)
                        pbuf = vid.buffer + d_scantable[y+r_refdef.vrect.y] + x+r_refdef.vrect.x;
                    else
#endif // Manoel Kasimier - buffered video (bloody hack)
                        pbuf = r_warpbuffer + d_scantable[y+r_refdef.vrect.y] + x+r_refdef.vrect.x;

                    *pbuf = additivemap[*pbuf + (int)vid.colormap[fogindex + ((level+32) * 256)]*256];
                }
            }
        }
    }
    // Manoel Kasimier - fog - end

This is a bit faster, I'll do a new build soon. Dither is +/- 10%, which seems a good balance between speckling and color banding. Worst-case performance hit I'm getting is 33%. Beauty cannot exist without pain.

Below is a 512x384 screenshot scaled up to show the dither pattern. If you don't know the map (CZG honey map set), it's been too long since you've visited func_msg or quaddicted

I'm kind of interested in your fogging. But kinda of already know how fogging works (this kind of thing happens when you dissect FitzQuake and slice and dice it well beyond the levels of human tolerance).

Either way, hats off to the fact you implemented software fogging. May leileilol stealzor it.

If ever there were a reason open source thinking and sharing matters, this would be it.

As I understand it, you've got your depth buffer and your screen buffer. The screen buffer contains a set of palette indexes, and the depth buffer contans - well - depths. If you know the fog colours, you can then use them to build a lookup table - make it 256x256 or something - then cross-reference depth with palette index on it and get a new palette index for the fog colour.

That assumes an 8-bit screen buffer. If you've got a 32-bit screen buffer you can just plug in the standard blend equation ((colour * factor) + (fog * (1 - factor))) and out comes the end result.

You can also do the same with a hardware accelerated engine by copying your depth buffer to a texture then blending it over the scene as a full-screen quad, using a shader to get your blend factor from the depth. It's slower than just using standard fixed-pipeline fog, and also slower than putting a fog equation into a shader, but it works.

One thing I would lose with this kind of setup is the ability to have fullbrights shining through fog. You can do it with software, using the same colour for all 256 entries of the relevant columns of your table, but hardware doesn't give you that kind of fine-grained control, and I can't see a straightforward way of doing it via a shader.

If you know the fog colours, you can then use them to build a lookup table - make it 256x256 or something - then cross-reference depth with palette index on it and get a new palette index for the fog colour.

That table already exists; it's the color shading map table (aka the colormap). Makaqu uses depth values converted to a range of 64 indexes per color (or 32 in super8, as qbism seems to be doing it, to avoid overbrights), and blends the results additively over the screen image buffer.

You can also do the same with a hardware accelerated engine by copying your depth buffer to a texture then blending it over the scene as a full-screen quad, using a shader to get your blend factor from the depth. It's slower than just using standard fixed-pipeline fog, and also slower than putting a fog equation into a shader, but it works.

Copying the depth buffer to an alpha channel (or simply using the alpha channel as a depth buffer directly) could be ideal, but the software renderer uses (iirc) 16-bit values for the depth buffer, which means that all values in the buffer would have to be translated anyway.

One thing I would lose with this kind of setup is the ability to have fullbrights shining through fog.

Most of the time fullbrights will already be brighter than the rest anyway, so there isn't much need to protect them from fog.

Also, fog isn't lack of light, it's an obstacle to light, and as such it should be able to occlude fullbrights. In some cases it may seem as though the light is traveling directly through the fog, but as I understand what happens is that what we see are actually reflections of the source light on the fog, and because of this that light is usually blurry. Some kind of bloom effect could be better for simulating that.

That table already exists; it's the color shading map table (aka the colormap). Makaqu uses depth values converted to a range of 64 indexes per color (or 32 in super8, as qbism seems to be doing it, to avoid overbrights), and blends the results additively over the screen image buffer.

Of course! I missed that one completely.

Improved dither, build 63: http://super8.qbism.com/wp-content/uploads/2012/04/qbismS8_0063.zip
Regarding overbrights- additivemap is used. May seem strange that it's not alphamap but that makes the fog look too dense. Another way to look at it with additivemap- maximum fog is solid white, not the fog color; the fog color is providing the alpha of each RGB channel. To compensate for only brightening the scene, fog color is reduced 1/2 and fullbright range is cut out. I guess "black" fog would be invisible. BTW, I haven't tried the Makaqu 1.4a method.

Trying with Wine it fails to create pcx screenshots. I have a clean Quake directory. Does it expect some screenshot directory to exist?

Also I get no 1024x768 windowed mode. Only 3 weird windowed resolutions.

That's the second engine you've tried where it can't write files. Are you sudo wine'ing?


Also I would do fog by generating a small 256x64 lookup table on the spot (when the fog command is called, perhaps maybe using a lookup table to generate it faster in rare 'animated fog' situations for lightning) like the colormap but fading to fog color and density instead then look that up from depth.

as leilei said you need to be superuser to write to non public folders on linux. easiest way is probably making a shortcut with sudo wine <name of your quake client here> -game etc.
making shortcuts differs a bit on linux builds so you might have to look up how.

Trying with Wine it fails to create pcx screenshots. I have a clean Quake directory. Does it expect some screenshot directory to exist?

Also I get no 1024x768 windowed mode. Only 3 weird windowed resolutions.

It puts screenshots in the game directory, like vanilla Quake.

Those weird resolutions are the new normal (widescreen). Set cvars vid_config_x and vid_config_y for any window size.

Improved dither, build 63: http://super8.qbism.com/wp-content/uploads/2012/04/qbismS8_0063.zip
BTW, I haven't tried the Makaqu 1.4a method.

I don't remember making any significative changes to it. Also, I was thinking of removing it altogether, along with the stereoscopic 3D mode and some other experimental features.

Your filenames needs some standardization. I just downloaded qbismS8_0063.zip, and the other two releases I've got here are named qbismSuper8_alpha_061410.zip and qbSuper8-03-13-11.zip.

I'm testing it here... Some impressions:
- There's an invisible item in the video options menu.
- The lighting looks kinda blocky, but is good.
- The lighting tends to green.
- Entering the menu didn't free the mouse cursor, so I had to alt-Tab to switch back here to write, and now the engine doesn't capture the mouse anymore, not even its buttons. The only way to fix this was by using a fullscreen mode.
- I couldn't find any cvar to get fog working in regular ID1 maps. r_fog is enabled, but I couldn't see any fog.
- The viewmodel adjustments for different fov sizes didn't work for my super shotgun model, but it's really nice anyway.

The lighting kinda reminded me of the Saturn version of Quake, which is nice as I'd like to get some of its features working in Makaqu. The stainmaps also looked really nice.

I will not run Wine as root, you crazy people. These two were the only ones that could not write screenshots, all others I tried were fine.
I guess I need to try strace later.

Sorry, my fault. I had some old screenshots left and qbism does not support labelling its screenshots with three or more digits (standard Quake bug if you want to call it that).

Your filenames needs some standardization. I just downloaded qbismS8_0063.zip, and the other two releases I've got here are named qbismSuper8_alpha_061410.zip and qbSuper8-03-13-11.zip.

I'm testing it here... Some impressions:
- There's an invisible item in the video options menu.
- The lighting looks kinda blocky, but is good.
- The lighting tends to green.
- Entering the menu didn't free the mouse cursor, so I had to alt-Tab to switch back here to write, and now the engine doesn't capture the mouse anymore, not even its buttons. The only way to fix this was by using a fullscreen mode.
- I couldn't find any cvar to get fog working in regular ID1 maps. r_fog is enabled, but I couldn't see any fog.
- The viewmodel adjustments for different fov sizes didn't work for my super shotgun model, but it's really nice anyway.

The lighting kinda reminded me of the Saturn version of Quake, which is nice as I'd like to get some of its features working in Makaqu. The stainmaps also looked really nice.

I'm very happy to get your feedback. Some responses-

- When I posted source to SVN a few months ago, I learned that a little batch file could automatically set version to SVN build number. That made more sense than date, and file names will probably be build # from here on out.
- Will check the menu, likely left over from a change.
- Colored lighting is added like blocklighting, but there's no quick means to dither between indexed values, so it uses basic dithering between adjacent values.
- For a while I was having trouble getting green at all, especially around slime which is usually lighted with green in .lit files. Now it's gone the other way. It is possibly something that can be adjusted in the custom palette. Results of change there are not directly linear and sometimes unexpected.
- On Windows 7, I couldn't duplicate the mouse capture problem. It released cursor at menu and recaptured upon exit menu and regain focus. I've got access to an XP machine. What Windows version are you using (or Linux/Wine)? Any others have this issue?
- Fog is set with worldspawn or SVC_FOG (with qc, using a trigger for example). It would be good to add a way to set it manually. I'm not sure if there's an automatic way to load it for ID maps, such as with an external .ent file. It could be something set brute-force in qc by checking file names.

I had some old screenshots left and qbism does not support labelling its screenshots with three or more digits (standard Quake bug if you want to call it that).

At least three digits is a good idea and should be easy to add. Something I never thought about.