I'm in a bit of a twist here that I can't seem to solve. The situation is as follows: I have a resourcemanager (finally, hurray) that takes care of "resources". It loads and unloads them, it keeps track of references. These resources can be tonnes of things: Scripts, textures, meshes, sounds, particlescripts etc etc. What I'm worried about is resources that can be animated, such as a mesh or a particle engine prototype. Every frame I will want to update the coordinates of the resource to animate it. Then the next frame update it some more... So in the end the coordinates are nothing like they were initially. Ofcourse, you see that I can not animate the resource itself because all objects linking to the resource would then change. That would look a tad silly. So I will need to make a deep copy of the entire resource, and animate that. Is that really the only way? Make a deep copy, an animate it then? It kind of defies the whole purpose of managing those kind of resources, if you have copies of them all over the place, don't you think? So, how do you deal with animated resources? I have the feeling I'm missing out on something. And for question 2: What do you think of as resources? So far I have the following things in my list (most of them TODO's): - Meshes (animated/static models, terrain) - Textures (animated (movies) and static) - Particle scripts (engines, primarilly prototypes of the engine) - Sounds - ??? Please help me fill in the list. note: I know most meshes can be linearly interpolated between frames for animating, but the first question mostly applies to resources with a non-linear behaviour, like for example particles or objects that are effected by world interaction. Thanks in advance for your input.

Personally, I don't consider any variable a resource. Resources are data not parameters.

Currently textures and sounds are the only things I handle with a resource manager.

Eh... don't listen to these guys. You seem to be leaning towards a broad definition of "resource", and there's nothing wrong with that. Of course, that said, the complications are many.

What you'd want to do for animation, etc. is to have static inputs be resources and have a separate memory allocation manager for scratch buffers, vertex buffers, texture buffers, etc. If you have pointers to these buffers within the resource, mark them somehow as transient (in the java lingo), meaning they won't be saved and will be recreated on load.

As for scripts and config files not being resources, why the hell not? Any and all static data can be a Resource for fast pre-compiled loading. Then you don't have to keep track of a bunch of singletons allocating/deallocating memory and paging for each subsystem...

Tom

I see that there are a few different opinions about this matter.
My definition of a resource is a "piece of data that can be used by multiple objects". This piece of data can be anything in my opinion ranging from textures, to meshes, to settingsfiles and much more.

I think Darkor gave me a basic idea of how to structure this. Use a second object that takes care of the animating/rendering/changing of the mesh for example. Then the resource will only serve as a prototype model for many objects.
As for particle engines, only the base settings should be loaded as a resource (particle size, speed, direction, gravity, etc etc) , and the RenderOperation, as Darkor calls it, will have its own vertex array. In the way ParadigmShift says, a temporary buffer, possibly also memory managed. The resource with the settings will only be used to animate.

Yes, I got a clearer vision now I believe.


I have another question. Having written a BMP and TGA container, do you keep the actual image data (as read from file) in memory, or do you load it in video-memory right away (glGenTextures and so forth, for you openGL users) and free the heap memory?

I just use D3DX's file to texture util-command [optionally saving the texture in non-video memory]