Interesting R200 HyperZ notes

[Bambers]

I don't think its a z buffer error as its a tear. One side is a different frame to the other. When nothing is moving then no tears can be seen.

That photo is washed out so to give an idea of what was actually taken I took a screenshot (different angle but near enough)

again 1024x768 2xQuality AA

http://www.jamesbambury.pwp.blueyonder.co.uk/shot0001.jpg

The blue is actually the flare from the plasma gun firing

The jagged tear actually occurs on both sides of the fixed one but slopes the other way in the top left half of the screen.

As can be seen in the photo the height of each (erm) 'jag' gets smaller towards the left, this is reversed for the tears in the top left.

The position of the tears isn't affected by the geometry around, they are definitely tears between 2 different frames being rendered

I've not really studied in other games (I only have q3 on 98 atm) but I remeber the non jagged tear in CS, the jagged ones are harder to notice because they don't stay in the same place but they were probably in CS too. When I say they move about randomly it's just like with vsync off, the tears can be anywhere on the screen.

AS you can probably tell its quite hard to describe

Unfortunately I can't tell if hyper z is on or off. The drivers are old and the registry settings have changed since then so tweaking programs won't work (and I cant remember the old registry tweaks), the settings used would be the default for the drivers, most likely on. Stencil shadows are off.

The FSAA view program was written by Basic and some of its workings are explained in this article http://www.beyond3d.com/articles/wildcatiii/index.php?page=page4.inc
Theres also a link to the program at the end.

I tested the old 2xq with it and got the following:

texture mode:

geometry mode:

no idea what it means though

 

[darkblu]

As far as I know, z-buffer accuracy is solely dependent upon the transform matrix (given the same hardware settings...i.e. same z-buffer depth, method).

under conditions of inadequate zbuffer accuracy, practice is that the near clipping plane gets pushed as far ahead as possible, according to the layout of the given scene, i.e. the objects distribution within it. this is usually the case for open-space scenes, but for quake-like scenes you can set the near and far clipping planes to some good(tm) values satisfying your scene depth & objects-distribution case and live happily ever after with your 24bit (or even 16bit) zbuffer.

Specifically, the ratio of far to near determines the z-buffer accuracy. While it is certainly true that the layout of the scene will affect how much accuracy is needed for good rendering, I don't believe it has any effect on the actual accuracy.

yes, that determines the z-buffer accuracy. point is both the near and far clipping planes are a function of what you want to get captured of the scene at hand. so in the end it's the scene which determines the aforementioned ratio. see?

 

[Simon F]

With the exception of "scenes" that might be useful for CAD of an object (i.e. near and far are almost equal), the far clipping plane distance has negligible influence on the accuracy of the Z buffer. You're probably better off saving your time and assuming it's at infinity - the loss of accuracy is typically only 1/2 a bit.

 

[KimB]

yes, that determines the z-buffer accuracy. point is both the near and far clipping planes are a function of what you want to get captured of the scene at hand. so in the end it's the scene which determines the aforementioned ratio. see?

No, because it seems like you're implying that the transformation matrices are adjusted on a per-frame basis. I've never seen a game that does this.