Managing loaded textures?
Author
I'm currently working on my engine, and I ran into a little messy problem. I currently manage all my textures in my CTextureManager class, but that messes things up quite a bit. I need to keep adding stuff, such as rotation points, sprite height/width and the number of sprites on a row, etc. and I need double loading functions, both in my sprite class and the manager class.
So I've been thinking about what other ways to store it but the only way I can think of is by storing the textures in a static map inside the sprite class itself. Then add a PreLoad() function and voila.
What do you guys recommend and how do you do it yourself?
Toolmaker
Let's see if I'm understanding this correctly. Basically, you have a sprite manager, not a texture manager? So the manager stores information other than just the raw picture data? Assuming this to be the case, this is how I would probably handle it.
Separate that functionality. Have separate sprite objects, which know their own rotation, size and such. Have the texture manager handle only the raw image data (and possibly the size of the image, if you find that necessary). When a sprite is told: "You need the image 'apple.bmp'," it goes to the texture manager and asks for the raw data. This way, you can have many objects which use the same texture data, but each sprite can still keep track of other attributes like your rotation point and the overall size of the sprite.
Is this what you were asking, or did I completely misunderstand?
Separate that functionality. Have separate sprite objects, which know their own rotation, size and such. Have the texture manager handle only the raw image data (and possibly the size of the image, if you find that necessary). When a sprite is told: "You need the image 'apple.bmp'," it goes to the texture manager and asks for the raw data. This way, you can have many objects which use the same texture data, but each sprite can still keep track of other attributes like your rotation point and the overall size of the sprite.
Is this what you were asking, or did I completely misunderstand?
Author
You have a little misunderstanding here.
I have a Sprite class, which holds it's rotation, location, etc. However, my sprite also has the ability to load a texture from file, and to take a texture via the texture manager.
The point however comes into play when we're talking about the rotation centre, and animation info. For instance, my rocks_big.bmp have 4 images in it, which are each 64*64 and have 2 per row. This means, my final bitmap is 128*128. Thus, that information needs to be stored aswell in the manager.
As for now, I'm kind of rewriting it and adding the texture management into the sprite class as a few static functions. This way, I don't need an additional class anymore and I got all data managed locally.
Toolmaker
I have a Sprite class, which holds it's rotation, location, etc. However, my sprite also has the ability to load a texture from file, and to take a texture via the texture manager.
The point however comes into play when we're talking about the rotation centre, and animation info. For instance, my rocks_big.bmp have 4 images in it, which are each 64*64 and have 2 per row. This means, my final bitmap is 128*128. Thus, that information needs to be stored aswell in the manager.
As for now, I'm kind of rewriting it and adding the texture management into the sprite class as a few static functions. This way, I don't need an additional class anymore and I got all data managed locally.
Toolmaker
I recently updated my texture manager to handle tile-sheets. Basically, instead of having the sprite call TextureFromFile(filename), I have it call TextureFromResource(resourceID,&sprite).
The resourceID is just an enum. The loader then loops through the resource definitions [the enum, the filename for the tilesheet to load, and 4 floats representing the min/max texture coordinates; all defined at program start (currently by hand, by config file in future)] to find the one that matches the ID. It goes into the sprite and sets its texture coordinates, and returns the texture pointer [possibly creating the texture in memory if it's not loaded].
The texture loader doesn't care about rotation issues or sizing. It just anchors the texture at the 4 sprite vertices.
The resourceID is just an enum. The loader then loops through the resource definitions [the enum, the filename for the tilesheet to load, and 4 floats representing the min/max texture coordinates; all defined at program start (currently by hand, by config file in future)] to find the one that matches the ID. It goes into the sprite and sets its texture coordinates, and returns the texture pointer [possibly creating the texture in memory if it's not loaded].
The texture loader doesn't care about rotation issues or sizing. It just anchors the texture at the 4 sprite vertices.
Author
Tile-sheets, do you mean in the form of animation sequences? You know, stuffing all the states of an object into 1 single image file?
I do that aswell, and I set the tile dimensions with a function. Then I proceed to do SetActiveSprite() which calculates the rect used for the blit.
Toolmaker
I do that aswell, and I set the tile dimensions with a function. Then I proceed to do SetActiveSprite() which calculates the rect used for the blit.
Toolmaker
Erm, yes; though I use them for the various tile my map might hold, or the various images of different units so that I don't need to swap textures when rendering a bunch of them together.
I don't pass the rect though, so the like sheet might look like:
Rather than requiring a fixed dimension. Perhaps I'm just missing details on what problem you're having. For mine, there's no double loading. The sprite class stores a pointer to the entire texture [the entire tile sheet] and vertex info [including texture coordinates which specify what part of the tile sheet is rendered onto the sprite]. Since the vertex info is just a bunch of floats, that handles any sort of rotation and sizing issues too.
Perhaps if you could explain your problems, or perhaps ask questions that'd help :]
I don't pass the rect though, so the like sheet might look like:
------------------------| | || | || | | | |----------|| | || | || | ||----------------------|Rather than requiring a fixed dimension. Perhaps I'm just missing details on what problem you're having. For mine, there's no double loading. The sprite class stores a pointer to the entire texture [the entire tile sheet] and vertex info [including texture coordinates which specify what part of the tile sheet is rendered onto the sprite]. Since the vertex info is just a bunch of floats, that handles any sort of rotation and sizing issues too.
Perhaps if you could explain your problems, or perhaps ask questions that'd help :]
Here's what I use in my texture manager:
I keep the manager focused on one thing: loading raw textures. It works for me so far. I'm trying to make an Ultima I type game, and it works great for the terrain tiles, player images, font, etc.
Take care.
class CTexture{public: CTexture(void); ~CTexture(void); CTexture *Next; GLuint ID; char *Name;};/***********************************************************************************************/class CTextureManager{public: CTextureManager(); ~CTextureManager(); void RestoreTextures(void); // like after an ALT-TAB CTexture * LoadTexture(char *); BOOL ReloadTexture(CTexture *); CTexture * FindTexture(char *); // finds texture object with specified name if it exists GLuint GetTextureID(char *); // returns texture ID for texture object with specified name, if it exists CTexture * FindTextureID(GLuint); // finds texture object with specificed tex id if it exists CTexture * FindLastTexture(void); // iterates from Root to next available NULL Next pointerprivate: DWORD Textures; // number of texture objects in existence CTexture *RootTexture;};I keep the manager focused on one thing: loading raw textures. It works for me so far. I'm trying to make an Ultima I type game, and it works great for the terrain tiles, player images, font, etc.
Take care.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
