Jump to content
  • Advertisement
Sign in to follow this  
Toolmaker

Managing loaded textures?

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

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

Share this post


Link to post
Share on other sites
Advertisement
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?

Share this post


Link to post
Share on other sites
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

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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

Share this post


Link to post
Share on other sites
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 :]

Share this post


Link to post
Share on other sites
Here's what I use in my texture manager:


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 pointer

private:
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.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • 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!