Resource management

Guess you won''t like my answer, but I think it depends on the size and type of the game.
Given a game like ''Boulder Dash'' you really don''t need to manage every resource type for itself. Ok, that''s a bad example, but I hope you get my point nevertheless

In other cases, I still have to say that it depends.
If there are many and many resources that are the same in size exactly, you probably want to split them from the other resources.
It''s way easier to deal with them seperately, since your strategy can be very simple _and_ effective.
But if that''s not the case, I don''t think splitting the space up (again) would do any good, a manager for all the remaining objects should then do a better job than four or five.

But even if you split some resource types from the others I think the memory manager for the splitted object should still be able to ''communicate'' with the ''main'' manager.
What if it suddenly needs space for additional tiles?
If they''re cascaded like this, you could perhaps even try to fuse the old and new block for tiles.

To make it short:
Second choice only if they simplify the allocation strategy significantly. Then there should still be a general manager that manages the special manager.
But if that''s the case, this could really help in reducing load.

i use a hybrid method of both. i have a cSurfaceManager which makes sure that each texture, surface or whatever is only loaded once. then i have a cSpriteManager, which loads my sprite data from a file (height, width, animation, etc) into the manager. when an object (bullet, enemy, etc) needs to be created, it requests the information from the sprite manager via the filename (the sprite file)and if its in there it returns the information copied (but a pointer to the surface), so sprite information is only loaded once. the sprite manager has a surface manager in it, because the sprites need to manage surfaces, because in the sprite files are paths to bmp files.

you have to think about how resources interact, and how they will be implemented into your game. if all resources can be handled and loaded simularly, make a template class or use polymorphism and derive from a base class to all of your different resources. if your resources are handled differently, (like mine), make your own managers or have a base manager class and derive from that, with virtual load, manage functions.

A. P. you have posted alot of questions, so i will answer them now.

quote:

---

How often do you cache out resources?

---

It depends on several factors. If a resource need to be cached out, it will be deleted in the gameloop.

Lets say:

A large terrain with 2 houses on each end. So if i am in the near of city A and i couldn''t see city B, textures, meshes,... of city B will be marked.
Then the taskmanger calls e.g. gResourceManager->FreeUnused(); and so the not needed data will be freed.
If I went now to city B, i dont need the stuff from city A. So B will be loaded and A will be cached out.

So the gResourceManager->FreeUnused() will be called in the beginning of the gameloop.

quote:

---

Are you using memory zones, priortizing resources, etc.?

---

Please define memory zones.

I want to use priortizing resources, but until now i haven''t thought much about it.

quote:

---

Do you ever clear all the registered resources (say, at the end of a level)?

---

Sure. Lets say you are playing the game and you are want to quite it. So go load the mainmenu (at this point you dont need the level data anymore) and show it.
If you want to go back to the game, the ResourceManager must load all level data again.

quote:

---

At what point are resources actually read into memory, when they are registered or is there a separate call when you resolve a resource handle to a memory pointer?

---

The resources are loaded at that point, when they needed. So firstly the will be registrated and the all resources will be loaded.


Sadly to say, i have no access to Game Programming Gems series. But in the next days i will go to the libary and look there.

Greets, Christian