AtlasSprite strange texture issue

cocos2d for iPhone » Programming » cocos2d support (graphics engine)

AtlasSprite strange texture issue

(26 posts) (4 voices)

Started 2 years ago by PhilM
Latest reply from PhilM

Tags:

PhilM
Member

Short Description:

Using the latest 0.8 cocos rls, after reloading a layer that contains AtlasSprites, some of the sprites load as white/blank rectangles, instead of the actual image. This happens sporadically, and only occurs on 2.2.1, its fine running on a 3.0 device. If you reload the layer again, different AtlasSprites can have the issue, its not always the same ones.
It usually doesn't occur until the layer has been loaded and released at least 3 or 4 times. Anyone seen anything like this?

Full Description:

I've just checked my app on my house mates 3G running 2.2.1 and have found an issue that I can't replicate on my usual 3.0 device.

I have multiple AtlasSprites added to a 'game' layer, with various animations run on them. The issue still occurs without running any of the animations. The images are preloaded using the new addImageAsync method.

The first few times the scene and layer are loaded, everythings fine. But if you keep unloading, and reloading, some of the AtlasSprites will show as a blank/white box, instead of the image. Reload again (by going back to the menu scene, and re-entering the scene and layer again), and different sprites will have this issue, and previous ones that were white, load fine.

It may well be something in my code (I'm guessing it must be), but as its sporadic/not-consistent, its making it hard to track down.

My house mates gone out now, so can't do any more tests at this moment. Currently debating whether to downgrade my phone to 2.2.1 to do further tests, as I was hoping to submit the app today :-/

Any ideas before I start stripping back the project to do some thorough tests?

Posted 2 years ago #
GameBit
Member

I saw such behavior on one of cocos tests, but newer in my apps

Posted 2 years ago #
PhilM
Member

Interesting, when I get access to a 2.2.1 device again later, I'll try running through the tests. I'm guessing it was the AtlasSpriteTest? I'll give that a try first.

Thanks.

Posted 2 years ago #
Steve Oldmeadow
Administrator

Sounds like a problem with the async loading. Do you get the problem if you don't load asynchronously? Are you sure you don't have two threads both trying to load asynchronously? The fact that it is sporadic and inconsistent is a fairly good sign it is a multi threading issue as code will run at different speeds at different times and on different devices so you may only get issues occasionally when by chance a contention occurs.

Posted 2 years ago #
GameBit
Member

yes its AtlasSpriteTest, and it seems i can reproduce it 100% of a time (but not sure you having same problem).

that strange "archifact" in left bottom corner appears on all tests, i checked code but it seems there is no sprite for it...

Posted 2 years ago #
PhilM
Member

Thanks for the tips both of you.

That was the first thing I wanted to try Steve, as soon as my mate comes back so I can nab his phone again. I was going to disable the pre-loading & test. Your explanation makes sense.

Are you saying that 2 async loading calls to the same image could cause that? I take it loading different images should'nt have the effect, just the same image twice?

Will check for that as well as seeing whether exiting the layer whilst the loading is still going is possibly triggering it somehow.

@GameBit: that looks like its the fps counter, not sure if its directly related, but thats the end result I'm getting, just not consistent like your seeing their. Will let you know if I get the same results when I run the tests.

Posted 2 years ago #
GameBit
Member

hm, yes true, it could be fps counter

Posted 2 years ago #
Steve Oldmeadow
Administrator

@PhilM - the problem is with OpenGL ES contexts. Two threads accessing the same context at the same time will cause problems.

Posted 2 years ago #
PhilM
Member

hmmm, ok. Your right, its deffo the async loading, just removed it from one scene and it works fine, whilst the others still show the problem.

I am calling addImageAsync for multiple images in a loop. But only in the one location on layer init. I wait until all the images have loaded before creating any sprites with them.

I had a rushed 30 mins with my friends phone, as he flew threw the house before a meeting. I'll start my next batch of tests by delaying all the image usage a second, to give the loading thread a chance to totally finish & see if its still happening. If so looks like I'll need to go back to basics and create a test case. There goes any chance of submitting today :-/

Thanks for the help in finding the general cause of the issue.

Posted 2 years ago #
PhilM
Member

@GameBit: I did try the AtlasSpriteTest on the 3G device with 2.2.1 & didn't see the issue you showed. The fps showed fine. This was using the latest 0.8 cocos2d rls.

Is your setup any different to that?

Posted 2 years ago #
Steve Oldmeadow
Administrator

Looking at the code it appears each image that is added with addImageAsync creates its own EAGLContext. There could simply be some limit to how many of these shared contexts can be created. Potentially there could also be an issue with releasing the context on 2.2.1 which would explain why the problem occurs once the layer has been loaded a few times (i.e. the supply of contexts has been exhausted). We should probably put code in there to check the context has been created so we can at least log an error.

I use similar code to what is in TextureMgr but I create one shared context to load all my images rather than one per image.

Posted 2 years ago #
PhilM
Member

ooo interesting, thanks Steve. I had presumed it would create a single context, and just load one image after the other, I should of taken a look at the code. Trying to tackle this on little/no sleep probably wasn't a good idea!

I'm pre-loading about 4 or 5 images at a time, and it seems to be around load 4 or 5 that the issue usually rears its ugly little head. Think I'll put this off till I'm fresh tomorrow, and follow your lead, and try and implement something on a single context.

Thanks again for all the help. Would have taken a long time to track down the exact culprit otherwise. (BTW, CocosDenshion pre-loading is working very nicely for me at least!)

Posted 2 years ago #
riq
Key Master

yes, thanks steve.
probably reusing the context would be better.

added issue #472
http://code.google.com/p/cocos2d-iphone/issues/detail?id=472

Posted 2 years ago #
riq
Key Master

@philm: could you test again your game with cocos2d r1199 ?

(you might need to add the zlib dependency to your game, not because of this issue, but because of another feature that was added previously)

Posted 2 years ago #
PhilM
Member

I'll hopefully have access to a 2.2.1 device again in the next couple of hours. I'll update to svn shortly and let you know how I get on.

Super quick response, thanks!

Posted 2 years ago #
PhilM
Member

Afraid my house mate hasn't returned yet, so looks like I'll have to give it ago tomorrow, either with his handset, or I'll take the plunge and downgrade my device.

Posted 2 years ago #
PhilM
Member

Doh, I'm still getting the error using svn 1199 (although I didn't have to include zlib to compile that version)

