Alpha'd sprites & EntityOrder performance hit

So, I have 100 blitz sprites which are all positioned on the same vertical plane. Because they're alpha blended, I'm getting a horrible side effect: when sprite a and sprite b overlap, sometimes a is rendered on top of b, other times it's vice versa. Yuck!

I figured the best way around this problem was to assign each sprite it's own entity order, to guarantee each sprite will be drawn in a specific order. Indeed, this worked fine.

However, I'm noticing a performance hit using this method. Without setting the EntityOrder of the sprites, I get 1-2ms, with EntityOrder used, I get 5-6ms. This isn't actually too much of a problem with the thing I'm messing around with, but on a more intensive project, I image this could be a pain.

Anyone else notice this performance hit using EntityOrder and/or know why it's happening?

Also, re the overlapping sprites problem detailed above, what would be the best way around this if I were to use a single surface sprite system? In that case, using EntityOrder isn't an option, obviously.

Cheers.

Doesn't make sense no that 'helping it to sort' would cost you...

Might (MIGHT?) it help if you offset the sprites by just a fraction ie. 0.001 so the offset won't be 'visible' but prevents them sprites from sharing the same 'space' - thus help Blitz to the sorting??? I use this for drop shadows for example, that are stuck to the floor, and then offset by 0.001 to prevent the same effect as you describe..

But yes, as far as I understand your 100 sprites would mean a 100 surfaces - thus a 'single surface' particle/sprite system should score you a serious speed increase..

Danny.

The problem is not a BLitz3d problem but a Direct X prob lem IMHO.

Possibly a fill-rate thing.

Big10p - use a single surface system. From experience, the poly's on a surface are displayed in the order that they're created if on the same plane. Using alpha ( fx 2+32 ) may screw this up though - not sure. There is no harm ( unless you want pixel perfect ) in offsetting by a small margin as danny suggests.

That said, you may still get a bit of slowdown due to fillrate on your ageing rig ;)

Unfortunately, this doesn't work because z-buffering is disabled for all the sprites, as they're alpha blended.

Yeah, if I was working on a 'serious' project that required loads of sprites, I'd wan't to use a single surface system. As it is, I'm just messing around with something that doesn't need too many sprites, anyway. I was just curious about the cause of the EntityOrder speed hit. And, I'd still like to know how a single surface system would get around this problem.

I don't doubt that. :) [edit]Actually, bmax can use direct x and presumably doesn't have this problem, so I wonder how that get's around the issue?[/edit]

Hmm, how would fill-rate be affected by using EntityOrder? The sprites are tiny, too.

Ah, so that must be the way single surface systems get around the overlapping sprites problem, then?!

As I say, this doesn't appear to work. I'm assuming this is because the alpha'd sprites are rendered after everything else, but the order they're rendered in isn't consistent, for some reason. Hence, the order they overlap changes.

You'll get that speed situation in all cases of polygons which are stacked behind each other in the 100s where you put priorities, as the object's priority is possibly not in the same order as the objects themselves are in the Direct X Z buffer. So as long as we can't access the z buffer, we can't decide who get's added in first, or maybe we can figure that out from the code. But if you add the objects in random order and put random display priorities, that should yeld slower (if my logic holds). That is why in my terminal system I draw each layer at a time from furthest to nearest.

z-buffer is disabled when using alpha so render order is based on distance to camera.

But, the z-buffer has nothing to do with the order entities are sent to be rendered in. Especially my alpha blended sprites, which aren't z-buffered at all, since the pixels representing the transparent parts can't be calculated until everything else has been rendered.

Also, I'm not stacking loads of sprites on top of each other. The sprites are tiny and only ocassionally will 1 or 2 overlap each other, yet the speed hit is consistent.