Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Texture cache collision (assets incorrectly shared) #312

Closed
ryanmcnz opened this issue Sep 5, 2013 · 20 comments

Comments

Projects
None yet
10 participants
@ryanmcnz
Copy link

commented Sep 5, 2013

When having multiple Spine objects in the Pixi stage that each contain separate assets, they have texture cache conflicts with said assets that share the same names in their skin/JSON hash file.
My suggested fix for this is implementing the use of IDs in the texture cache, eg. perhaps using a UUID rather than just using the image name.

Here is a simple example I made using the AssetLoader, to show this issue:
http://www.mediafire.com/download/eq81sgt15ls5lnj/asset_spine_test.zip

This contains two cannons made in Spine that are purposely in separate files.
These have the same bone names and image names in their skin...but use different texture files, JavaScript objects, etc.

Technically their assets shouldn't clash in the cache.
An example of where this could be an issue is if I had a dog and a human, but they both contained an image reference in their skin called "head", this issue would then occur.

To load these in, I've created two sets of objects with different names in JavaScript, to show that it isn't a conflict with something such as only having one AssetLoader or recycling other objects.

When loading this example, it has a random occurrence of either showing the two cannons correctly with their different textures, or randomly showing two cannons that look the same (aka duplicating assets between them for no reason).

My solution to this issue was to give all my spine skins heavily unique image names such as:
"cannon1_img_head", instead of "head".

@ryanmcnz

This comment has been minimized.

Copy link
Author

commented Sep 8, 2013

After further investigation, this may not be a problem with the bone names...but instead the image names in Spine skins and JSON hash files.
I've successfully fixed this with two Spine characters that have the same bone names, but unique image names in each of those characters skins.

@englercj

This comment has been minimized.

Copy link
Member

commented Sep 8, 2013

If you are using our loaders it is possible there is a name collision the texture cache

@ryanmcnz

This comment has been minimized.

Copy link
Author

commented Sep 8, 2013

Cheers for mentioning that englercj, yes I am currently using the regular AssetLoader.
I can confirm that the texture cache collision is the issue occurring here.

If you'd like to see all of the tests I've done so far, including my fixed cannons and their resources, you can download them all here:
http://www.mediafire.com/download/8lo25av813oryga/fixed_spine_cannons_-_pixi.js.zip

I've updated the issue to explain this correctly, and cleaned up my wall of text :)

@photonstorm

This comment has been minimized.

Copy link
Collaborator

commented Sep 10, 2013

This happens for BitmapFonts too. It creates PIXI.TextureCache entries based on the character codes, which of course are identical if you've more than 1 font, so at present you're limited to just 1 bitmap font in your game.

@englercj

This comment has been minimized.

Copy link
Member

commented Sep 10, 2013

@photonstorm I'm not too crazy about the bitmap font implementation in general (I don't use it in grapefruit), so there are a couple issue we should fix there.

@photonstorm

This comment has been minimized.

Copy link
Collaborator

commented Sep 10, 2013

Yeah I think we're doing very similar things re: grapefruit and phaser! I use UUIDs for the texture cache entries to get around these sorts of problems.

@andrewstart

This comment has been minimized.

Copy link
Contributor

commented Sep 12, 2013

While the BitmapFontLoader stores each character in the texture cache, the BitmapText object doesn't actually look at the texture cache, so it is safe to remove that bit from the loader and/or use multiple bitmap fonts.

@choppingblock

This comment has been minimized.

Copy link

commented Nov 22, 2013

@englercj is there any way to not use the default AssetLoader with Spine objects, or might here be any know workarounds for the collision issue?

@GoodBoyDigital

This comment has been minimized.

Copy link
Member

commented Feb 9, 2014

hey guys - this issue has been hanging around for a little while! @ryanmcnz the latest version of pixi should have that sorted. If you could confirm that would be ace. Thanks!

@ryanmcnz

This comment has been minimized.

Copy link
Author

commented Feb 9, 2014

Hi Mat! This issue still appears to be occurring with the latest Pixi.js release.

I've tested this with the latest builds for both the Master and Dev branch (most recently compiled 2014-02-08), using the assets example linked in my first post.
This test was done using the latest release of Chrome, Firefox and Chrome Canary.
These all had the exact same behavior/outcome.

Expected outcome:

  • Two cannon spine animations are shown. Each uses a different texture.
  • The left one is orange with a small green square at the tip.
  • The right one is green with a small blue square at the tip.

What's occurring:

  • Two cannon spine animations are shown.
  • Sometimes the two cannons are correct.
  • Sometimes the two cannons are randomly using the same texture.

I think another test that could confirm if this bug still exists is using multiple different BitmapFonts simultaneously.
Cheers for all the awesome work on Pixi.js btw!

@GoodBoyDigital

This comment has been minimized.

Copy link
Member

commented Feb 9, 2014

@ryanmcnz sorry about this but I think I responded to the wrong post (I have been going through the issues today) this is something we will definitely be looking at post 1.5.

@ryanmcnz

This comment has been minimized.

Copy link
Author

commented Feb 9, 2014

@GoodBoyDigital Ah yes no problem, looking forward to 1.5.

@englercj englercj modified the milestones: v1.6, v1.5 Feb 9, 2014

@AndreiBarsan

This comment has been minimized.

Copy link

commented May 31, 2014

A very simple way to trigger the texture conflict is loading both Spineboy and Pixie and then trying to render Pixie. The character will look normal, except for the head, which will be replaced by Spineboy's.

@vpmedia

This comment has been minimized.

Copy link

commented Jul 15, 2014

Hi,
I've the same issue as mentioned in the current ticket, any advice how to solve it?
Are there any existing extensions which allow me to use different caching IDs?
I'm referencing this request too:
http://www.html5gamedevs.com/topic/5445-best-way-to-load-texture-atlases-with-the-same-frame-names-possible-pr/

Actually I'm working on a project which involves sharing assets between Flash and HTML5 client, so i've a fixed naming convention already applied, which is like:

asset.zip/common/spritesheets/buttons.png (which contains sequence of images 0.png,1.png,2.png..)
asset.zip/game1/spritesheets/buttons.png (which contains sequence of images 0.png,1.png,2.png..)

if(gameN/spritesheets/buttons.png exists i use that with frames (0.png,1.png), if not i fall back to common sheet ..

@englercj

This comment has been minimized.

Copy link
Member

commented Jan 24, 2015

This works differently in v3 now with the new loader system.

@englercj englercj closed this Jan 24, 2015

@englercj englercj added this to the v3.x milestone Jan 24, 2015

@englercj englercj self-assigned this Jan 24, 2015

@PainKKKiller

This comment has been minimized.

Copy link

commented Jun 30, 2017

I use pixi.js v4.5.2, I have a lot of spritesheets containing sequences of frames with names 001.png, 002.png ... etc, and I have a lot of warnings in my console which looks like this:
bundle.js:19178 Texture added to the cache with an id [001.png] that already had an entry
so I suppose this issue still isn't resolved?

@englercj

This comment has been minimized.

Copy link
Member

commented Jun 30, 2017

Can you open a new issue with a running example of the problem you are having please?

@PainKKKiller

This comment has been minimized.

Copy link

commented Jun 30, 2017

Ok, I'll try to do a reproducible example

@gle6as

This comment has been minimized.

Copy link

commented Jul 11, 2017

Hey, the problem still here. Created new issue here: #4156

@lock

This comment has been minimized.

Copy link

commented Feb 24, 2019

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.

@lock lock bot locked and limited conversation to collaborators Feb 24, 2019

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
You can’t perform that action at this time.