I was in your exact same situation for what seemed like years, there's just no 'really good fast way' to draw a 2D background like we used to in DirectDraw. It seems ridiculous but its true. You will have to render a large texture of some sort as your background and there's not much you can do about it.

One thing is for sure, you definitely want to do it with one DrawPrimitive call. If you have a tiling texture, look into using the WRAP texture addressing mode so that you can use texture coordinates beyond (1,1) to tile the plane. For instance your upper left might be (0,0) and bottom right (4,4) to repeat your image four times. The (more general) alternative would be to have a vertex buffer with 16 quads (4x4) which you would render with one DrawPrimitive.

Quote:Original post by EasilyConfused
So you reckon if I create say a 256x256 texture and look into wrapping it, it would be reasonably fast? At least then I suppose I could use the same texture for different resolutions.

If that's what you need... but today's cards are definitely fast enough to use a 1024x1024 or even larger texture if need be, and you can still easily get 'hundreds of fps' (inaccurate measurement but you get the idea.)

People around here often ask how to do various full-screen effects (flashes, backgrounds, etc) and the most common response is 'use a full screen quad' (6 vertices, 2 triangles). Today's cards are so fast (even, say, GeForce2 caliber hardware) that your background should not be a significant problem unless it has many layers or something complicated.

Quote:How come Direct3D can't support straightforward 2D blitting as well as polygons? I mean, my card obviously can since it will run DirectDraw applications dead quick. Why can't Direct3D take advantage of this as well?

I'll let somebody else give you a more technical answer to this if I'm wrong but the way D3D is set up, you build up states and commands to send to the GPU so that it can run in parallel with your CPU. No longer are you concerned (at all) with pixels; the GPU is a black box and you don't know how it works, just that it can draw and blend triangles very quickly as you specify via renderstates and vertices. Thus a well designed game (even a completely 2D one) is very easy to make resolution independent. The operations that DO access pixel data (locking surfaces, etc) are extremely slow because they cause a stall, where the graphics card has to stop what it's doing so you can play around with its guts. You have to learn to think differently about how your backbuffer is assembled throughout the frame.

The 'blitting' method is no longer the name of the game; drawing a whole bunch of triangles (in the largest batches possible) is. Even though this is annoying for certain basic tasks, the power you get in exchange ('free' scaling, rotation, alpha blending for starters) are very much worth it.

Note that pixel shaders blur some of these distinctions but I'm assuming you're using the basic fixed-function pipeline to make your 2D engine, and a pixel shader still isn't going to help you improve a basic 1-to-1 background 'blit' in terms of performance.

Quote:Original post by EasilyConfused
What about IDirect3DSurface8 and IDirect3DDevice::CopyRects? I notice it seems to be missing from Direct3D 9. Is this a plausible way to draw a backdrop then render textured quads over the top? I appreciate you can't alphablend and so on with CopyRects but is it comparable to a DirectDraw blit?

I think they are just too slow. I tried it once and was lucky to get something like 20fps. There's a ton of advantages to avoiding this kind of thing and just drawing the background the way you'd draw any other sprite, except larger.

Quote:Original post by EasilyConfused
What do people reckon?

I did the same thing, basically wrote my own sprite class and engine and avoided D3DXSprite (not that there's anything wrong with it but you can add your own features to a custom class). It's certainly easier than doing 3D stuff right away, but ONLY because you avoid the 3D math that can be tricky. Remember to keep in mind that D3D doesn't care if what you're doing is '2D' or '3D': it just draws textured triangles for you, regardless of how or why you're telling it to do so. This will make the transition to 3D or mixed 2D/3D easier for you if you can begin thinking this way; it's the same API with the same functions no matter what your intentions. No need to worship 3D as something TOTALLY different. Once you learn vertex buffers and things like that, changing to 3D will be no big deal for you in terms of working with D3D; the biggest differences are probably light/shading setup and transformations that are applied to your vertices before rendering.

I have to add that you shouldn't feel any pressure to go 3D if you don't want to; I firmly believe there's tons of possibilities for outstanding games using just basic FFP 2D stuff. Such games (in a variety of genres) can easily look fantastic for many years to come.