If you want to batch sprites that use different textures, you'll have to combine those textures into a single texture atlas and handle the adressing. Also if you want to render multiple quads with a single DrawPrimitive call but without using a dynamic vertex buffer, you should look into the various methods of instancing available in D3D9. There's a sample in the SDK, and also a good one on Humus's page.

However I really don't think you're going to need to worry about this too much...unless you're rendering 1000's of sprites a frame I doubt you're going to incur too much CPU overhead. In 99% of cases you should be fine with the batching ID3DXSprite offers, which batches together sprites of the same texture.

Use a custom vertex shader, and build a vertex buffer that has multiple rectangles in it. Each vertex of each rectangle would include an integer to tell you which "number" rectangle it was a part of, and then you could use that number to choose which set of transform params to use.

Quote:Original post by Sync Views
ok... I have 0 idea where to start and how what your saying works because I thaught vertex shaders were just the colours of something not where something is?

Pixel shaders can only affect the colour (and depth), but vertex shaders can mess with any aspect of the vertex. Everything that the fixed-function transform and lighting pipeline does - SetTransform/SetLight stuff - can be done in vertex shaders.

Quote:So you saying I can use a custom shader so I can send say 20 diffrent transform matrixes and have them transform diffrent quads rather than one matrix that effects all the quads in the buffer I'm drawing?

Yep, pretty much.

Quote:Original post by Sync Views
What I don't get is how I'm meant to add "custom" data to it as there are no "custom" entrys for the D3DDECLUSAGE_* types.

From the docs:

Quote:D3DDECLUSAGE_TEXCOORD can be used for user-defined fields (which don't have an existing usage defined).

-1..+1 ranges are only involved if the data type is one of the normalized formats (e.g. D3DDECLTYPE_UBYTE4N). None of the float formats are normalized.

Quote:It looks as if I can only draw as many vertices as are in the buffer (eg I can't draw a quad for every matrix using the same 4 input vertices). Should I just create like 100 quads in the buffer or something then so I'm pretty sure I'm unlikly to run out of quads and have to split drawing for that texture into 2 blocks?

Yes, that's the idea. If you happen to have > 100 quads, then you do it in two batches; but this won't happen often if you've got enough quads in the buffer.

Quote:Also how fast is sending matrixes and stuff for use in a vertex shader?

It's pretty fast. However, if the quads are always the same size and always have the same texture coordinates, then you don't need to send a full matrix; if you only need to send the position on screen, that's just an x/y pair - two float values. Packing in rotations is a little more involved, but still, if this is 2D then you should only need a 2x3 matrix, which you can pack into two registers. As a general rule, the smaller the size of the data you're sending to the vertex shader, the faster it will be to send.

You could also look into the possibility of preserving data from frame to frame - you don't necessarily have to reupload /all/ the params again every time, you might be able to get away with only reuploading those that have changed.

Quote:Original post by Sync Views
Does writing my own vertex shader by pass the world, projection and view transforms or is it just the first two?

It bypasses all three. It also bypasses the Direct3D lighting engine (D3DLIGHT9, SetLight/LightEnable).

Quote:(I'm not complelty sure what the diffrence between the last two is anyways...)

Take a look at the SDK docs - DirectX Graphics -> Programming Guide -> Getting Started -> Transforms.

Loosely speaking, the view transform is used to account for the camera's position and orientation in the world, while the projection transform is used to simulate the camera's "lens."