2d possibilites and performance
Author
Please go to www.geocities.com/popatr/gdpost.html and look at what I have there. There are three main ideas I have for implementing a 2D game engine, and I would like to know what you guys think is best. If all three ideas stink, go ahead and tell me so (and tell me why).
Also, if you know of a better way, would you please share it?
Edited by - popatr on January 9, 2002 12:45:18 AM
You should use a vertex based approach and not copyrects in most cases.
The 2D article on this site does break one of the rules of high performance rendering in that it sends 2 triangles per sprite/tile instead of many more. I have found that, at least on good cards (GF2 and up) the performance hit is negligible for a couple of reasons.
1. Sending larger buffers without matrix operations requires locking the vertex buffer and manipulating them on the CPU (which you also really shouldn't do). The two methods end up breaking even (+/- 1-2 fps).
2. You are much more fill constrained by 2D than you are geometry constrained. Doing something like leaving alpha blending on when you don't need it has a much higher impact on performance.
However, if you're tiling, you might be able to have a larger buffer for all the background tiles and then smaller buffers (or smaller chunks of the same buffer) for moving sprites. This could give you the best of both worlds.
On the method where you talk about the z buffer. These are called degenerate triangles and you don't have to move them off plane. Just colocate them with other vertices and use them as you describe.
The "visible from the front" thing isn't a problem. Just turn off culling. Not a great thing to do in 3D, but in a 2D world, you want every triangle drawn.
In short, here's my suggestion... (Assuming you have a tiled background and some moving sprites). Treat the background as one big grid of triangles or perhaps several rows of triangle strips. Move this large grid when you have to (scrolling) and use degenerate triangles if your texturing scheme requires it. Treat the moving sprites as you describe in your first point, but put the sprites in the same vertex buffer.
Some people are going to come back and tell you not to use matrices, instead use transformed vertices. From what I've seen, the difference is nonexistent and the matrix way just seems cleaner. However, my tests have not been on a wide range of hardware, so I'd be curious to see other comparisons.
Edited by - CrazedGenius on January 10, 2002 1:41:55 AM
The 2D article on this site does break one of the rules of high performance rendering in that it sends 2 triangles per sprite/tile instead of many more. I have found that, at least on good cards (GF2 and up) the performance hit is negligible for a couple of reasons.
1. Sending larger buffers without matrix operations requires locking the vertex buffer and manipulating them on the CPU (which you also really shouldn't do). The two methods end up breaking even (+/- 1-2 fps).
2. You are much more fill constrained by 2D than you are geometry constrained. Doing something like leaving alpha blending on when you don't need it has a much higher impact on performance.
However, if you're tiling, you might be able to have a larger buffer for all the background tiles and then smaller buffers (or smaller chunks of the same buffer) for moving sprites. This could give you the best of both worlds.
On the method where you talk about the z buffer. These are called degenerate triangles and you don't have to move them off plane. Just colocate them with other vertices and use them as you describe.
The "visible from the front" thing isn't a problem. Just turn off culling. Not a great thing to do in 3D, but in a 2D world, you want every triangle drawn.
In short, here's my suggestion... (Assuming you have a tiled background and some moving sprites). Treat the background as one big grid of triangles or perhaps several rows of triangle strips. Move this large grid when you have to (scrolling) and use degenerate triangles if your texturing scheme requires it. Treat the moving sprites as you describe in your first point, but put the sprites in the same vertex buffer.
Some people are going to come back and tell you not to use matrices, instead use transformed vertices. From what I've seen, the difference is nonexistent and the matrix way just seems cleaner. However, my tests have not been on a wide range of hardware, so I'd be curious to see other comparisons.
Edited by - CrazedGenius on January 10, 2002 1:41:55 AM
Author
Thanks for the quick reply-
So if fill rate seems to be the bigger concern, could anyone give tips on how to maximize performance this way? (Now that CrazedGenius mentions it, I will definitely make sure alpha blending is off when I don't need it) I guess lower res textures would always do the trick, and/or using mipmaps if I allow zoom-outs (loss of detail).
Could someone tell me whether its possible to reduce the colordepth to 8bpp. (which should increase fill rate) I don't really know how to do this in D3D, or if its even possible. All of my past projects/experiments initialize D3D with code straight from the SDK tutorials, and I was never sure where (if anywhere) color depth was specified. And so far I have always been using windowed modes, not fullscreen.
Well, I guess I'll study this a bit more on my own. I know that many of the examples will let you alt-enter into full screen mode, and I'll look at them. I bet that fooling around in this area will stumble me into how to change the colordepth. (if possible)
If 8bpp is possible, and I switch to it, does that completely rule out alpha blending? If alpha blending is still possible, how is it done? In 32bpp, the level of alpha goes straight into the first 8bits of a pixel, but in 8bpp how would such a thing be specified?
Edited by - popatr on January 10, 2002 12:21:10 PM
So if fill rate seems to be the bigger concern, could anyone give tips on how to maximize performance this way? (Now that CrazedGenius mentions it, I will definitely make sure alpha blending is off when I don't need it) I guess lower res textures would always do the trick, and/or using mipmaps if I allow zoom-outs (loss of detail).
Could someone tell me whether its possible to reduce the colordepth to 8bpp. (which should increase fill rate) I don't really know how to do this in D3D, or if its even possible. All of my past projects/experiments initialize D3D with code straight from the SDK tutorials, and I was never sure where (if anywhere) color depth was specified. And so far I have always been using windowed modes, not fullscreen.
Well, I guess I'll study this a bit more on my own. I know that many of the examples will let you alt-enter into full screen mode, and I'll look at them. I bet that fooling around in this area will stumble me into how to change the colordepth. (if possible)
If 8bpp is possible, and I switch to it, does that completely rule out alpha blending? If alpha blending is still possible, how is it done? In 32bpp, the level of alpha goes straight into the first 8bits of a pixel, but in 8bpp how would such a thing be specified?
Edited by - popatr on January 10, 2002 12:21:10 PM
don''t go down to 8 bit, stay at 32.
just make sure that the textures aren''t any larger than they need to be. also, in some cases, you may want to put several small textures in a larger texture to reduce switches.
just make sure that the textures aren''t any larger than they need to be. also, in some cases, you may want to put several small textures in a larger texture to reduce switches.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
