Well, looks like speccy, Democoder and OpenGL guy have pretty much covered it all. Anything I add would just be repetitive.
As it stands, floating Z is useless to me. Now and in the foreseeable future.
While the game I'm working on is DX8 compliant, I don't have any plans to incorporate any DX9 specific features - because it doesn't contain anything useful to me at this time.
BUT, I'm not particularly concerned about the game (BCG) I'm working on. I'm concerned about the last game (BCM) and all future games which will be working on DX8 for sometime to come. But hey, the only consolation is that the 9700PRO is only one card. I'm not going to beat myself up about it. But my concern is that it starts with this card - and I'm sure future Radeon cards will still be missing a W buffer component.
The fact is, I no longer have the benefit of a W buffer. I tried the shader suggestion without much success and conveyed this to ATI. Around the end (9/23) of Sept. they promised to have one of the devs actually prove this theory with sample code (just like nVidia would) in case I was missing something. I'm still waiting for it. In the meantime, BC gamers have to put up with the artifacts.
Further, the problem with the terrain rendering was reviewed by the ATI devs, who on 09/16, came up with several suggestions - most of which (a) I was already doing (b) didn't work.
Here is a snippet from the conclusion rather lengthy email. Some pretty useful stuff were in that email actually (e.g. a suggestion about premodulating the water texturing for rendering).
The Z fighting is happening between steps 5 and 6. It's not a problem with multitexture at all. The trouble is that step 5 is drawn with triangle lists and step 6 (using the same vertices) is drawn with triangle strips.
While these will have the same rasterization when not clipped, things will go awry (as we are seeing) when clipping is involved. In order to characterize this, I disabled TcL and the rasterization guardband. This forces the SWTL path in D3D to clip everything and we then see the same sort of Z fighting. Z compare is set to less-equal but this doesn't prevent Z fighting on co-planar polygons.
Why don't we see this problem on nvidia? One thing I see is that nvidia reports a very large guardband. It's quite possible that they are not clipping in this case so they don't have any problems here.
Possible solutions:
- Render steps 5 and 6 with the same primitive types. This should guarantee invariance even with clipping.
- Render step 6 with a Z bias between 0 and 16 then render step 8 with a higher value. Thus, 8 could be used at step 6 and 16 at step 8
- Render the base texture with the detail maps at the same time. This will completely resolve Z fighting issues and alleviates the need for Z bias. I.e. multitexturing.
Note the highlighted parts. Ignore everything else because its all speculation and I already explained the process to them. Anyway, the bolded part is where I personally think the problem is and thats in the progress of being checked out - again - with code designed to alleviate this problem on these boards. Naturally, it works fine on every single graphics card to date - except the 9700 Pro. They suggest that it has something to do with the guardband. I have no idea, because I don't care about excuses. I want solutions and they seem to be trying to come up with one. Right now, they're just waiting for me to tell them if the suggesting (in bold) works or not.
Oh, did I mention that I put in shadows and it works fine on every card but is flat out busted on the 9700PRO? No? Go see Mafia for an idea. Naturally, I can't do anything about it until the previous problem is solved, because they might be related. At this point, I don't have a clue.
XBox here I come
