Engine resources management
Author
I am doing a Textures manager class, later I will do a objects manager, shaders manager, etc. I think that all will hace the same structure, but I have questions about how to implement the internal "array" of elements.
What is the best (faster), store objects of the class texture or store pointers to texture objects ? tha texture manager have to be instanciated global, and only one time (singleton), or it must have a static internal array of textures ? use std::vector, a vector own class or a simple pointer/array ? it would be good to have a pointer to array of pointers to texture objects ?
Thanks!
Whether you should store pointers or instances depends on what you want to do with them. If your list of objects is going to change at any time after you initialize the texture objects, then you probably need to use pointers, since you shouldn't be recreating all of the textures each time you add one to the list or take one away. However, if you just create all of your textures once, and never want to add or remove textures from the list again until shutdown, then an array of instances is best. Whether your array of pointers/instances should be static or dynamic (either with the new operator or with a vector class) depends on whether you will know the number of textures you want to load at compile time. If your program needs exactly 29 textures every time, then create a static array of 29 textures or pointers to textures. If your program sometimes needs 9 and sometimes needs 37, then use a dynamic array so that it is sized to fit the program's needs.
Author
My texture manager will load a texture (create a texture instance, open archive, load texture data, and add the instance to internal vector) when you specify it, at the begining of each level, it will load the set of textures needed for all the level, but in a zone in which a player usually not go, if player go here, it must load new textures. So the list will be dinamically extended when needed.
When I say static I refer to a "static std::vector<texture> ...", a common structure for all texture manager objects (if there are more than one).
When I say static I refer to a "static std::vector<texture> ...", a common structure for all texture manager objects (if there are more than one).
Author
an I would store Texture objects, pointer to texture objects ? create the texture objects out, and add it to texture manager, or create texture objects only inside texture manager ?
Storing pointers to texture objects would work fine. I personally like to use a std::map of id => tex pointer.
As for creating within or outside the texture manager, that's entirely up to you. Though using the texture manager as a factory guarantees that all textures created are registered and cleaned up.
As for creating within or outside the texture manager, that's entirely up to you. Though using the texture manager as a factory guarantees that all textures created are registered and cleaned up.
A Singleton Texture Manager for OpenGL
Using Managers
You should get some ideas by reading these.
Cheers!
Using Managers
You should get some ideas by reading these.
Cheers!
Haha the singleton class is funny, mostly since it both adds junk to a class which could both be instances and allow singleton access via a function.
////////////////
// header
////////////////
class TextureManager
{
//no singleton junk, allow this to be used in instances as well
};
TextureManager &MAIN_TEXT_MANAGER();
////////////////
// source
////////////////
TextureManager &MAIN_TEXT_MANAGER()
{
static TextureManager sO;
return sO;
};
Thereby using MAIN_TEXT_MANAGER() will return you a singleton of that class using a function without crapping up a class.
////////////////
// header
////////////////
class TextureManager
{
//no singleton junk, allow this to be used in instances as well
};
TextureManager &MAIN_TEXT_MANAGER();
////////////////
// source
////////////////
TextureManager &MAIN_TEXT_MANAGER()
{
static TextureManager sO;
return sO;
};
Thereby using MAIN_TEXT_MANAGER() will return you a singleton of that class using a function without crapping up a class.
Hi there,
have a look at what Sam Lantinga did when coding Pirates Ho!:
http://www-106.ibm.com/developerworks/linux/library/l-pirates2/
He developed a template driven resource manager. You can grab an early code version there as well to get an impression of what this could look like.
Regards,
T.
have a look at what Sam Lantinga did when coding Pirates Ho!:
http://www-106.ibm.com/developerworks/linux/library/l-pirates2/
He developed a template driven resource manager. You can grab an early code version there as well to get an impression of what this could look like.
Regards,
T.
Quote:Original post by TroneX
have a look at what Sam Lantinga did when coding Pirates Ho!:
http://www-106.ibm.com/developerworks/linux/library/l-pirates2/
He developed a template driven resource manager. You can grab an early code version there as well to get an impression of what this could look like.
Though I have not looked at this site I would agree that using templates for a resource manager and related classes is the best way to go. You may want to finish the texture manager first then see how it could fit in with the above mentioned code or take ideas from the code an apply them to the texture manager.
Chris
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
