Sign in to follow this  
speedie

help on design ideas for a 2D renderer

Recommended Posts

speedie    140
I started Direct X about a year ago and how come quite a ways, I haven't stepped into full fledged 3D yet, and not sure if I will anytime soon (I'm just to much a fan of 2D games, gameplay over effects). Along the way I've built up quite a framework, that has made, making demos for testing new ideas and techniques take only an hour instead of days, the input core I developed I'm most proud of, But enough of my bragging. I've been moving on to doing 2D in 3D, to make use of better effects. But with my hackish converting, I'm starting to notice some major frame rate hits. So I decided to start optimising and at the same time reorganize my renderer. So far my layout is something like. class CGraphics, this is the main core of my renderer, it'll handle initializing DirectX and manage all the other subclasses. class CTexture, this just manages all texture within the game, loading, removing and gabage collection. class CSprite, similar to CTexture, but a sprite will be a preloaded vertexbuffer, using any part of a texture. This should help by removing the need to lock and unlock vertex bufferers every loop. class CLight, handles lights in the same way CTexture handles textures. Those are my main classes, everything else will be based off of or use these classes. The only one left that I havn't quite figured out how to design yet is my class CScene, this class is what becomes active when I call the Display function of the graphicscore. I need it to store a series of draw commands, and be able to issue them all at once. So I'm asking, first off is this a good layout, and what Kind of things should I be looking out for with this design if I plan to incorporate vertex/pixel shaders, and different renderstates? also how taxing are calls to the renderstate? such as turnning off and on lighting?

Share this post


Link to post
Share on other sites
ET3D    810
Quote:
Original post by speedie
class CSprite, similar to CTexture, but a sprite will be a preloaded vertexbuffer, using any part of a texture. This should help by removing the need to lock and unlock vertex bufferers every loop.

Locking buffers could actually be faster. You'd want to render as many sprites with the same call as possible, because the render call has a high overhead (and associated settings, like setting the VB, are also costly). This can normally be achieved by creating a large vertex buffer and filling it with relevant sprites, then rendering it all at once. Though for the background, for example, you may be able to create such a buffer when the level loads, so you won't have to change it each frame.

Take a look at ID3DXSprite for an example of a class which allows rendering sprites. Though you could probably write a less general and more efficient class.

Share this post


Link to post
Share on other sites
speedie    140
OK, so I guess batching would be the best route, and not worry about tons o vertex buffers.

or would it still be good to keep the vertex buffer per sprite, so any sprite that doesn't get added to an index buffer, doesn't have to worry about creating a vertex buffer at runtime, just use scaling and tranformation matrices to put it were I want it?

Also should I have multiple index buffer, and what are the best ways of calculating what texture should be used for the buffer. I assume I'll have to run through everything that is to be drawn and calculate wich texture is used the most? But with a couple thousand things on the screen, I would think that could slow things down?

Also does DX do auto clipping based on z values or do I have to do this on my own? Such as if I draw something close to me, then some far away but at the same position, Will DX know on it's own not to draw the far away thing?

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this