surf8.s asm - taking out the lightmap smoothing

[leileilol]

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.

[andrewj]

Very quick and dirty way:

In each function (R_DrawSurfaceBlock_mip0..3) there are two 'and' instructions:

Code: Select all

andl    $0xFFFFF,%ebp
....
andl    $0xFFFFF,%ebx


Change $0xFFFFF to $0x0

[leileilol]

Cool! But it seemed to only turn off the left-to-right lightstepping. Did give me a clue, though...

Code: Select all

movl   %edx,C(lightright)

to........

Code: Select all

movl   %edx,C(lightleft)

We have blocks!

The math is still done regardless though, that's next.

[ceriux]

leilei i love how the stuff you work on always looks so retro. my opinon... games should have stayed this way.

[mankrip]

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.

[leileilol]

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))

[leileilol]

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.

[ceriux]

i think it would be cool to have a engine that had both extremely high visual options and extreamely low ones.

[qbism]

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.

Code: Select all

prowdest[b] = ((unsigned char *)vid.colormap)[(light & 0xFF00) + lightcolormap[pix*256 + color]];

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

[leileilol]

q1source + djgpp makefile + timedemo demo1 results

13.6fps = lightmap smoothing
14.0fps = no lightmap smoothing


ALRIGHT!!! 0.4FPS INCREASE

[taniwha]

2.9%. Not bad, actually.

[Spirit]

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++

[mh]

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.

[qbism]

ALRIGHT!!! 0.4FPS INCREASE

That may be the maximum potential. What is FPS without lightmap? (r_fullbright)

[leileilol]

ALRIGHT!!! 0.4FPS INCREASE

That may be the maximum potential. What is FPS without lightmap? (r_fullbright)

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.

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.