Page 11 of 28
Re: qbismSuper8 builds
Posted: Sun Dec 16, 2012 12:49 pm
by leileilol
You know how sometimes a lightmap would appear jagged?
What if one of those popular scaler algorithms (i.e. HQ2X) worked in SurfMipBlock, creating straight lines of shadows and other curved smoothness? It would make updating dynamic lights very expensive though
btw qbism, any strange reason why you didn't use GrabColormap2 from qlumpy instead? Despite the "not used in quake" comment, that function actually is used to generate the colormap for Quake 1.0x.
Re: qbismSuper8 builds
Posted: Sun Dec 16, 2012 10:31 pm
by qbism
I never paid attention the difference between GrabColormap2 and GrabColormap before:
GrabColormap
frac = 1.0 - (float)l/(levels-1);
GrabColormap2
frac = range - range*(float)l/(levels-1);
Super8
frac = 1.05 - (frac * frac);
Squaring frac gives a gamma boost to brightness component, which improves blending with the hue component in some places. The "1.05" was eyeballed at some point. It would be a good place for a cvar. (Super8 converts .lit RGB to indexed hues. )
Scaling algorithm would either be a speed hit or memory hit. Devote 4x memory to lightmap and hqx2 entire thing at time of upload.
Re: qbismSuper8 builds
Posted: Mon Dec 17, 2012 10:36 pm
by mankrip
Lightmaps are actually smaller than the textures; the engine scales them up when caching surfaces, so leileilol's suggestion makes sense. This wouldn't require more memory, but would make the lightmaps much slower to cache.
Re: qbismSuper8 builds
Posted: Mon Dec 17, 2012 11:59 pm
by qbism
I'm talking about reducing the block size to 8x8.
Re: qbismSuper8 builds
Posted: Mon Dec 31, 2012 9:12 pm
by qbism
Massively annoying "windowed mode stuck off-screen" bug fixed.
http://sourceforge.net/projects/qbism/f ... p/download
Hope it works for everyone. Thanks to Mankrip and Baker discussion and improvement
http://forums.inside3d.com/viewtopic.php?f=3&t=5087
new vid, Tormentarium map with custom palette (torment.lmp included in distro .pak)
http://youtu.be/JC09stMpKSo
I don't know if it's a ddraw thing or just super8, but super8 requires entire draw window to be onscreen to avoid getting stuck, so it checks every frame.
One user reported a bug I can't duplicate... anyone had this problem: "It’s looking really good but for some strange reason I’m still getting that weird timing error when I mess with max framerate. I’ve cleared out all configs and settings between events but it seems once it’s stuck in ‘benny hill’ mode it just stays that way for a long time, then goes back to normal for a bit, then fast again. intel p6100 2.0ghz notebook processor, the computer is an Asus Notebook K52f running Windows 7 x64"
Re: qbismSuper8 builds
Posted: Mon Feb 04, 2013 6:02 am
by qbism
Build 123 released. Fixed pixel aspect, shading in dark areas, and view direction on spawn. Added r_nolerp_list (torch animation doesn't lerp). The pak features bent palettes created by Amon26. Do "r_palette amon26_pal01" and "restart" for example.
Current super8 build:
https://sourceforge.net/projects/qbism/ ... urce=files
ne_ruins with amon26_pal14
Re: qbismSuper8 builds
Posted: Mon Feb 11, 2013 6:41 am
by qbism
unrolling mips
Code: Select all
/*
================
R_DrawSurfaceBlock8_mip0
================
*/
void R_DrawSurfaceBlock8_mip0 (void)
{
int v, i, b, lightstep, lighttemp, light;
int colorleft, colorright; //qb: indexed lit
byte *psource, *prowdest;
psource = pbasesource;
prowdest = prowdestbase;
for (v=0 ; v<r_numvblocks ; v++)
{
// FIXME: use delta rather than both right and left, like ASM?
lightleft = r_lightptr[0];
lightright = r_lightptr[1];
r_lightptr += r_lightwidth;
lightleftstep = (r_lightptr[0] - lightleft) >> 4;
lightrightstep = (r_lightptr[1] - lightright) >> 4;
colorleft = r_colorptr[0];
colorright = r_colorptr[1];
for (i=0 ; i<16 ; i++)
{
lighttemp = lightleft - lightright;
lightstep = lighttemp >> 4;
light = lightright;
if (r_coloredlights.value)
{
prowdest[15] = vidcolmap[(light & 0xFF00) + lightcolormap[psource[15]*256 + colorright]];
light += lightstep;
prowdest[14] = vidcolmap[(light & 0xFF00) + lightcolormap[psource[14]*256 + colorright]];
light += lightstep;
prowdest[13] = vidcolmap[(light & 0xFF00) + lightcolormap[psource[13]*256 + colorright]];
light += lightstep;
prowdest[12] = vidcolmap[(light & 0xFF00) + lightcolormap[psource[12]*256 + colorright]];
light += lightstep;
prowdest[11] = vidcolmap[(light & 0xFF00) + lightcolormap[psource[12]*256 + colorright]];
light += lightstep;
prowdest[10] = vidcolmap[(light & 0xFF00)+ lightcolormap[psource[10]*256 + r_colorptr[dithercolor[light%41]]]];
light += lightstep;
prowdest[9] = vidcolmap[(light & 0xFF00)+ lightcolormap[psource[9]*256 + r_colorptr[dithercolor[light%41]]]];
light += lightstep;
prowdest[8] = vidcolmap[(light & 0xFF00)+ lightcolormap[psource[8]*256 + r_colorptr[dithercolor[light%41]]]];
light += lightstep;
prowdest[7] = vidcolmap[(light & 0xFF00)+ lightcolormap[psource[7]*256 + r_colorptr[dithercolor[light%41]]]];
light += lightstep;
prowdest[6] = vidcolmap[(light & 0xFF00)+ lightcolormap[psource[6]*256 + r_colorptr[dithercolor[light%41]]]];
light += lightstep;
prowdest[5] = vidcolmap[(light & 0xFF00)+ lightcolormap[psource[5]*256 + r_colorptr[dithercolor[light%41]]]];
light += lightstep;
prowdest[4] = vidcolmap[(light & 0xFF00) + lightcolormap[psource[4]*256 + colorleft]];
light += lightstep;
prowdest[3] = vidcolmap[(light & 0xFF00) + lightcolormap[psource[3]*256 + colorleft]];
light += lightstep;
prowdest[2] = vidcolmap[(light & 0xFF00) + lightcolormap[psource[2]*256 + colorleft]];
light += lightstep;
prowdest[1] = vidcolmap[(light & 0xFF00) + lightcolormap[psource[1]*256 + colorleft]];
light += lightstep;
prowdest[0] = vidcolmap[(light & 0xFF00) + lightcolormap[psource[0]*256 + colorleft]];
light += lightstep;
}
else
{
prowdest[15] = vidcolmap[(light & 0xFF00) + psource[15]];
light += lightstep;
prowdest[14] = vidcolmap[(light & 0xFF00) + psource[14]];
light += lightstep;
prowdest[13] = vidcolmap[(light & 0xFF00) + psource[13]];
light += lightstep;
prowdest[12] = vidcolmap[(light & 0xFF00) + psource[12]];
light += lightstep;
prowdest[11] = vidcolmap[(light & 0xFF00) + psource[11]];
light += lightstep;
prowdest[10] = vidcolmap[(light & 0xFF00) + psource[10]];
light += lightstep;
prowdest[9] = vidcolmap[(light & 0xFF00) + psource[9]];
light += lightstep;
prowdest[8] = vidcolmap[(light & 0xFF00) + psource[8]];
light += lightstep;
prowdest[7] = vidcolmap[(light & 0xFF00) + psource[7]];
light += lightstep;
prowdest[6] = vidcolmap[(light & 0xFF00) + psource[6]];
light += lightstep;
prowdest[5] = vidcolmap[(light & 0xFF00) + psource[5]];
light += lightstep;
prowdest[4] = vidcolmap[(light & 0xFF00) + psource[4]];
light += lightstep;
prowdest[3] = vidcolmap[(light & 0xFF00) + psource[3]];
light += lightstep;
prowdest[2] = vidcolmap[(light & 0xFF00) + psource[2]];
light += lightstep;
prowdest[1] = vidcolmap[(light & 0xFF00) + psource[1]];
light += lightstep;
prowdest[0] = vidcolmap[(light & 0xFF00) + psource[0]];
light += lightstep;
}
psource += sourcetstep;
lightright += lightrightstep;
lightleft += lightleftstep;
prowdest += surfrowbytes;
}
r_colorptr += r_lightwidth; //qb: indexed colored
if (psource >= r_sourcemax)
psource -= r_stepback;
}
}
Re: qbismSuper8 builds
Posted: Mon Feb 11, 2013 3:29 pm
by leileilol
Why are you getting a cvar value within a loop
I would put the cvar check in R_DrawSurface then check appropriately for the pblockdrawer that would house the colored lighting mips, it's faster that way.
I would also turn that into a global int and have that int changed on the model.c loading functions for sanity checking
Re: qbismSuper8 builds
Posted: Mon Feb 11, 2013 5:57 pm
by qbism
leileilol wrote:Why are you getting a cvar value within a loop
I would put the cvar check in R_DrawSurface then check appropriately for the pblockdrawer that would house the colored lighting mips, it's faster that way.
I would also turn that into a global int and have that int changed on the model.c loading functions for sanity checking
Thanks, I'll do both ideas. I used to have it even worse, the cvar was one loop deeper.
Re: qbismSuper8 builds
Posted: Tue Mar 19, 2013 8:36 pm
by dreadlorde
Any chance of support for resolutions such as 1920x1080?
Re: qbismSuper8 builds
Posted: Tue Mar 19, 2013 10:15 pm
by leileilol
type vid_describemodes. 1920x1080 should be like, vid_mode 21
Re: qbismSuper8 builds
Posted: Wed Mar 20, 2013 2:09 am
by taniwha
If a bit of code duplication doesn't bother you (and you have cvar callbacks), a global function pointer is better than a global int. Then the cvar can select the appropriate function. If you don't have callbacks, then checking the global (or cvar) before calling the function is almost as good. The less branches in your inner loop, the better (but certainly, don't go checking global vars, or worse, cvars!).
Also, if your compiler is good with inline functions, you can put most of the logic into a set of such and then the separate functions selected by the cvar are just a series of inlined calls to the functions, with the calls for the selectable functionality different.
eg: (functions selected by if for simplicity)
Code: Select all
static inline void func1() {...}
static inline void func2a() {...}
static inline void func2b() {...}
static inline void func3() {...}
void func_a ()
{
while (condition) {
func1();
func2a();
func3();
}
}
void func_b ()
{
while (condition) {
func1();
func2b();
func3();
}
}
void func()
{
if (cvar) func_a();
else func_b();
}
Re: qbismSuper8 builds
Posted: Wed Mar 20, 2013 5:05 pm
by qbism
Duplicating code indeed means faster execution here by pulling out the if-statement. In the case of colored lighting, a sanity check (locked cvar, global int, or boolean) is still required before selecting the function. Super8 doesn't have cvar callbacks but it would be handy in several areas.
Re: qbismSuper8 builds
Posted: Thu Mar 21, 2013 4:44 am
by qbism
Another incremental change to colored light dithering and rendering.
Build 134:
https://sourceforge.net/projects/qbism/ ... urce=files
map: tuhnu2 by zaka
Re: qbismSuper8 builds
Posted: Thu Mar 21, 2013 5:18 am
by r00k
looks NICE!