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.
You should. For reasons I don't fully comprehend, you don't. I suspect (having written and optimized a polygon-based renderer) that they're cheating a little here, which is far from rare (or inherently bad). Let's say an edge falls through the middle of the pixel. On the right hand side of that edge (say), the textures are well defined. On the left hand side, they're not. Now, how to we pick points for antialiasing? In the naive 4x model, we treat each pixel as four pixels, and things work fine. For each of those four pixels, the line either passes to the left of the center, in which case we use the texture of this object, or the line passes to the right of the center, in which case we use the texture of the underlying object. For this to work, we need to replicate the z-buffer 4x also; that is, we're basically making an image 4x bigger (2x by 2x), and then scaling it down. More advanced FSAA algorithms (like the horridly-named Quincunx, or whatever) use strange numbers of points (5, here), and use different selection criteria. Also, they minimize scaling up of the z-buffer, since it's expensive and should make little difference. That means, though, that for a given point we may not be able to tell if the line is to its left or its right; we guess, and if we guess wrong, there's a chance we take from the undefined pixel. Again, I'm not claiming to know the exact algorithmic details, but I'm pretty sure this is the root problem.
I've had this sig for three days.
http://www.halflife2.net/forums/showthread.php?s=& threadid=3071
The gist: This isn't a big deal.
The game plays just fine on the hardware with the exception of a setting that very few even hardcore gamers use. This is important to a few enthusiasts, most others will never know the problem existed.
-- taking over the world, we are.