We’ve got an iPad game that uses a mixture of SpriteManager sprites, and other objects (particle systems for explosions, 3D boxes for walls and shots). All seemed to be great, and in fact we were doing final testing in preparation for submission to Apple, when suddenly:
All our sprites have frozen, while the rest of the game continues to work normally.
By “frozen” I mean that no attempts to change the size, position, number, or animation of the sprites on screen has any effect. I see seven sprites, which were the ones there at the end of the last game, and they are frozen (no longer animating). These should have been destroyed. Conversely, when I start a new game, or even go to the game’s Help screen, I create new sprites. These do not appear. Yet all the non-sprite objects (walls, shots, explosions) are working fine. All symptoms point to the SpriteManager simply not updating its trimesh at all; the sprites I see are the ones from an hour ago, when the problem first appeared, and no manipulations I can do from the outside seem to affect this at all.
But here’s the awful part: this occurred only after a long period (an hour or so) of testing, during which everything worked flawlessly. And of course this is on the device, not running under the debugger. Attempts to reproduce it on another device have so far failed. So I have no way to poke at the internals, and no way to reproduce the problem.
So I’m appealing here… has anybody ever run into this? Does it trigger an “oh yeah, we saw that once, and it turned out to be…” memory for anyone?
Many thanks,
Do you use SpriteManager or Spritemanager2? I’ve been using SM2 for ages now and have never come across anything like this.
If it were me, I’d be deleting the plug-in, reinstalling and rebuilding the atlases.
We’re using SpriteManager… didn’t know there was a SpriteManager2. I think it’s too late for this project (we want to submit, like, tomorrow), but I’ll check it out for the next one.
I finally caught it doing it again, and found a NullReferenceException at UnityEngine.Transform.TransformPoint, called from Sprite.Transform, called from LinkedSpriteManager.TransformSprites, called from LinkedSpriteManager.LateUpdate.
The problem seems to be that there’s a sprite in the activeBlocks list that has no client set. Some of the sprite methods check for a null client, but .Transform and .TransformBillboarded do not. So I added “if (clientTransform == null) return;” to the top of each of those.
Then I started pondering how we could have gotten into this situation in the first place. That’s a bit harder, and I still don’t fully understand it. It’s some edge case that involves game-over happening at the same time we’re transitioning to another room, so we’re setting things up and tearing things down in a lot of ways. Somehow we’re managing to get a sprite in the active list that’s already been cleared, though searching through the code, I don’t quite see how that’s possible.
But we realized that we don’t need to tear down the sprites right away at game-over, but can instead delay it until the next major state change (going to the high-score list). We like the look of that better anyway, and I strongly suspect it will avoid the problem. That, combined with the null checks, will hopefully be the end of it.