qbismSuper8 builds
Re: 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.
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.
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
Code: Select all
//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
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
Re: qbismSuper8 builds
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.
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.
The night is young. How else can I annoy the world before sunsrise? Inquisitive minds want to know ! And if they don't -- well like that ever has stopped me before ..
Re: qbismSuper8 builds
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.
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.
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
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.mh wrote: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.
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.mh wrote: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.
Most of the time fullbrights will already be brighter than the rest anyway, so there isn't much need to protect them from fog.mh wrote:One thing I would lose with this kind of setup is the ability to have fullbrights shining through 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.
Re: qbismSuper8 builds
Of course! I missed that one completely.mankrip wrote: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.
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
Improved dither, build 63: http://super8.qbism.com/wp-content/uplo ... 8_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.
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.
Re: qbismSuper8 builds
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.
Also I get no 1024x768 windowed mode. Only 3 weird windowed resolutions.
Improve Quaddicted, send me a pull request: https://github.com/SpiritQuaddicted/Quaddicted-reviews
Re: qbismSuper8 builds
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.
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.
i should not be here
Re: qbismSuper8 builds
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.
making shortcuts differs a bit on linux builds so you might have to look up how.
Productivity is a state of mind.
Re: qbismSuper8 builds
It puts screenshots in the game directory, like vanilla Quake.Spirit wrote: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.
Those weird resolutions are the new normal (widescreen). Set cvars vid_config_x and vid_config_y for any window size.
Re: qbismSuper8 builds
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.qbism wrote:Improved dither, build 63: http://super8.qbism.com/wp-content/uplo ... 8_0063.zip
BTW, I haven't tried the Makaqu 1.4a method.
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.
Re: qbismSuper8 builds
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.
I guess I need to try strace later.
Improve Quaddicted, send me a pull request: https://github.com/SpiritQuaddicted/Quaddicted-reviews
Re: qbismSuper8 builds
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).
Improve Quaddicted, send me a pull request: https://github.com/SpiritQuaddicted/Quaddicted-reviews
Re: qbismSuper8 builds
I'm very happy to get your feedback. Some responses-mankrip wrote: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.
- 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.
At least three digits is a good idea and should be easy to add. Something I never thought about.Spirit wrote: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).