qbismSuper8 builds
-
- Posts: 268
- Joined: Tue Nov 24, 2009 2:20 am
- Contact:
Re: qbismSuper8 builds
Any new updates qbism?
Get off my lawn!Ken Thompson wrote:One of my most productive days was throwing away 1000 lines of code.
Re: qbismSuper8 builds
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.
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.
Re: qbismSuper8 builds
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.
Re: qbismSuper8 builds
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.
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.
Re: qbismSuper8 builds
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!!!!!!!!!!!!!!!!!!!!!!!!!!
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!!!!!!!!!!!!!!!!!!!!!!!!!!
i should not be here
Re: qbismSuper8 builds
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
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
i should not be here
Re: qbismSuper8 builds
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.
Mipmap-based "fog" could be faster, but would certainly look worse.
Re: qbismSuper8 builds
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:
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
Re: qbismSuper8 builds
When it gets to this stage porting the software renderer to 32-bit might work out faster than keeping it 8-bit.
We had the power, we had the space, we had a sense of time and place
We knew the words, we knew the score, we knew what we were fighting for
We knew the words, we knew the score, we knew what we were fighting for
Re: qbismSuper8 builds
Don't use the bestcolor function, that's slow.
Make a 15to8 lookup table and use that.
Make a 15to8 lookup table and use that.
i should not be here
Re: qbismSuper8 builds
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.leileilol wrote:Don't use the bestcolor function, that's slow.
Make a 15to8 lookup table and use that.
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.mh wrote:When it gets to this stage porting the software renderer to 32-bit might work out faster than keeping it 8-bit.
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)
{
.
.
.
Re: qbismSuper8 builds
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).
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).
We had the power, we had the space, we had a sense of time and place
We knew the words, we knew the score, we knew what we were fighting for
We knew the words, we knew the score, we knew what we were fighting for
Re: qbismSuper8 builds
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.mh wrote: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).
The Makaqu fog implementation runs as post process using z-buffer, after everything is drawn but the HUD.
Re: qbismSuper8 builds
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 wrote:Mipmap-based "fog" could be faster, but would certainly look worse.