surf8.s asm - taking out the lightmap smoothing
surf8.s asm - taking out the lightmap smoothing
I'd like to try this but i'm having trouble understanding this Abrashy stuff. How would I just apply an unblended single lightmap texel across a surfmipblock, making lighting rather blocky and reminiscent of CyClones, skipping all the delta blending math?
This would in theory, bring a huge benefit to low-end performance, followed by changing the fade calculation on the dynamic light painting.
This would in theory, bring a huge benefit to low-end performance, followed by changing the fade calculation on the dynamic light painting.
Last edited by leileilol on Tue Sep 18, 2012 9:46 pm, edited 1 time in total.
i should not be here
Re: d_surf asm - taking out the lightmap smoothing
Very quick and dirty way:
In each function (R_DrawSurfaceBlock_mip0..3) there are two 'and' instructions:
Change $0xFFFFF to $0x0
In each function (R_DrawSurfaceBlock_mip0..3) there are two 'and' instructions:
Code: Select all
andl $0xFFFFF,%ebp
....
andl $0xFFFFF,%ebx
Re: d_surf asm - taking out the lightmap smoothing
Cool! But it seemed to only turn off the left-to-right lightstepping. Did give me a clue, though...
to........
We have blocks!
The math is still done regardless though, that's next.
Code: Select all
movl %edx,C(lightright)
Code: Select all
movl %edx,C(lightleft)
We have blocks!
The math is still done regardless though, that's next.
i should not be here
Re: d_surf asm - taking out the lightmap smoothing
leilei i love how the stuff you work on always looks so retro. my opinon... games should have stayed this way.
Re: d_surf asm - taking out the lightmap smoothing
I don't think so. But it's nice to see the lighting become more similar to the Saturn version of Quake.
Being able to simulate to some degree the visuals and other features of GLQuake, Quake 64 and Saturn Quake was one of my goals with Makaqu. I even figured out how to load several of Saturn Quake's loading screens. Eventually I wanted to add an option to switch between those styles, WinQuake's style and Makaqu's default settings.
Being able to simulate to some degree the visuals and other features of GLQuake, Quake 64 and Saturn Quake was one of my goals with Makaqu. I even figured out how to load several of Saturn Quake's loading screens. Eventually I wanted to add an option to switch between those styles, WinQuake's style and Makaqu's default settings.
Re: surf8.s asm - taking out the lightmap smoothing
I don't know how well this kind of no-math hack would work in C for the Dreamcast.
A 486 to test a result is operational right now. I was able to put this alternate method into a cvar. Since I know jack squat of ASM (I barely pushed vga bios registers on my own to color the startup screen) i'm going to have to comment out one line at a time of the highest surfmipblock loop hoping nothing breaks in a test and repeat. Once I achieve this, I'll do a release build and get testing (no, not a release. The dynamic lights and low detail are still bugged (waterwarp is sometimes screwed, and low detail doesn't work in Mode13h))
A 486 to test a result is operational right now. I was able to put this alternate method into a cvar. Since I know jack squat of ASM (I barely pushed vga bios registers on my own to color the startup screen) i'm going to have to comment out one line at a time of the highest surfmipblock loop hoping nothing breaks in a test and repeat. Once I achieve this, I'll do a release build and get testing (no, not a release. The dynamic lights and low detail are still bugged (waterwarp is sometimes screwed, and low detail doesn't work in Mode13h))
i should not be here
Re: surf8.s asm - taking out the lightmap smoothing
Took more math out as much as I could without screwing it up and did a 486 timedemo demo1 benchmark.
Old: 10.2fps
New: 11.5fps
I should really test these in a vanilla quake engine rather than my bloated stuff.
There's also the idea of just using one pixel per 16 texel block for both drawspans and surfmipblock.
Old: 10.2fps
New: 11.5fps
I should really test these in a vanilla quake engine rather than my bloated stuff.
There's also the idea of just using one pixel per 16 texel block for both drawspans and surfmipblock.
i should not be here
Re: surf8.s asm - taking out the lightmap smoothing
i think it would be cool to have a engine that had both extremely high visual options and extreamely low ones.
Re: surf8.s asm - taking out the lightmap smoothing
Colored light can be added cheap this same way but maybe not enough for 486 target. Get the color just like getting the light, then an extra 256x256 lookup table.
Colors are reduced to 8-bit indexed on-the-fly from standard .lit file. Or a utility to precompute, and just to make up a name, a .lt8 file if to save memory. On second thought maybe lmp format.
Another option is dithering of light and/or color. Ordered or indexed pseudo-random dithering. I don't know that it really goes with the look.
I'm hoping the map textures won't be bigger than 32x32
Code: Select all
prowdest[b] = ((unsigned char *)vid.colormap)[(light & 0xFF00) + lightcolormap[pix*256 + color]];
Another option is dithering of light and/or color. Ordered or indexed pseudo-random dithering. I don't know that it really goes with the look.
I'm hoping the map textures won't be bigger than 32x32
Re: surf8.s asm - taking out the lightmap smoothing
q1source + djgpp makefile + timedemo demo1 results
13.6fps = lightmap smoothing
14.0fps = no lightmap smoothing
ALRIGHT!!! 0.4FPS INCREASE
13.6fps = lightmap smoothing
14.0fps = no lightmap smoothing
ALRIGHT!!! 0.4FPS INCREASE
i should not be here
Re: surf8.s asm - taking out the lightmap smoothing
2.9%. Not bad, actually.
Leave others their otherness.
http://quakeforge.net/
http://quakeforge.net/
Re: surf8.s asm - taking out the lightmap smoothing
Dammit leilei, you should totally write a detailed blog series "optimising Quake for a 486" or something. Would be super interesting and give you hacker_cred++
Improve Quaddicted, send me a pull request: https://github.com/SpiritQuaddicted/Quaddicted-reviews
Re: surf8.s asm - taking out the lightmap smoothing
2 milliseconds which is actually quite significant. OK, on this kind of scale 2 milliseconds is a fairly small proportion of total, but even being able to get that from software Quake on a 486 is semi-heroic.
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: surf8.s asm - taking out the lightmap smoothing
That may be the maximum potential. What is FPS without lightmap? (r_fullbright)leileilol wrote:ALRIGHT!!! 0.4FPS INCREASE
Re: surf8.s asm - taking out the lightmap smoothing
r_fullbright doesn't actually disable lightmap blend. Even r_fullbright could be faster by just taking out the light blend functions from the surf8 completely as yet another surfmipblock set, which would also lead to fullbright not going overbright since there would be no colormap used.qbism wrote:That may be the maximum potential. What is FPS without lightmap? (r_fullbright)leileilol wrote:ALRIGHT!!! 0.4FPS INCREASE
To go further would be to make a 16 span block a solid color from that block's first texel so we skip a lot of patches
There's also the potential increase from adding r_dynamic and/or crude dynamic lights (no fade, but a hard circular clip off). GLQuake w/ Voodoo2 on a 486 gets around 21-32fps, so there's plenty of sky to reach for.
I should port engoo's low detail crap back to Quake and check out the increase. I remember that helping a 486 a lot.
When I say 486, I mean a L2 cacheless AM5x86 clocked at 120MHz ( 40x3 ), which roughly meets Quake's original minimum requirements.
i should not be here