3 ms·
From the article: >More performance >There are of course a lot of tricks to achieve higher performance. >Instead of drawing from back to the front we can dra
by cma 6y ago
From the article:
>More performance
>There are of course a lot of tricks to achieve higher performance.
>Instead of drawing from back to the front we can draw from front to back. The advantage is, the we don't have to draw lines to the bottom of the screen every time because of occlusion. However, to guarantee occlusion we need an additional y-buffer. For every column, the highest y position is stored. Because we are drawing from the front to back, the visible part of the next line can only be larger then the highest line previously drawn.
Level of Detail. Render more details in front but less details far away.
- kazinator 6y ago> However, to guarantee occlusion we need an additional y-buffer Not necessarily. If there is a uniformly colored background, and the pixels being drawn are of a different color, you can test the existing pixel value to determine whether it's a foreground object, or background. In the rare case that an object pixel value happens to be the same as the background, you can make an alteration in the least signficant bit of the least sensitive color to make it different. If there is a complex background, chances are you have a full copy of it, and can refer to it to see if any pixel in the image has changed. And in any case, a Y buffer is just the size of one scan line. E.g. using a 1024x768 screen as an example (3 byte RGB pairs), you need 1024x2 bytes for the Y buffer. That's .08% of the size of the frame buffer. You could use a scan line in the frame buffer for this storage. If you are not actually using the entire screen (because, say, the game shows the inside of a cockpit with instrumentation) there is no sacrifice at all; after being done using that temporary memory, you will draw over it anyway.