qbismSuper8 builds

[dreadlorde]

Any new updates qbism?

[qbism]

I'm working on improving colored light. More balanced and more intense. I don't want a QSG-style super-saturated blow-out, but color is very subtle and "blech" in the current release. Red and green ranges in the standard palette are weak (from a colored lighting standpoint) so I'm tweaking that as well.


Below is a bug in the current unreleased dev build, a little dithered patch of colored lights on each health and ammo box. I think it's related to the brightness of the color patch being brighter than the actual light level. Possibly solved with an adjustment to the mixing formula where the lookup table is generated. But when I make the boxes look good, everything else looks bad.


I may release a new build shortly after this bug is squished.

[qbism]

Fixed the bug. But why bother? Something primitive in the back of the mind enjoys the crudeness of 8-bit color trying to do what it doesn't know it shouldn't try to do.

[qbism]

Download super8 build 61: http://super8.qbism.com/wp-content/uplo ... 8_0061.zip

Many screenshots: http://super8.qbism.com/2012/04/super8-build-61/

Default custom palette setting, better colored light control, and fog are the main new features of this build.

Select a default palette with r_palette. The default is “s8pal”. Set it to “palette” for the standard palette, or make your own.
Set colored lighting intensity with r_clintensity. 1.0 is the default. Normal range is from 0 to about 2.
Fog color and density will be loaded from maps that use fog. Toggle it with r_fog. Maps with fog color that is similar to overall map brightness look best.

[leileilol]

FOG


FOG YES

FOGGIN DOWNLOADING THIS MOTHERFOGGING BUILD FOR FOG'S SAKE

NOT ONLY THAT BUT I'M FOGGING CHECKING OUT YOUR FOGGING SVN

I'M GONNA FOGGIN STEAL YOUR FOG!!!!!!!!!!!!!!!!!!!!!!!!!!

[leileilol]

your fog is slow in hi-res

how is it without dither?

BTW Laser Arena supported fog in software and it had dither. If you go some steps further you could make super8 run LA

[mankrip]

If it works like in Makaqu, it should be awfully slow, which is the reason why I gave up on implementing it properly.

Mipmap-based "fog" could be faster, but would certainly look worse.

[qbism]

SVN FOG-RUSTLIN'? SLOW? FOGWASH! Crank that res back down to 320x200. Don't notice much speed difference on an i3 laptop, PIII might be different.

The code is indeed Makaqu with two minor changes- increasing the layer distance and a dither function. The dither would be faster with a look-up table. It should look sort-of random and uniform, but determinate to avoid flickering white-noise.

OPTIMIZE ME:

Code: Select all

long xorShift64(long a) {
    a ^= (a << 21);
    a ^= (a >> 35);
    a ^= (a << 4);
    return a;
}

    // Manoel Kasimier - fog - begin
    if (fog_density && r_fog.value)  //qbism - adapt for global fog
    {
        int			x, y, level, fogindex;
        byte		*pbuf;
        short		*pz;
        extern short		*d_pzbuffer;
        extern unsigned int	d_zwidth;
        extern int			d_scantable[1024];
        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 = 30 - (int)(*pz * ((256.0 - fog_density*256.0)/256.0) + (int)xorShift64((long)(y*14121.753245+x*y*13.753245077))%2); //qbism - ditherish
                level= min(30, level);
                if (level > 0)
                {
#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 + ((64-level) * 256)]*256];
                }
            }
        }
    }
    // Manoel Kasimier - fog - end

[mh]

When it gets to this stage porting the software renderer to 32-bit might work out faster than keeping it 8-bit.

[leileilol]

Don't use the bestcolor function, that's slow.

Make a 15to8 lookup table and use that.

[qbism]

Don't use the bestcolor function, that's slow.

Make a 15to8 lookup table and use that.

In this case it's only hitting bestcolor once per r_renderview call. But bestcolor is getting abused elsewhere in code many times per frame, maybe a lookup could replace it everywhere.

When it gets to this stage porting the software renderer to 32-bit might work out faster than keeping it 8-bit.

It would look smoother, too, if I understand this to mean popping up into RGBA. That would look good in a certain style although it deviates from a hard-core 8-bit aesthetic aspect : intentional limited color use, jagged edges, dither, and low-res. 8-bit rendition can increase the sensation of actually being inside the grainy universe where palettized 64x64 surfaces live.

I haven't tried lately to simulate paletted color with a hardware engine. Start with GL_NEAREST then crank up the contrast. Or something like that.

This seems to run a bit quicker

Code: Select all

byte ditherfog[] =  
{ 2, 1, 1, 0, 1, 0, 2, 0, 1, 0, 1, 2, 0, 1, 0, 2, 0, 0, 1, 0, 2, 1, 0, 1,2, 0, 0, 2, 0, 2, 1, 0, 2, 0, 0, 1, 2, 0, 1, 0, 1};
.
.
.
               level = 32 - (int)(*pz * (256.0 - fog_density*256.0))/256 + ditherfog[(x*y+x)%41]; //qbism - ditherish
                if (level > 0)
                {
.
.
.

[mh]

The way I'd do it is still use the colormap but expand to 32-bit at the last minute. That would give you the full 8-bit crunchiness but would also enable effects like fog and coloured light to be handled better. I have a version of software Quake that more or less does this, but using C code, no asm, so it's not really the best performer.

Other ideas are to draw to 3 different screen buffers - one for each colour channel, then recomposit them to the final 32-bit image for display. Also occurs to me that using the z-buffer data for fog depth info as a post-processing pass might be good too (I've tried this with hardware and it's much slower than regular fog, but it might work well with software).

[qbism]

Other ideas are to draw to 3 different screen buffers - one for each colour channel, then recomposit them to the final 32-bit image for display. Also occurs to me that using the z-buffer data for fog depth info as a post-processing pass might be good too (I've tried this with hardware and it's much slower than regular fog, but it might work well with software).

Color has to be handled prior to going to d_drawspans, the main bottleneck. The 3 buffer idea is interesting because the asm drawspan functions could possibly still be used. Run for each channel. 3x slower than non-colored light, but results in nicely dithered colors.

The Makaqu fog implementation runs as post process using z-buffer, after everything is drawn but the HUD.

[qbism]

Mipmap-based "fog" could be faster, but would certainly look worse.

I just tried this with a quick hack, adding a fixed value to light at each mip function. It is a compelling idea because there is almost zero impact to FPS. It worked, but the standard four mip levels are not nearly enough for smooth transitions.

[mankrip]

Mipmaps also doesn't work the same way across very different resolutions, so the results would be inconsistent.