Best resource handling
Author
I'm beginning programming on my first game in DirectX/C++ and what I thought would be pretty straight forward isn't exactly so. I'm implementing a tile map loader/drawer class but was curious to know if there is a best way of loading my resources. For instance, the map file contains information about which sounds and bitmaps to load... but should the map class be the only class that has access to these resources? I thought about having sound and image resource managers global to everything. This has an advantage that I can access anything by index if I needed, but I don't see the purpose of having other classes able to access something irrelevant.
In general, I have planned to have Character, HUD, Map, etc. classes that load their own data and have exclusive access, yet they all have a pointer to the graphics renderer, vertex buffer, and audio player so they can use the data.
So, what is your opinion? Is there an advantage to one way or the other?
[Edited by - BNY on October 28, 2007 11:22:00 PM]
This would probably fit better into Game Programming.
You basically need to have generic resource objects. For example, your image resource can be made visible to every class type in your game that needs to render images. The image class would have it's own routines to render, and those would be hidden in it's source file. That means objects like characters aren't exposed to anything (like a graphics engine) except a simple generic class. Characters that want to render images simply call Image.Render() and leave the rest up to the hidden code. That prevents them from being exposed and connected to the graphics API.
Resource management is usually handled about the same way. You can include a reference count in your generic image class that keeps track of how many objects are using it.
You basically need to have generic resource objects. For example, your image resource can be made visible to every class type in your game that needs to render images. The image class would have it's own routines to render, and those would be hidden in it's source file. That means objects like characters aren't exposed to anything (like a graphics engine) except a simple generic class. Characters that want to render images simply call Image.Render() and leave the rest up to the hidden code. That prevents them from being exposed and connected to the graphics API.
Resource management is usually handled about the same way. You can include a reference count in your generic image class that keeps track of how many objects are using it.
Author
Ah, it makes a lot more sense now. Making a resource handler make it easier for a HUD, Map, and Character class to load images by using an object to load it for them instead of rewriting code for each class. It also makes the design much more object oriented this way. I think one of my Game Programming Gems books talks about this too.
As this is my first large game project, It's good to have GameDev people like you help me understand. Thanks!
As this is my first large game project, It's good to have GameDev people like you help me understand. Thanks!
Author
One more thing...
Since I'm not just blitting bitmaps to the display, but rather working with textured quads and perhaps some more complex geometry, the image handler would have to also contain vertex information as well if I were to render with it.
So instead, I figure I could have a model/sprite manager hold vertex data and then request textures from a texture handler. Sounds good?
[Edited by - BNY on October 29, 2007 4:14:07 PM]
Since I'm not just blitting bitmaps to the display, but rather working with textured quads and perhaps some more complex geometry, the image handler would have to also contain vertex information as well if I were to render with it.
So instead, I figure I could have a model/sprite manager hold vertex data and then request textures from a texture handler. Sounds good?
[Edited by - BNY on October 29, 2007 4:14:07 PM]
I can only guess about your exact situation, but I would imagine that may over-complicate things. If it were me, I would create a texture-quad blitter in the graphics engine, and just have images use that to render themselves.
If the textures need to be attached to their own individual quads for some reason, then it may be necessary. But you can usually do well by generating the vertices as you draw them. I believe that's how ID3DXSprite works too. It's much less of a hassle to do something like..
Image.Draw( source_x, source_y, width, height );
Image.Draw( source_x+1, source_y+1, width-2, height-2 );
..Rather than needing to create two seperate quads at startup for the same result.
If the textures need to be attached to their own individual quads for some reason, then it may be necessary. But you can usually do well by generating the vertices as you draw them. I believe that's how ID3DXSprite works too. It's much less of a hassle to do something like..
Image.Draw( source_x, source_y, width, height );
Image.Draw( source_x+1, source_y+1, width-2, height-2 );
..Rather than needing to create two seperate quads at startup for the same result.
Author
I'm going to use a static vertex buffer so each quad has its own texture coordinates when loaded in. I'll be able to rotate or scale them in 3D space easily so I won't be limited to object just facing the screen if I want to do some special effects, so it's a little more functional than ID3DXSprite.
I could generate vertices on the go, by locking and unlocking the buffer each frame, but I have been under the impression that it's slow.
I could generate vertices on the go, by locking and unlocking the buffer each frame, but I have been under the impression that it's slow.
From what I understand, you only need to lock and unlock once per frame. You just copy all of your image data in between those two calls. Any decent particle system works the same way.
Author
I'll look into this. It would probably be a lot faster if I lock and unlock the buffer a few times to draw a tile map with multiple textures than to call DrawPrimitive from a static vertex buffer for each tile. Thanks!
[Edited by - BNY on October 30, 2007 11:58:04 AM]
[Edited by - BNY on October 30, 2007 11:58:04 AM]
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement