Jump to content
  • Advertisement
Sign in to follow this  
BNY

Best resource handling

This topic is 3945 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

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]

Share this post


Link to post
Share on other sites
Advertisement
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.

Share this post


Link to post
Share on other sites
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!

Share this post


Link to post
Share on other sites
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]

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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]

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!