DDraw7 vs D3D8 CopyRects
Hi,
I am about to start making a retro 2D game using system memory surfaces which i blit to a system memory backbuffer.
But I was wondering if anyone know if it is faster to use DirectDraw7''s Blt/BltFast or Direct3D8''s CopyRect?
Probably the same, though Blt/BltFast might be faster.
But if you''re making a 2D game, just use DX7.
- Goblineye Entertainment
The road to success is always under construction
But if you''re making a 2D game, just use DX7.
- Goblineye Entertainment
The road to success is always under construction
No contest! DirectX 7 Blt wins. This is because CopyRects does not do color keying, or clipping, nor does it use any hardware. It is also slow. This is because it is not meant to be used as a blitting function. It is meant to be used to move texture data between textures.
I made some performance tests on the CopyRect & the D3DXLoadSurfaceFromSurface. My test platform was a Pentium II 450MHz with Matrox G400. The CopyRect & D3DXLoadSurfaceFromSurface were both 5 times slower than an implementation using the old DirectX 7 Blt.
So much for the talk about integrating DirectDraw and Direct3D in DirectX 8.0. They simply removed the 2D-support!
So much for the talk about integrating DirectDraw and Direct3D in DirectX 8.0. They simply removed the 2D-support!
No no no...
CopyRects was meant to provide a way to infrequently update textures. It was never meant as a blit replacement. You are comparing oranges to apples here. The fact that you''re trying to use an API incorrectly does not make the API bad.
Microsoft didn''t remove 2D support, the hardware vendors did. A while ago, card makers would tout how fast their blitting engine was. You never see that anymore because cards aren''t set up to blit anymore. DX8 acknowledges that. You can still do 2D, but you don''t use "blit" anymore.
Where was it written is stone that 2D = "block transfer"? It could just as well equal "2D textured rect".
CopyRects was meant to provide a way to infrequently update textures. It was never meant as a blit replacement. You are comparing oranges to apples here. The fact that you''re trying to use an API incorrectly does not make the API bad.
Microsoft didn''t remove 2D support, the hardware vendors did. A while ago, card makers would tout how fast their blitting engine was. You never see that anymore because cards aren''t set up to blit anymore. DX8 acknowledges that. You can still do 2D, but you don''t use "blit" anymore.
Where was it written is stone that 2D = "block transfer"? It could just as well equal "2D textured rect".
Heh, I thought that was obvious... haven''t you noticed all the people posting stuff like "directx 8 2D game, 100+ sprites slows down to crawl" I say, if your gonna do a 2D game with directx 8,
make it by using textured billboards instead. that way, the 3D hardware can help out with it, and then you can use the texture alpha channel for transparency. I.E. tiles on screen are the usual 2D tile bitmaps, textured on to square polygons laid out in a grid. sprites are 2D bitmaps on free moving square polygons with a minimally closer z-coordinate (or for that matter, if your gonna bother to make a 2D engine like this, might as well allow non-square elements...something that isn''t so simle with true 2D.) presto, DirectX hardware accelerated 2D engine.
You could even create a library that would hide the details to the point of the 3D aspect being completely hidden. your init would setup direct3D, loading a bitmap would load it to a texture, and blitting would be simply placing the appropriately textured polygon at the specified coordinates.
who says ya can''''t code drunk? 103 errors ain''''t that bad..........
make it by using textured billboards instead. that way, the 3D hardware can help out with it, and then you can use the texture alpha channel for transparency. I.E. tiles on screen are the usual 2D tile bitmaps, textured on to square polygons laid out in a grid. sprites are 2D bitmaps on free moving square polygons with a minimally closer z-coordinate (or for that matter, if your gonna bother to make a 2D engine like this, might as well allow non-square elements...something that isn''t so simle with true 2D.) presto, DirectX hardware accelerated 2D engine.
You could even create a library that would hide the details to the point of the 3D aspect being completely hidden. your init would setup direct3D, loading a bitmap would load it to a texture, and blitting would be simply placing the appropriately textured polygon at the specified coordinates.
who says ya can''''t code drunk? 103 errors ain''''t that bad..........
Billboards are a bit of a complication.
Use either transformed vertices (already in screen coordinates) or "normal" vertices and an ortho projection. The advantage of the latter is that you can use the transformation functionality to move the vertices without locking.
Use either transformed vertices (already in screen coordinates) or "normal" vertices and an ortho projection. The advantage of the latter is that you can use the transformation functionality to move the vertices without locking.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement