Slashdot Mirror
NVidia Doesn't Play Nice With Half-Life 2
Sevn writes "Apparently, there's a hardware anti-aliasing bug in many new graphics cards that's surfaced in relation to Half-Life2. The details are on a forum post at HalfLife2.net. It seems that many ATI cards will be able to work around the problem, but nVidia users may not be able to. Here is a link to the original X-bit Labs story." The X-Bit Labs article explains further, citing issues with "...Full-Scene Anti-Aliasing, a popular feature that dramatically improves image quality in games... This is a problem for any application that packs small textures into larger textures. The small textures will bleed into each other if you have multi-sample FSAA enabled [in DirectX 9.0]."
It might be because my NES cartridges won't fit inside the PS2 slot tray. I'm not sure...
Yes, they do.
Right. Let's say you have four 256x256 textures... you can pack them into a single 512x512 texture, which is often convenient, especially when the textures tend to occur together. Now, when a graphics card does texture mapping, it sort of assumes that the portion of the texture it's painting on one triangle spills over onto the other faces of the polyhedron... that is, that it's wrapping the texture, in some way, around the polyhedron. One of the consequences of this assumption is what we're seeing here. In multisampling FSAA, you look at a set of points, not just the pixel center, to figure out what color to display in the pixel. In the center of a face, this works fine; the points are all in the desired pixel, all on the same face, and you get the correct effect. Towards the edge of a face, though, some of the points chosen may be past the edge of the texture boundry. If the texture wraps (that is, continues), it will be more or less the same color; we may see a tad of color from something that, strictly speaking, should be on the next face, but this is a non-issue. However, what if we're at the end of the texture? Normally this is detected and special-cased; either they wrap around to the far end of the texture or, more likely, they just throw out the given point. However, here, we're at the end of what the programmer thinks of as a texture, but not what the hardware thinks of as a texture... so it averages in a little bit of totally wrong coloring in the pixels at the edge of a polygon, under certain conditions. Solutions? Hardware side: Have the card only pick pixels within the polygon, which should therefore also be within the texture; the above describes only if you have some mismatch, like getting points from the far side of pixels that are part of the polygon on screen, but only partially inside the polygon in fact. Developer side: Don't pack textures.
I've had this sig for three days.
This isn't a new problem, this is a generally known limitation. If you place multiple textures onto one texture, you need to place a border area on them so that the mipmapping, interpolation, and anti-aliasing features work. This is because they use neighboring pixels for the smoothing. I bet it happens even with FSAA off, it just probably isn't as noticeable.