Can we use the file path as the name of the texture - c++

Question

This is my texture manager class.
class TextureManager
{
public:
static std::map<std::string, Texture2D> Textures;
static Texture2D LoadTexture(const GLchar *file, GLboolean alpha,
std::string name);
// Retrieves a stored texture
static Texture2D GetTexture(std::string name);
// Properly de-allocates all loaded resources
static void Clear();
private:
TextureManager() { }
// Loads a single texture from file
static Texture2D loadTextureFromFile(const GLchar *file, GLboolean
alpha);
};
what i plan to do is to give the path of the image as the string parameter of the map .
when i need to load another image i will first check the Map with the given path if the image is loaded or not.
I have two questions.
1) Is this a acceptable work flow to check if the image is loaded or not
2) Can we use the path of the image as a string value of the map.

Answer 1

First, before I even answer the question, I'd strongly recommend NOT making the member vars and functions of this class static. I know initially it may seem sensible to maintain a single global set of textures, however in many cases this quickly becomes a little rubbish.
For example, let's say I have textures for a level in a game, and a set for the GUI. I then need to dump the old level textures, and load the new set for the next level, without touching those for the GUI. If all the textures exist within a single object, then it will require a little bit of work to figure out which ones I need to delete. If however they are in two texture managers (one for the GUI, one for the level), then all I need to do is delete the texture manager for the level, and create a new one for the next level.
Your current design (simply nuke all the textures) would cause havok for any loading screens / GUI textures that may be present when loading a new level.
There is nothing fundamentally wrong with using the file path as a key for your texture lookup, BUT there are a few edge cases you may need to address before it will become a robust class:
Convert all backslashes to forward slashes: e.g. C:\files\foo.jpg ---> convert to ---> C:/files/foo.jpg. This avoids the issue on windows that you can use / or .
On Windows ONLY, convert all the characters to lowercase. i.e. "C:/foo.txt", "c:/FoO.TxT", etc: they all refer to the same file. On linux/mac, those are different files. On windows they are the same file.
Beware of relative v.s. absolute paths. Ideally you'd ONLY ever use relative paths, and those would be your keys. This avoids the issue of loading C:/files/foo.jpg and ./foo.jpg.
Beware of "./foo.jpg" and "foo.jpg"
If you can handle those cases, then it should work reliably. I would however suggest a slight change to the API for purely performance reasons:
typedef uint32_t UniqueTextureId;
class TextureManager
{
private:
// increment and return for each new texture loaded.
// zero should indicate an invalid texture
UniqueTextureId m_idGenerator = 0;
// a lookup to turn the file path into a unique ID
std::unordered_map<std::string, UniqueTextureId> m_filePathToId;
// a lookup to get the texture from an ID
std::unordered_map<UniqueTextureId, Texture2D> m_idToTexture;
// a method to take a raw filepath and...
// 1. convert \ to /
// 2. make lower case on windows
// 3. convert any absolute paths to relative paths
// 4. If a paths starts with ./, remove the first two chars.
std::string tidyUpFilePath(std::string str);
// turn a file path into an integer
UniqueTextureId filePathToId(std::string messyPath)
{
std::string tidyPath = tidyUpFilePath(messyPath);
const auto& it = m_filePathToId.find(tidyPath);
if(it != m_filePathToId.end())
{
return it->second;
}
return 0;
}
public:
// return a unique ID for this texture (which can probably be
// unique only within the current TextureManager).
UniqueTextureId LoadTexture(const GLchar *file, GLboolean alpha, std::string name);
// Do not return a Texture2D object! (return a pointer instead)
// if you return a copy of the texture, there is a good chance
// the destructor will end up calling glDeleteTextures each
// time the returned object is destroyed, which will cause a right
// bother for the next frame!
const Texture2D* GetTexture(UniqueTextureId id)
{
const auto& it = m_idToTexture.find(id);
if(it != m_idToTexture.end())
{
return &it->second;
}
// Just to guard against the case where the id is invalid.
return nullptr;
}
};
One other word of caution. If you are in the situation where there may be multiple calls to loadTexture(), you should probably consider reference counting the textures. This would allow you to have a nice symmetric deleteTexture() method (where it first decrements the ref count, and only deletes the texture when the ref count hits zero).