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:

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]

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

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

[qbism]

[mankrip]

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