Tutorial 7 online

[Digby]

Mirek,<br><br>Relax, I think YOU missed my point.  I fully understand the c-buffer approach.  My question was that I would like to know the performance difference between it and using a stencil buffer.  Your answer of "much slower" isn't meaningful to me.  I would prefer to see data to back that up.  Is it 25% slower?  is it 50% slower?  is it 200% slower?  That's the sort of  information someone would need to choose one algorithm over another.<br><br>The c-buffer's performance is highly data dependent.  It works nice for large opaque objects that don't contain a lot of transparency changes across a horizontal span.  It doesn't work for alpha-blending and the application must submit its drawing in explicit front-to-back order (or at least be aware that it will be drawn as such).  If you get a sprite that has a number of transparent sections across a horizontal span, then span management for these sprites can turn into a nightmare.  Jacco chose to use an opaque ball shape for a reason.  Using a c-buffer approach for rendering a sprite of any aribrary shape is more difficult and can end up being slower than alternate methods.<br><br>I think the c-buffer approach is great for large opaque compositing.  Things like parallax images for side-scrollers could benefit from reduced overdraw (Jacco hinted at this in his tutorial).  I'm not so sure about its worth as a general sprite solution though.<br><br>

[Captain_Chickenpants]

Okey dokey, what I need is a modification to the C-Buffer approach that will alpha blend between sprites. <br>I think the way I will have to do it is to allocate an area of memory for where the sprites overlap, and blend into this then passing this as the address for that span, unless anyone else has a better idea?<br><br>Paul.

[MirekCz]

digby those resoluts you're asking are highly dependend on entry data. On phantom's ball example the difference would be huge, up to 100% slower I would say... and with a bitmap created of pixels transparent/non-transparent/transparent/.... c-buffer would be slower then stencil buffer. But in usual games, most/all sprites have got few spans per horizontal line... It all depends where and how you will use it.<br>On the other hand.. the best way to find out is to make a little test...*hint* *hint*

[Digby]

Mirek,<br><br>Yes, I wholeheartedly agree that to answer my question I should probably write some code and measure the results.<br><br>We should be able to come up with an idea of the overhead of managing multiple spans vs. testing a stencil buffer though.  One thing about the stencil buffer that I didn't mention before was that all you need is 1 bpp to perform the stencil test.  Therefore you can read 32 pixels worth of stencil data in one DWORD read.<br><br>

[MirekCz]

digby:yeah, you can, but...<br>1.without using asm, checking for single bit might be not that fast afterall (still much faster then reading mem)<br>2.often you would have to read much more then one pack of 32bits<br>3.So It all comes to the question where you want to use it... if you have got bitmaps with average width of 50 and one-few spans, you would be probably better handled with a c-buffer, else a stencil buffer might be the way to go... (this is an "example" and I can't give you exact numbers when it's better to use c-buffer and when stencil buffer.. You would need to test that...<br>PS. With a small overdraw (<2.0) I guess you could be better served without any additional buffor at all - cause you're doing just a simple blit which is quite fast... things would look much different if you were doing additional calculations perpixel (like bumpmapping mentioned earlier by phantom) <br>(putting 20k more pixels on screen might be less expensive then handling the c-buffer and hungryds if not thousands of spans...)<br>Therefore for small overdraw (especially when you're using a lot of transparent images) compressed sprites (rle encoded/whatever the name is) might be the best solution (and you can use alpha-blending easily then...)

[Phantom]

Ehm,<br><br>Some thoughts:<br>- A stencil buffer implemented in software could be faster than just blitting. I've never thought of that, but instead of writing 32 pixels, you test 32bits in a mask, wich does not require any memory access at all (theoretically; if the mask is in a register).<br>- Of course this testing takes time, so at zero overdraw, this algorithm is obviously slower than a simple blit.<br>- Each implementation of the stencil buffer algorithm has it's own more or less exact percentage of overdraw at wich it is faster to use than plain blitting. Authors should calculate this figure and publish it with the source code. <br>- The c-buffer can't handle alpha blending. Alpha stuff is fundamentally bad for c-buffers, since it REQUIRES overdraw. You could theoretically draw alpha spans without filling the c-buffer, though. That means however that subsequent spans that get behind the alpha spans should be mixed AT THAT STAGE. So while you don't fill the c-buffer, you still have to keep track of the fact that there is an alpha-span there. That's not funny anymore. <br>- The performance of a c-buffer algorithm could be expressed in 'minimal efficient spanlength'. When you insert two 240 pixel span per scanline, ANY implementation of the c-buffer algo is faster than plain blitting. However, imagine an asm implementation of a c-buffer algo using trees instead of linked lists and a non-recursive insertion function (mine is still recursive). Given the simplicity of the actually executed code (the insertion function is huge, but the path is quickly narrowed down), a very good implementation could already be efficient at an average span length of 4 or 5 pixels. This would mean that almsot ANY situation would benefit from using it.<br>- Final thought: In the above optimal algo there would be a huge performance difference between an optimzied 'scene' and a scene that peforms OK just because the c-buffer code is so mighty efficient. While high-speed is good, huge fluctuations in speed are NOT good.<br><br>- Jacco.

[Phantom]

O yeah, I haven't tried this yet, but I bet the balls demo would be a lot faster if I would sort the balls using their x-coordinate. Far less clipping of spans in that case, all spans would simply grow from left to right. <br><br>Ehm... That wouldn't work. The drawing order of the balls would change per frame, causing bad popping. Never mind.

[MirekCz]

Phantom:*ROTFL*, your last post is great:)))<br>and about the stencil.. with complicated sprites such situation might be "rare" and you also didn't take one fact into account... you have to fill the stencil buffer first anyway...<br>And another reason why c/stencil isn't the greatest - no alpha-blending for both...<br>I still believe a good usual drawing can be often faster or as fast as c-buffer/stencil buffer... and a lot less trouble:)

[Phantom]

Of course. But sticking to the most ancient solution is not satisfying, is it? But I think you're right.

[MirekCz]

Phantom:sure it's not... the use of c-buffer or stencil buffer can bring a lot in some cases... It all depends pretty much on the situation. (I guess most engines that don't use alpha-blending would profit heavily from them..., but a lot of ppl is using alpha-blending...)<br>So to sum it all up, it's a good idea and might appear here or there to create effects "never seen before":) (for ex. it's perfect for a Mortal Kombat like background with 7 layers or so... a lot of side-scrollers could profit from it:)