When texture and texture atlas have same names getTextureAtlas returns texture

[sjabberwocky]

For example, we have two atlases for mobs in game: icons.png with m01 icon textures m01.png with mob animations When we use getTextureAtlas("m01") AssetManager will returns m01 texture from icons atlas.

I use latest version of Starling.

[PrimaryFeather]

I'm not sure I understand exactly what you mean — you say that the method getTextureAtlas returns a texture? That method is implemented like this:

/** Returns a texture atlas with a certain name, or null if it's not found. */
public function getTextureAtlas(name:String):TextureAtlas
{
    return _atlases[name] as TextureAtlas;
}

So I cannot see a way this method could return a texture directly — thus, I guess that I'm misunderstanding you! Could you give me some more details about your problem? Thanks in advance!

[sjabberwocky]

Hi Daniel! This is example from my game which use Starling for 5 years: I have mob with id m07. In atlas gameUi I have the texture m07 (icon for mob). Also I have atlas m07 which has animations for this mob. In Starling 2.0.2 I use getTextureAtlas("m07") and everything works fine. Then I updated to Starling 2.4.x and the new asset manager. After this update mob is invisible and sometimes it shows textures from gameUi atlas instead of proper animations. Then I renamed m07 to mech3 (unique name) and everything works fine again. The same issue I had with mob s08 with has icon in gameUi and it's own atlas s08. Looks like something going wrong when atlas and texture share the same name.

[PrimaryFeather]

What you're probable seeing is the following change I made in the new AssetManager.

Previously, when looking up a texture via manager.getTextures("name"), the AssetManager first looked through it's standard (non-atlas) textures, and if it didn't find a texture there, it looked inside the texture atlases. Now, that order has changed: it now looks inside the texture atlases first, and in the standard textures later.

That means a call to getTexture("m07") will previously have returned the standard (non-atlas) texture "m07", and now it will return the subtexture "m07" from the atlas.

Is that what you're seeing?

The reason I changed this is that very often, people are not really interested in the standard textures, but more in the atlas subtextures. E.g. if you add a texture atlas called "character" (→ character.xml and character.png) and that atlas contains a subtexture with the same name, you're typically interested in that subtexture, because there's not much you can do with the atlas texture (i.e. the big texture that contains all the subtexture).

So I figured this was a more sensible default.

Of course, it's not optimal in all cases — like in yours, where the changed behavior now produces the wrong result.

Now you've got two options:

a) Make sure the names are unique, as you did in your tests. b) You can also force the AssetManager to return the texture that's not from the atlas, like this:

var texture:Texture = manager.getAsset(AssetType.TEXTURE, "m07", false) as Texture;

The important part here is the last parameter (false) which means that texture atlases are ignored.

Does that information help in any way? Can you live with this change?

[sjabberwocky]

It's okay for me, cause I yesterday released fixed version of the game. But it was really weird when players start reporting about invisible mobs in the game which works fine for 5 years. Thank you for your comments!

[PrimaryFeather]

:bowtie: Ooops! Sorry about that! But I'm glad to hear you could already solve it.