Jump to content
  • Advertisement

Archived

This topic is now archived and is closed to further replies.

zilch_

Resource Management

This topic is 5933 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

Hi, This is gonna be hard to express, and I have been searching for artickles regarding it; ok here it goes. I have been thinking lately much about the handling of resources in a game. For now, It''s only about sprites having 1 or more images assigned to them. I want one large object, maybe called CResourceManager handle loading storing and handling out of new objects of a certain type. I want to AVOID having objects created e.g: entitys.insert(entitys.begin(), new HomingMissile()) to having to assign it''s sprite data from a global variable, e.g: // so the constructor reaches it; loaded somewhere else extern Sprite g_sprite_homingMissile; //constructor of homingmissile HomingMissile::HomingMissile() { m_sprite = g_sprite_homingMissile } Well that''s how I did it previously. I really don''t know how to do it better yet. I have been thinking about having a static Sprite object in for example the HomingMissile class that is assigned upon start of program and thus every created HomingMissile has it already assigned. Is this good, or bad? Oh, I''ve been thinking about this so much that it hurts in my head. In game programming gems 1 or 2 i have found a EntityManager that createas all the objects: Entity* Entity::EntityFactory(int type) { // switch on all different kinds of eneitys, like GHOST and CAR, and _new_ one of these, and return it. } Well, how will this ghost know the sprite associated with it, or don''t people have that inside the class? Well well, that''s it I guess I really hope someone can give me some clues here! Thanks zilch_

Share this post


Link to post
Share on other sites
Advertisement
My ideas involve having a Resource object that has a series of arrays inside of it that stores all the data as to what is relevent about each resource, and where to retrieve the data for it when it is needed.

For instance, the sprite object would be an array of elements, each element holding, for example, the name of a file to load, and eventually a populated pointer to a graphic API object (OpenGL or DirectX) that is ready to render when the data is loaded.

The animation object would hold references to sprite objects (by pointer to a sprite element in the sprite array) to conduct the animations.

In the game object registry, a given game object type that uses the same graphics all the time would refer to either an element in the sprite array or an element in the animation array to determine what to render when it comes time to draw that object.

And finally, in the world game object list itself, each game object would have a pointer referring to an object type in the object registry.

This methodology is a pain to hard code for testing, but it will be easier to implement when I convert the initializations of the resource arrays to instead loading text files that hold the data for each element. Then I can just modify the text files and test without having to recompile the program.

[edited by - Waverider on September 13, 2002 8:33:59 AM]

Share this post


Link to post
Share on other sites
Waverider:

To follow an example through your implementation...

At the beginning of the game, you read a file with a description of all of the elements present in the world. You distribute this info into the various classes. When you are ready to enter the first level/world state, you create instances of specific objects accordingly and store them to the world game object list.

Does the game object registry entry maintain how each object type acts? More precisely, does an object in the world game object call an update function from the corresponding game object registry?

I always have difficulty with the vision of where knowledge exists in class hierarchies....

Share this post


Link to post
Share on other sites
I haven''t fully implemented this yet, but here''s the idea:

The resource arrays have enough space to load in the information from the files, AND some pointers that start out as NULL but will eventually point to loaded data (bitmaps, sprites, sounds, etc.). The engine I have only loads them as they are needed.

For the game objects, I plan to do this:

A pointer to a base class of Behavior functions (no data, JUST functions) that I will override with derived versions corresponding to each object type. Now, I could store all these objects in an array, and give them each a name, such as "HeavyJet", "LightJet", etc. And the file''s information for the objects could have a line that says:

Behavior=HeavyJet
or
Behavior=LightJet

And when the object registry loads, it will search out the name of the behavior in the behavior obejct array, and set the pointer to that element for that object.

Then each loop I would call this function:

object.lpBehavior->Update(currentGameTimeMS, &object);

Something like that. I can''t really type up a detailed description of it all off the cuff. Hopefully you get the idea. And of course, there are other ways of doing this.

Share this post


Link to post
Share on other sites
Thanks Waverider. That was a big help for my visualization.

I noticed that you pass current game time in your update method. Does each object maintain its last updated time?

[edited by - EERookie on September 13, 2002 2:49:51 PM]

Share this post


Link to post
Share on other sites
Yes, currently. The reason I do it this way is because new objects could be passed in multiplayer with the state and time they possessed on the other machine, and on the next game loop, they will all be caught up to this machine's time. I suppose I could just catch up the objects at the point they are received, but there is another variable:

I usually keep a lastBehaviorTime and a lastRenderedTime. Objects will almost always behave each loop (as long as they have a game effect - why make a particle effect behave if we know it won't be rendered?), and will not always be rendered (because they are not on the screen for some reason - behind a wall, out of the frustum, etc.) That way I'm not always doing the calculations behind animating complex 3D objects. But if, say, for example, a large mech is behind a hill bringing its left arm to bear on a target, I will have to animate the mech anyway to calculate the direction and source of the weapon being fired.

So many problems to solve. Sometimes I try too hard to design everything at once


[edited by - Waverider on September 14, 2002 2:41:14 AM]

Share this post


Link to post
Share on other sites
I'm almost sure I understand your question (if not, it's on me for doing this as I sleep).

If you need to load in specific graphics/sounds/ect for each object, but have multiple objects that can possibly share those resources, and want to only have one instance of them loaded at once, (geez thats a big if statement)
The way I do it is a linked list. I make each resource have an ID (you could use the filename for example), a pointer to the memory of the object, and a reference count..
struct KResource		// Resource Record
{
CHAR ID[MAX_PATH];// ID Of Resource
VOID *Object; // Actual Object
LONG RefCount; // Reference Count
KResource *L,*R; // List Attributes
};
When something wants to load a resource, it would call something like "Sprite = GetResource("Missle.bmp",IMAGE_TYPE);" The function would then check through the linked list to see if that image is already loaded, and if it is, increase its reference count and just return the pointer to it. If its not, then it would create,load it, then add it to the list. When you "RemoveResource(Sprite)", you would find it in the list, reduce its reference count, and delete it if it's ref is 0.

Hope that helps at all.

[edited by - Jiia on September 15, 2002 2:44:47 AM]

Share this post


Link to post
Share on other sites
Yes, ofcourse it helps!

Is there any way to ensure that a newly created object has a certain sprite associated with it, without having to assign it for every one (e.g. in the constructor)?

Like having a static Sprite * in the class, that is assigned upon the start of the program, like this:

HomingMissile::bindSprite(SpriteManager::getInstance()->getSprite(SPRITE_HOMINGMISSILE));

In this case the SpriteManager is a singleton, as you can see, and the sprite is previously loaded with:

SpriteManager::getInstance()->loadSprite(SPRITE_HOMINGMISSILE, "data\\sprites\\hm\\hm.spr");

This makes getting the sprite faster, as it''s mapped to an int instead.

Is this a bad idea? I hate to have the constructor of an often created object having to assign it everytime.

I think i will run into problems when rendering it if it is static, but I don''t know yet. Unfortunately I can''t forsee the future in this case.

Thanks for all the help,
zilch_

Share this post


Link to post
Share on other sites
Resource Management is something i''ve just finished implementing in my engine...

essentially you have two abstract classes, one called ResourceManager and another called Resource. You inherit these to create, for example, TextureManager and Texture.

The Texture object knows how to create and delete itself etc... and the managers control all access to these created object (which are stored in a map currently).

From there you just add functionality, sorry for being so brief... i''m using this system for...

- textures
- sounds
- materials / shaders
- levels

but it can be used for many other things too...!

-jonnii

Share this post


Link to post
Share on other sites

  • Advertisement
×

Important Information

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

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!