Pixi.js: Texture cache collision

[gle6as]

Hello. I'm using PIXI v4.5.2 and found same problem as here https://github.com/pixijs/pixi.js/issues/312

I have tons of assets with same names in different modules of app. As I adding module to core game I dynamically creating loader and load assets with prefix. Code for asset Loader looks like that:

    return new Promise((resolve) => {

        const loader = new PIXI.loaders.Loader()

        for (let a in assets) {
            loader.add(`${prefix}:${a}`, assets[a])
        }
        loader.load((loader, resources) => {
            loader.reset()
            loader.destroy()
            resolve(resources)
        })
    })

So when I loading assets for example for 'Building1' I use code like this:

const assets = {
    body: require('../assets/tiles/house1/body.png'),
}
let textures = await Loader(assets, 'building1')`

After that in another module I use same scheme, but with another prefix. For example 'building2'
And here is the problem — PIXI automatically adds urls of assets to textureCache even if they provided with names in Loader.

So in texture cache I have:

/building1:body:Texture
/building2:body:Texture
/body.png:Texture 

Here we have warning 'BaseTexture added to the cache with an id [/body.png] that already had an entry'
And of course my modules works incorrect.

Here is fiddle (look at the console) — why we add urls, when we have explicit names?
https://fiddle.jshell.net/jz9xx0hm/7/

[englercj]

The only reason this would be causing a problem is if you are using the loader to load assets then doing .fromImage on a texture and passing in the URL. For example, since you use the resources from the loader in your example it works perfectly fine. What is the issue you are having?

That warning is just telling you that we overrode the entry for the url in the cache with something else, but since you aren't doing cache lookups by URL that shouldn't matter (and you shouldn't be doing cache lookups by URL).

why we add urls, when we have explicit names?

Because doing .fromImage(url) or .fromImage(name) are both supported methods of creating a texture from something that was loaded in the loader. I don't recommend doing it, because it is highly confusing (as you are experiencing) and to really effectively take advantage of it you kind of need to understand how the cache works. However, it was a tradeoff we made early on to have .fromImage "just work" all the time and it has stuck with us since.

[gle6as]

Thanks for reply, found that problem was in webpack, which overrides images and causing incorrect loader behavior.

[nigelgutzmann]

@gle6as can you explain in a little more detail what the issue was with webpack?

[lock[bot]]

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.