Feature Request: Filename recovery from pointer

[Thulsa Doom]

As pointers to local memory may not be valid when saved and load back from disk or are even sensless by tranfering in network;
- It would be a most valuable feature to recover the corresponding filepath/name from the engine by a given pointer to a texture or mesh.

Suggestion, there may be at least a function like:
const char* getFilenameFromPointer(ITexture* text)

regards,

Thulsa

[zenaku]

IMO that's not a feature that the engine should support. Since you pass in the name of the file when you load the texture, you should also be responsible for keeping track of the filename that you passed in. Not everybody needs to keep track of it once loaded, so making it part of the engine adds bloat.

It's simple enough to do something like:

Code: Select all

class ITextureInfo {

    public:
    ITextureInfo(IVideoDriver *drv, char *filename) 
    { 
        m_Texture = NULL; 
        m_Filename = filename;  
        if(drv) 
       { 
            m_Texture = drv->getTexture(filename);
       }
    }
    
   ~ITextureInfo() {}

    ITexture *Texture() {return m_Texture;}
    char *Filename() {return m_Filename;}

    private:

    ITexture *m_Texture;
    char *m_Filename;

};


void someFunction(IVideoDriver *drv)
{
    ITextureInfo TexInfo(drv, "/some/path/to/file.bmp");

    ITexture *Texture = TexInfo.Texture();
    char *Filename = TexInfo.Filename();
}

I'm sure it has some bugs cause I just typed it in, but I hope you get the idea.

[Guest]

In principle your're right. If the feature is added to the engine,
or user introduced by a ITextureInfo class it's overhead. In general every
new feature adds more or less overhead.
But some bloat gives major advantage with respect to the big picture.
The ulterior motive behind my question is, that I imlemented a
simple XML Interface which works like this:

Code: Select all

IXMLDocument *doc = ...

SXMLData<typename> data;
	data.name = "nodename";
	data.value = (typename) value;
doc->WriteData(data);

alternatively:

doc->ReadData(data);

This works for any even complex Irrlicht typename
with to preconditions:
#1 there's no pointer stored in the typename
#2 the typename does support the operator=

The only Irrlicht typename which is currently not supported is
the ITexture and the SMaterial.

So picking up your good idea, I request Niko to extend the engine with
following features:

#1 extending the irr::video::ITexture class by a method
const char *Filename() {return (const char*) m_pFilename;}
#2 implementing
irr::video::SMaterial::operator= (const irr::video::SMaterial::SMaterial &other){..}

Thank you for your input,
T.D.