It never happens on the first 2 runs of the scene, then sometimes kicks in on the 3rd or 4th, always by the 5th. The scene I'm testing against loads 5 images via the async method, and clears them from the cache when the scene ends.

ooooo - I've just tried to delay my sprite display code, if I add a delay of 0.5 seconds before initializing my AtlasSprites, the error seems to disappear? If I reduce the delay to 0.3/0.4 then it still happens but less frequent.

So, for now, I might just use this workaround/bodge, although its not ideal. Perhaps it sometimes takes a while for the loading context to close down? Although its still very strange it never happens the first few runs...

Posted 2 years ago #
PhilM
Member

Just to clarify, I'm not trying to display the sprites until all 5 images have triggered the preloadSpritesImageLoaded method, which I set as the selector when calling the addImageAsync method.

The delay was added when the last async load is complete, instead of calling the sprite setup/display code straight away.

Posted 2 years ago #
riq
Key Master

thanks for the feedback. probably sdk 2.x doesn't support creating textures in parallel.

Posted 2 years ago #
PhilM
Member

I spoke too soon :-/

Even though it seemed to be working on those initial tests, I managed to reproduce the error later, even with a delay of 1.5 seconds, although it does happen less frequently than without the delay.

I also just tried chaining the loading, by creating an array of images, and only loading one after the previous has finished loading. This again seems a little better again (it now takes at least 10-15 loads before it triggers the bug).

I think I might just remove the async loading for now, and deal with it in update, as its already set me back another day, and starting to drive me mad!

Posted 2 years ago #
riq
Key Master

ok.
I've just re-opened the bug.
I'll try to get 2.2 device and play with it to understand why the async is failing.

Posted 2 years ago #
PhilM
Member

Thanks riq.

I've now got my app working fine without async loading, just a slight stutter whilst the loading takes place.

If I get a chance to play with it more next week, I'll let you know if I find anything...

Posted 2 years ago #
riq
Key Master

ok. I've tested it on an sdk 2.2.1 device and I could reproduce the problem.

fixed on r1218.

Posted 2 years ago #
PhilM
Member

ooo, I'll have to check this in the week. thanks!

So, by wrapping the context change & loading request in an if statement, and using [contextLock unlock]; at the end fixed it?

Did you encounter anything triggering the 'TetureMgr: EAGLContext error' in your tests with the new fix?

I'll post back my results once I've tried this (may not get a chance for a couple of days).

Posted 2 years ago #
riq
Key Master

yes, it seems that placing the [contextLock unlock] at the end fixed it.
But no, I couldn't trigger the "EAGL context error" condition, but I added it just in case.

Posted 2 years ago #
PhilM
Member

That's good to hear. Sounds promising!

Posted 2 years ago #

RSS feed for this topic

Reply

You must log in to post.