Hello, i have a few questions regarding speed when it comes to handeling the backbuffer in D3d (not ddraw). I am implementing a software renderer and am currently working on doing alpha, which is very slow per default since it requires reading from the backbuffer which is in video memory(slow read, fast write). In ddraw it was possible to have the backbuffer in systemmemory, but it seems this is not possible in d3d. So i was wondering what would be faster, handeling a backbuffer myself or using a d3d surface created in sysmem? The advantages to using a d3d surface would be if you could blit it, since blit is fast and memset/memcpy is slower. But is UpdateSurface() the equalent of what blit was in ddraw? Doing it manualy would require: memset(bb, 0xFFFFFFFF, sizeof(int)*w*h); memcpy(locket_d3d_bb, bb, sizeof(int)*w*); every frame, which is sloooow! While blit could be used for both clearing and copying, but is it the same as blit was in ddraw or is it just a memcpy?

UpdateSurface() isn't quite the same. I believe both surfaces would need to be in system memory.

Consider dynamic textures. You create a dynamic texture, same size as your backbuffer, which you lock and fill using your software renderer, as per usual. When done, you unlock the texture, shove it into sampler 0, and render a textured quad into the backbuffer. Because it's a dynamic texture, the overhead of locking is minimal; the hard work is done on Unlock, when the data is sent across the bus to the graphics card, and while that's happening you can be getting on with something else (like AI or Physics).

To improve performance even further, you could triple-buffer your swap chain, and double-buffer your dynamic textures (i.e. have two of them and alternate which one you write/render each frame) - that would allow the system much more time to shlep resources across to the graphics card before you want to use them again.