Ok, I've found a couple of problems going through the glut demos but I'm a bit stuck which direction to move to fix them and thought someone brighter might give me a pointer.
Both problems have similar symptoms. The example here is underwater.c. Scenario 1. vertices are rendered in 2 passes. Pass 1 has lighting and texturing enabled. _NeedEyeCoords is true and the vertices are transformed using separate Model / Projection matrices. Pass 2 has lighting disabled hence vertices are transformed using the combined Model/projection matrix. Problem : z values are slightly different (see attached file) and this causes artifacts on the rendered surface (proved by hacking both paths to use seperate model / project matrices) Scenario 2. vertices again rendered in 2 passes. Pass 1 has no texturing, hence _NeedProjectCoords is true (TINY_VERTEX_FORMAT) and the vertices are sent to the hardware (radeon) pre 1/w. Pass 2 enables texturing and the vertices are sent via emit_wgt0 for the hardware to do the divide. Same / similar symptoms which leads me to believe similar problems with z-values (again, forcing the same path "fixes" the problem) That said, a 16-bit Z buffer reduces the problem and I've seen other programs (RTCW) that exhibit problems with the z-buffer (when running with a driver that has problem 1 hacked around by using separate matrices for both paths and with things that are textured, so not problem 2 afaict - making me think it's either another different path issue or this is just an over sensitive z buffer?) So does the z-buffer zscale / zoffset need tweaking or does it always need to do hw divide? TIA -- Michael.
(gdb) x/32f VB->ClipPtr->data 0x81ad260: -33.8503151 -38.0965919 12.7596169 41.8397446 0x81ad270: 68.1937866 -16.570282 33.115387 55.4102554 0x81ad280: -47.5877037 -30.958437 25.509613 50.3397446 0x81ad290: 47.5877037 -10.6218176 53.740387 69.1602554 0x81ad2a0: -68.1937866 -5.97489166 40.134613 60.0897446 0x81ad2b0: 26.9816227 23.8792686 65.365387 76.9102554 0x81ad2c0: -88.7998657 19.0086555 54.759613 69.8397446 0x81ad2d0: 6.37554121 48.8628197 79.990387 86.6602554 (gdb) x/32f VB->ClipPtr->data 0x81ad260: -33.8503151 -38.0965958 12.7596197 41.8397446 0x81ad270: 68.1937866 -16.570282 33.1153793 55.4102554 0x81ad280: -47.5877037 -30.958437 25.5096207 50.3397446 0x81ad290: 47.5877037 -10.6218176 53.7403793 69.1602554 0x81ad2a0: -68.1937866 -5.97489357 40.1346207 60.0897446 0x81ad2b0: 26.9816227 23.8792667 65.3653793 76.9102554 0x81ad2c0: -88.7998657 19.0086517 54.7596207 69.8397446 0x81ad2d0: 6.37554169 48.862812 79.9903793 86.6602554
