Archive for February, 2006

LOD bias’ raison d’etre

Thursday, February 16th, 2006

Mipmap LOD bias is usually used for two things: one, by smartass developers, to artificially boost apparent texture sharpness, simultaneously producing hideous aliasing and thrashing the texture caches. Two, by smartass driver writers who use it as a cheap way to improve performance. I’ve seen our games’ textures reduced to 16×16 smudges on a laptop’s 9600 switching to “performance mode” when running on batteries, presumably to conserve power - it was a disaster, and cost me a good chunk of debugging time until I figured it out.

Today I’ve found a legitimate use of the mipmap LOD bias. I’m implementing very-high-resolution screenshots (as in “print quality resolution”, or in “fscking too much for the GPU resolution”) using the method outlined by Steve Rabin in Game Programming Gems 4: I render and store NxN resolution screenshots, offset by M/N of the screen pixel resolution in each dimension by tweaking the matrices, then interleave them, taking one pixel of each input image in every NxN block of the output image. So if you have an object which is 5 pixels tall in the original resolution, you’ll have it 5xN pixels tall in the output image.

The problem is that the GPU has picked mipmaps for the object as if it was 5 pixels tall, which become too blurry when the object suddenly becomes 5xN pixels; hence, a -log2(N) bias is required to restore its normal look. Direct3D seems to allow negative bias up to -3.0, so you can effectively use this technique up to 8×8 the screen resolution; if you use a reasonable 1600×1200 as your screen resolution and assume a print quality of 300 dpi, this means you can get reasonable prints up to 40″x30″ (100 cm x 75 cm for metrophiles). Of course, even if you upsample 16×16, and give a negative LOD bias of “only” 3.0, I doubt anyone will be able to tell the “wrong” minimaps on a 300 dpi print :-)

At these resolutions, a 32-bit OS starts to show its limits: the 1600×1200 image, upsampled 8×8 is 350 MB; if you need 16×16, this becomes 1.4 GB, and might be somewhat problematic to fit in the 2 GB address space provided to a 32-bit application by Windows.

Buck a point

Friday, February 10th, 2006

I always wondered why on Earth games typically have “inflated” scoring systems: the tiniest thing you can do is awarded not with 1 point, but with, e.g. 100. Here’s a resonable theory by Kim Pallister:

Kim’s First Rule of Casual Game Design: Points awarded should correlate to real-world currency and the reward for an accomplishment should correlate to the value to the user.

OK, so what does this mean?
First off, when I say “first rule” I don’t mean most important. I just mean it’s the first I’ve come up with :-)
Secondly, when I say correlate to real-world currency, I mean the basic unit. E.g. 1 point = $1.
Finally, when I say value to user, I mean that you should think about things like “if these points were dollars, how would I feel about accomplishing that act and winning that amount?”

The Making of SOTC

Thursday, February 2nd, 2006

Finally, a some kind soul translated the lecture on The Making of “Shadow Of The Colossus” for us round-eyed barbarians.

Where is my NVPerfHUD64?

Wednesday, February 1st, 2006

For almost two months now developing exclusively on Windows XP 64-bit edition, the first major missing/incompatible piece of software: the NVIDIA instrumented drivers needed by NVPerfHUD. Please, NVIDIA!