I am writing this because I've noticed there is a lot of confusion out with with the so-called newbies and their understanding of how object occlusion works in hopes to clarify the situation.
Z-Sorting and Z-Buffering are NOT the same thing. Dark Basic Pro currently only supports Z-Buffering, which can cause a few problems. A patch is in the works to implement better occlusion techniques whether it be Z-Sort or something else, however for this explination I am going to be talking about Z-Sorting.
What is Z-Sorting? Z-Sorting (or Painter's Algorithm) is where objects are drawn based on the order of their distance to the camera. Basically, if an object is 5 yards away from the camera compared to an object 3 yards from the camera, then the 5 yard object will be drawn before the 3 yard object. That makes it to where closer objects will paint over the farther objects and give correct occlusion. There are limmitations to this, however. For the case of two objects intersecting each other there is no correct way to sort who gets drawn first. For instance, say you have two plains crossing each other in the shape of an X like in this picture:
http://www.geocities.com/djpeterson83/PainterGlitch.JPG
as you can see, there is just no correct way to draw it. If you draw the red one last, now, you would have the red one on top of the blue one.
What is Z-Buffering? Z-Buffering was the initial cure-all for the Z-Sort or Painter's Algorithm, but as will be shown later, it has its limmitations as well. How Z-Buffering works is by using a buffer the size and dimmension of the screen buffer (your monitor, basically). It then writes to the Z-Buffer all the polygon information just like it would to the screen with one exception: instead of writing the polygon's pixel color value at that location, it writes the polygon's pixel Z position, and only writes it if the new Z position of that pixel is closer to the camera. Otherwise it just ignores it because that pixel should be occluded. Because of the way that Z-Buffering works, it really doesn't care about the order of the objects it is drawing, only if the pixels of each object are closer than the last plotted pixel at that point. This gives pixel perfect occlusion, but has one major limmitation: if an object's pixels are translucent, then it will write the pixel to the Z-Buffer as if it were opaque! Thus objects which should show slightly through at that particular pixel, are completely obscured. Back in the beginning of 3D game programming, translucency was never an issue, so this wasn't a problem, but now a days this is not the case. Many of you may have noticed this phenominon already with blue-edged trees, or water that shows right through the terrain.
The Verdict: In today's graphics, Z-Buffering or Z-Sorting alone are not enough. Both methods must work together to give the best looking visuals with as few artifacts as possible. Thankfully, the DBP folks are adding in this capability (or a similar one).
The Solution: Currently, until the next patch comes out, THERE IS NO REAL SOLUTION. I stress this because there is a lot of missleading talk about how disabling the Z-WRITE of an object is some cure-all, but this is not the case! All this simply does is make it where the Z-Buffer ignores your objects pixels. This can actually cause more problems as now your object is ignored by the Z-Buffer, your object gets completely occluded by objects FARTHER away from it. A tree 50 yards away will now show over a bush 1 foot away, and as you may guess, this looks really wierd.
I hope this clears things up a bit, because the DBP folks have really been getting hit hard by similar bug-reports on the same issue. If there are any comments to this, please feel free to post.
Current Projects: Verious things right now. Lots of utils for game making. Hopefully something solid soon.
http://www.geocities.com/djpeterson83
