Aha... I rebooted and the black tris were still gone so I now realise why the black tris were there when using updatenormals!
The reason the black tris were there is because the corner vertcies of the quad were connected to both the front and the back faces. Because these face in exact opposite directions, it is impossible to calculate a normal for them which is halfway between the two. So all attempts to clauclate the normals ended up getting screwed up.
It should also be noted that even if the two sides had used individual vertcies, if you'd used Mark's updatenormals function you would have seen the same results, because MArks' updatenormals function looks for vertcies which occupy the same space and smooths across them. This sometimes leads to graphical glitches when you have geometry arranged in weird ways.
So that's what was going on. No zbuffer problem or bug in Blitz' rendering. Just normals that were impossible to calculate because of one tiny bit of debugging code I'd mistakenly left in the quad function. :-)
The reason the black tris were there is because the corner vertcies of the quad were connected to both the front and the back faces. Because these face in exact opposite directions, it is impossible to calculate a normal for them which is halfway between the two. So all attempts to clauclate the normals ended up getting screwed up.
It should also be noted that even if the two sides had used individual vertcies, if you'd used Mark's updatenormals function you would have seen the same results, because MArks' updatenormals function looks for vertcies which occupy the same space and smooths across them. This sometimes leads to graphical glitches when you have geometry arranged in weird ways.
So that's what was going on. No zbuffer problem or bug in Blitz' rendering. Just normals that were impossible to calculate because of one tiny bit of debugging code I'd mistakenly left in the quad function. :-)