Game architecture with directx
Author
I''m in the midst of design a galaga type clone, but I''m having a little trouble with the architecture of it. I have a custom windows class to handle windows creation. I also have a graphics header/cpp file for doing stuff like setting up directx. I''m stuck on how I''m going to render everything and that good stuff. Should the player and each enemey(which I''m going to have classes for) render itself, or should I just have my game class keep track of where the graphics are, and render them all. I''ll be using textured quads for all the graphics, so that may play into it as well. Please help, I don''t know how to organize all this stuff.
Thanks.
Either way can work its up to you. Notice that if you have each object drawing themslevles they will all require access to your direct3D device. This means you either have to hook each object into your Direct3d device, or you have to have your device globally visible. One way to do this (I''m not claiming this is the best way) is to have a singleton class called EngineState or something and have your direct3d device available from there. This way for each object to draw itself it just needs to include EngineState.h and then call EngineState.GetDevice() anytime it needs to use the device. (Have the one instance of EngineState created in your custom DX class you talked about).
The difficult part about organizing your rendering code IMO is the use of VBs/IBs. The easiest thing to do is have each object have its own VB/IB(IB optional) and call SetStreamSource - DrawPrimitive for each object. A more difficult but efficient method would be to have one large VB/IB which each object places its vertex/index data(probably located in your dx class or possibly in the EngineState class I mentioned) into this way you don''t have to call SetStreamSource for each object. I''m not a master at this stuff but hopefully this info made a little sense and will help you out some.
ATS
The difficult part about organizing your rendering code IMO is the use of VBs/IBs. The easiest thing to do is have each object have its own VB/IB(IB optional) and call SetStreamSource - DrawPrimitive for each object. A more difficult but efficient method would be to have one large VB/IB which each object places its vertex/index data(probably located in your dx class or possibly in the EngineState class I mentioned) into this way you don''t have to call SetStreamSource for each object. I''m not a master at this stuff but hopefully this info made a little sense and will help you out some.
ATS
Since you''ll have lots of the same image, a good way to conserve your texture memory is by having a texture manager that prevents a file from being loaded twice (just hand out reference to a texture)...
Since you''ll also have the same sprite in many cases you may want to do the same...
My point being, since you have lots of re-use of resources, it''s a good idea to keep your drawing code seperate and then have your game objects call on that code to perform the drawing. That''s just the way I do things
Since you''ll also have the same sprite in many cases you may want to do the same...
My point being, since you have lots of re-use of resources, it''s a good idea to keep your drawing code seperate and then have your game objects call on that code to perform the drawing. That''s just the way I do things
What I would do is create a class for the player, a class for the enemies, and a class for the projectiles, etc. I would recommend using a single pointer to each type and looping through each one every frame. Also, if you can, load each image outside of each class so that you don''t have to reload the image from the file once for every reference to a class.
Author
Thanks for all the advice guys. Here's what I plan on doing. Stop me now if something is wrong.
CCustomWindow - Controls all the windows creation, etc.
CGraphics - Setup and shutdown directx, load all the textures, etc.
CGame - Controls the game states, keeps track of the level, the enemies, and the player.
CPlayer - controls the player, including input and position.
CEnemy - Controls enemy posistioning and AI.
CProjectile - Controls the projectile graphics, movement, and coords.
I plan on loading all the textures with CGraphics. CPlayer and all the CEnemy's will have thier own quad with coordinates and such, along with a pointer to the correct texture. The one thing I'm not entirely sure on yet, is how to do the level graphics.
Look okay for a rough design to you guys? This is my first graphical game. I probably should have started with a tetris clone or something, but I think I can pull it off.
[edited by - moonshot on October 16, 2003 5:58:34 PM]
CCustomWindow - Controls all the windows creation, etc.
CGraphics - Setup and shutdown directx, load all the textures, etc.
CGame - Controls the game states, keeps track of the level, the enemies, and the player.
CPlayer - controls the player, including input and position.
CEnemy - Controls enemy posistioning and AI.
CProjectile - Controls the projectile graphics, movement, and coords.
I plan on loading all the textures with CGraphics. CPlayer and all the CEnemy's will have thier own quad with coordinates and such, along with a pointer to the correct texture. The one thing I'm not entirely sure on yet, is how to do the level graphics.
Look okay for a rough design to you guys? This is my first graphical game. I probably should have started with a tetris clone or something, but I think I can pull it off.
[edited by - moonshot on October 16, 2003 5:58:34 PM]
I have a base object, which in this case would be a parent of player and alien. That base class has a static pointer to the D3D device.
So then I can just do player->Draw() and it draws itself.
So then I can just do player->Draw() and it draws itself.
Nah, Tetris and Galaga probably have the same difficulty, except for maybe moving the little guys around in attack patterns. Besides Galaga was always more fun!
Author
Okay, another design question. When it comes to textures, I just want to load each different texture once. I figured I''d make a linked list of the textures, and have a texture ID for each one. So, when I create a new enemy say, I can just call the GetTexture( texture_ID ), and it''ll return the pointer to the texture I want. Of course this will require a large amount of defines, but it''ll make the code more readable that way. The defines would be like #define ENEMY_SHIP_01 11. Using a linked list would also allow me to only load the textures for each given level. When the level is over, I could release all the textures, and then just load the ones for the next level. It seems to me that I''m missing something here though. What do you guys think?
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
