Loading texture from memory-backed IReadFile

[FliesLikeABrick]

Hello all,

In concept, I am trying to solve an issue very similar to the one in this thread: http://irrlicht.sourceforge.net/forum/v ... p?p=214692

The solution proposed by vitek in this post is simple and certainly appears that it should work, however it does not.
http://irrlicht.sourceforge.net/forum/v ... 92#p214692

The problem is this line:

Code: Select all

  myDisplayTexture = driver->addTexture(image->getFileName(), image);
 

Firstly, IImage doesn't have a member 'getFileName()' so I replaced it with file->getFileName(). This compiles, but at run time generates the error:

LOAD PNG: can't read file
: minimap.png

This led me to look into the interface class implementations of driver::addTexture in Irrlicht/CNullDriver.cpp

Code: Select all

//! Creates a texture from a loaded IImage.
ITexture* CNullDriver::addTexture(const io::path& name, IImage* image, void* mipmapData)
{
        if ( 0 == name.size() || !image)
                return 0;
 
        ITexture* t = createDeviceDependentTexture(image, name, mipmapData);
        if (t)
        {
                addTexture(t);
                t->drop();
        }
        return t;
}
 

so I then looked at the implementation of createDeviceDependentTexture

Code: Select all

ITexture* CNullDriver::createDeviceDependentTexture(IImage* surface, const io::path& name, void* mipmapData)
{
        return new SDummyTexture(name);
}
 

As you can see, createDeviceDependentTexture simply calls SDummyTexture(name), which means that it does nothing but load from the specified file name, instead of using an already-created-and-populated IImage as the comment above the addTexture implementation says.

Any proposed alternative solutions? I'm guessing the original solution by vitek was created based by the documentation only, and not in practice -- otherwise I would expect that they would have encountered this problem when attempting to implement it with an IReadFile coming from an in-memory pseudofile.

The only solution I can think of at the moment is something like the second option in vitek's post, to copy the texture data manually. I'd quite like a cleaner solution like the first one, performance is not important in this particular use case. I suppose I might as well start pursuing that option until a better one comes up.

Irrlicht devs, is there a chance you can correct the behavior above where it appears that the intent of this addTexture implementation is to use the already-loaded IImage but the implementation does otherwise? That is the underlying problem here, and it ultimately is only compatible with one specific implementation of IReadFile (one where that filename actually exists on the filesystem in the expected location)

[hendu]

I'm loading textures from RAM just fine, though I use getTexture:

IReadFile *f = irr_loadfile(tmp, &buf);
driver->getTexture(f);

Where irr_loadfile is my own helper function that returns an IReadFile via CreateMemoryReadFile.

[FliesLikeABrick]

Can you post your helper function? It turns out I was very wrong in my original post, it was actually my createImageFromFile() call which was generating the error, not the addTexture() call.

Here is what I am doing now, similar to what you just mentioned:

IReadFile *file = IRR.device->getFileSystem()->createMemoryReadFile( server->minimap, server->minimapLen, "::dummyMinimap.png", false );


ITexture *t = driver->getTexture(file);

This yields:
[08:49:42] LOAD PNG: can't read file
: ::minimap.png
[08:49:42] Could not load texture: ::minimap.png

[hendu]

Sorry, secret sauce

The relevant parts are the same as you have. I would check two things, first is the file name unique, and second, are your minimap and -len parameters absolutely correct. If you wrote that out to a file, is it a valid png?

edit: And third, make sure you have PNG support in your irrlicht build. Might sound obvious, but if you have a custom build

[FliesLikeABrick]

Thanks for the sanity check! There was a typo in the thread function which was setting the len for the png, total derp on my part.

This turned out to be a silly issue, sorry for wasting your guys' time! It appears that this whole thing was because I took the error message to mean it was trying to actually read the file from disk when it wasn't. This is what I get for not doing checks as I write new code...