3D Engine Organisation?
Author
Hi,
To help me learn C++ and DirectX - or to motivate me, at least - I'm writing a simple 3D engine with DX9. It's just fixed function at the moment, although I'll probably go back and write a shader driven version at some point as I do have a little experience with HLSL.
I'm really just looking for some advice on organisation of a 3D engine, particularly in relation to the Direct3DDevice. If I want to, for example, load a texture with D3DXCreateTextureFromFile, I need to use the Direct3DDevice to do that. If I want to create a cube with D3DXCreateBox, again, I need to use the Direct3DDevice to do that.
I have an Engine class which does all the broad, general stuff, and currently, that's where I keep the Direct3DDevice pointer. But that would mean having the Mesh, Texture and all these other classes, going back to the Engine class every time they want to load or create something. Heck, even rendering a single mesh alone would have to go back to the engine class.
So I'm wondering if I should just add a static variable to each of the classes and set it when I create the device, or whether I should continue going through the engine class, but in a neater way. Or whether I should have a separate class for the device, or whatever. I'm just looking for some ideas in structuring a simple 3D engine. If there is a basic tutorial for this sort of thing somewhere, that would be great, as I'm sure there will be other issues arising of a similar nature.
I'm not looking to download Irrlicht and read through the whole thing or buy a huge book. That would be way overkill for a simple 3D engine as a learning project. I'm just looking to make my life a little easier and more enjoyable while I learn to write this little self-tutorial project.
Not to put you down or anything, but everyone's first engine is always a mess. The best is to have some kind of draft of what you want and jump right in and do it. Start off small!
Knowing exactly what you want, be it Tetris or a pacman clone... is extremely important.
There are a lot of discussions about how to structure your engine and the lot.
I tend to think of every main component of a game engine as a separate unit/engine.
InputEngine, GraphicsEngine, PhysicsEngine and NetworkEngine etc...
These engine can either talk to each other in the layer above it... being the implementation of the game or the world engine. This totally depends on you.
I suggest you mess around with it and find something that works for you.
Think about it logically too though.
Knowing exactly what you want, be it Tetris or a pacman clone... is extremely important.
There are a lot of discussions about how to structure your engine and the lot.
I tend to think of every main component of a game engine as a separate unit/engine.
InputEngine, GraphicsEngine, PhysicsEngine and NetworkEngine etc...
These engine can either talk to each other in the layer above it... being the implementation of the game or the world engine. This totally depends on you.
I suggest you mess around with it and find something that works for you.
Think about it logically too though.
I do agree with Armadon, a generic engine class isn't probably the best place to store a pointer to the D3D device. It would be better to split the engine into separate classes/units/engines.
I'd not go for a static variable. The problem is you have a device which is "unique" and you're copying it into several static variables. In OOP it is desirable to do the opposite, to provide an unique access point to multiple data. By copying your device around you're adding unnecessary complexity. If you write a new class, you'll also have to set the static variable, thus you'll have to modify the engine class. Unless you ask the engine for the device, but in that case nothing should prevent you to ask for the device only when you need it (when creating your objects).
As for rendering, if it's true you have to ask the engine to give a pointer to the device, it is also true you don't want to set textures/vertex buffers/index buffers which are already set. At a certain point, when the amount of data rendered increases, you'll have to check for redundant sets and there's no way a mesh or texture class should be responsible of doing it. Since you'll probably have to ask some cachers/managers to set a texture/vb/ib (if they're not already set), I think there's no problem to ask the engine to render a mesh.
I'd not go for a static variable. The problem is you have a device which is "unique" and you're copying it into several static variables. In OOP it is desirable to do the opposite, to provide an unique access point to multiple data. By copying your device around you're adding unnecessary complexity. If you write a new class, you'll also have to set the static variable, thus you'll have to modify the engine class. Unless you ask the engine for the device, but in that case nothing should prevent you to ask for the device only when you need it (when creating your objects).
As for rendering, if it's true you have to ask the engine to give a pointer to the device, it is also true you don't want to set textures/vertex buffers/index buffers which are already set. At a certain point, when the amount of data rendered increases, you'll have to check for redundant sets and there's no way a mesh or texture class should be responsible of doing it. Since you'll probably have to ask some cachers/managers to set a texture/vb/ib (if they're not already set), I think there's no problem to ask the engine to render a mesh.
Author
Thanks guys, some good points there. This is not going to touch on physics, networking or audio, and it might not deal with input either. I was planning on having a RenderWorld function in the engine class which did all the checking for redundant state changes. The render method in mesh, for example, was only for those instances where you just want to render one or two things alone. Like if you're rendering a couple of things to a texture or something.
I didn't like the idea of a bunch of static variables holding the Direct3D handle, which was what prompted me to ask for suggestions. I think what I'll do is have a DirectXEngine class which does all the base DirectX stuff. It won't completely abstract the renderer - that's far too much work for a simple learning exercise - but it will do anything that needs the Direct3DObject, and it will make it slightly easier if I did ever decide to rewrite it in another API.
I didn't like the idea of a bunch of static variables holding the Direct3D handle, which was what prompted me to ask for suggestions. I think what I'll do is have a DirectXEngine class which does all the base DirectX stuff. It won't completely abstract the renderer - that's far too much work for a simple learning exercise - but it will do anything that needs the Direct3DObject, and it will make it slightly easier if I did ever decide to rewrite it in another API.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
