Author : Paul Nettle
Page : << Previous 5
if your average segment is 7 pixels or more (consider this in YOUR application), then you've saved memory over a 16-bit z-Buffer.
This does NOT include any inefficiencies in your segment manager or insertion routine (see the insertion routine questions for details).
You may not be doing simple grayscale gouraud shading. You might have colors, too. Add a byte (or whatever your app requires) for color.
Then there's the texture mapping information. This adds to the size, too -- possibly almost doubling the amount of memory required. But in some games (especially Wolfenstien-style games), you can still find a tremendous memory advantage over z-Buffers since the segments will most likely be so long.
These are things to consider when using s-Buffers. If you find that the s-Buffers will use more memory than z-Buffers, you've got a decision to make: Speed or Memory?
Q: "What are some more possible advantages of s-Buffers?"
As you render the s-Buffer, you'll be rendering the screen top-down, and each scanline from left to right. I can't think of any obvious advantages this offers other than the fact that it makes your low-level drawing routine a tightly optimized muscle machine.
If you have any cool ideas to make use of this unique feature, please lemme have 'em!
It would be an easy task to add information to your s-buffer lists that allows you to determine which scanlines have changed since the previous render so that your screen updates only contain updates to the scanlines that have changed. This will reduce the amount of time you spend updating the slow RAM on your video card (for PCs).
For more, see the next two sections on Masking and Transparencies.
Q: "What about masking?"
Many games have dash-board masks or the like. s-Buffers offer a clean way to handle this.
You can add a flag to your segment structures that can make it a masking segment.
This way, you can build a masking s-Buffer, use it as your starting point when you render, and insert segments into it, not letting them interfere with the masking segments. This will remove the need to perform pixel-by-pixel masking as the image is drawn to the screen.
This will also prevent your low-level drawing routines from having to render pixels behind the mask.
Q: "What about transparencies?"
By extending the masking idea a bit further, you can flag certain segments as transparent. As you insert segments, any non-transparent segments that fall behind the transparent ones won't remove the transparent segments. Any non-transparent segments that end up in-front of the transparent ones will clip the transparent segments.
This brings up the problem that some segments now overlap with transparent segments, making the Insertion routine that much more complex.
Note that transparencies modify the image behind them. If these transparent segments are kept in order of left-right (following their non-transparent neighbors in back-front order) within the linked-list for a scanline, as the low-level drawing routine draws the transparent segments, the non-transparent ones will already have been drawn, and the transparency modifications will fall into place nicely.
Q: "What are the disadvantages?"
If s-Buffers are used to store many small segments, of if you use an inefficient Insertion routine, you might find that the memory requirements will be quite high. I would expect that this would only be a concern in a small percentage of the applications out there.
There can be much difficulty in writing the insertion routine.
s-Buffers won't work with some implementations of curved surfaces as a z-Buffer will.
Page : << Previous 5