ID3DXSprite does batching automatically, HOWEVER, it require you to flush when you change textures etc.

The fastest way is as you said, batch as far as possible (by texture and states), and for all solid quads (sprites) you draw front-to-back, then you draw all transparent sprites back-to-front. (using your own or someone elses 2d engine using Direct3D)

I'm guessing that using a custom pixelshader and vertexshader you could crank it up even more as to only process minimal amount of instructions, but I would say, if you perform the previous step you should have plenty of power for any game that is built with any sense in mind on most of the graphics cards available today.

Using static buffers for static content (e.g., map tiles) could likely improve the speed by a small factor, however, can also decrease the performance due to excessive texture changing etc, trial and error.

EDIT: it's said that the ID3DXSprite for DX9 is much better than it was back in DX8.

Hi,

Well, I didn't ever tried the dx8 sprites, and I use an own sprite class for dx9 rendering instead of the D3DXSprite. maybe, batching could make your code faster, but I don't really think so, as you mentioned hundreds of sprites (which are, if you do them with two triangles) are not that much vertices, and not that much draw calls. I would suggest measuring with NVPerfHUD. Try the 2x2 texture option. If it speeds up, then consider making your textures smaller, and/or using DXTn compression for your textures. (This DNTn thing gave me almost 2x FPS increase in some cases on some hardware). So, before trying anything, use compressed DDS textures, then do some measuring. I think batching is not the way for you, but you can try of course (I did).

kp

From your description, you probably don't have a problem - ID3DXSpite will be optimized, so I wouldn't worry about it being slow unless you see particular evidence that it's a bottleneck in your software...



I use my own implementation of sprites, so I can't answer w.r.t. to the actual interfaces.

But I will say that you need to be quite sure that your new implementation is significantly different to the D3DX version if you expect a noticeable speed increase.

By this I mean that if you were to re-implement ID3DXSprite using pretty much the same methodology you're unlikely to beat the hand-tuned and tested Microsoft code [smile]

However, if you change one of the mechanics (such as storing all resources together to aid batching) then you might well get a speed-up for the simple reason that you're taking advantage of a "special case" in your system.

A similar example of this is that I wrote my own text rasterizer that took advantage of the fact the text was (mostly) static... it's an order of magnitude faster than using the D3DX text rendering, but I reckon that's only because I'm taking advantage of my knowledge of the way it's being used and chagned the mechanics accordingly...

hth
Jack

Quote:Original post by Rebooted
D3DX text is quite slow because it uses GDI functions, so you can beat it with your own code. ID3DXSprite however, is probably as fast as you can get.

No, since the june (i think) 2004 D3DX Text is based on textured quads (with the option to use D3DXSprites to improve performance) rather than GDI

Quote:Original post by 2dcoder
Would anyone like to code a simple sprite test challange? It would be cool if several coders coded a sprite test to see who's render loop is rendering the most sprites, at the highest fps. :)

800x600x32 screen, 2000 32x32 sprites, all moving in pong fashion around the screen, with rotation and scaling, etc. Any takers? Perhaps we could all use the same texture? I could code a DirectX8 version using VB6 and the D3DXSprite interface for comparison???

DirectX 8 or 9 only. We could all use Fraps.com utility for fps reporting so no cheating. :) LOL...

Actually, i've just implemented a simple sprite demo (no demo.. sorry) where i pushed around 250 888 sprites at 30fps in 1024 * 768 * D3DFMT_X8R8G8B8, and YES, those were textured sprites...

Quote:Original post by Metus
No, since the june (i think) 2004 D3DX Text is based on textured quads (with the option to use D3DXSprites to improve performance) rather than GDI

It has always been as far as I believe, HOWEVER, what he was referring to was the generation of the texture, which is done using GDI calls, and could be quite slow for generating the texture.