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???
Unfortunately, this doesn't work because z-buffering is disabled for all the sprites, as they're alpha blended. 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..
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. The problem is not a BLitz3d problem but a Direct X prob lem IMHO.
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] Possibly a fill-rate thing.
Hmm, how would fill-rate be affected by using EntityOrder? The sprites are tiny, too. From experience, the poly's on a surface are displayed in the order that they're created if on the same plane.
Ah, so that must be the way single surface systems get around the overlapping sprites problem, then?! There is no harm ( unless you want pixel perfect ) in offsetting by a small margin as danny suggests.
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.