[RESOLVED] Strange bug where some sprites are missing/scrambled into grey lines or dots

Hi

Apologies for this wall of text but I have been on this issue for about 10 days now :confused:

I have a menu where the player can choose one of various levels to play, then when they get game over or complete it, they can return to this menu to select and play a different one.

In the editor on the PC, the menu and all the levels work 100% fine, with no error messages in the console.

And when testing on an Android device, they all work fine except for one weird exception…

There is one specific level that makes another specific level glitch out with scrambled/missing sprites if you go from it to the other (using the menu in-between). These scenes are both < 1MB.

So both these levels play fine, just like all the others, in any circumstance other than if you play them one after the other. And they are far from the largest in the game (largest scene is 10mb).

The visual bug/glitch is that some of the larger sprites (2048) are missing, and some are scrambled into grey lines/dots.

I have seen this once before and after assigning some items in the inspector that I forgot, it went away so I figured it was a null reference exception.

I am not carrying anything between the two scenes like with DontDestroyOnLoad or anything.

But I am using PlayerPrefs to call some data between scenes - Scores, visual customization of items etc.

What I initially tried:

  • A GUI console on the device for a null reference check (in case it wasn’t showing in the editor but was on device).

  • Deleting both scenes after copying/pasting all their objects into fresh ones.

  • Deleting/rebuilding the library/re-importing the project.

  • Copying/pasting the images into “new/fresh” PNGs and bringing them into the project and swapping them - In case they were corrupted or something.

None of that worked.

Then someone on Reddit said it sounds like I might be hitting Unity’s memory limit for images as they had seen similar when working with 60 1024 sprites, so I tried:

  • Temporarily reducing the problem sprites max size to 1024 from 2048 and the issue stopped happening! But I really could do with 2048 and seeing as they are not an issue anywhere else in the project I wanted to carry on trying to fix it properly.

  • So I returned the max size to 2048, and implemented a scene transition system using Resources.UnloadUnusedAssets() - Without using LoadScene.Async to keep memory use down as much as possible.

  • Staggered enabling of game objects at start of scene.

None of that worked.

Then I finally thought I got somewhere when I discovered:

  • If I swap the problem (1.6MB) 2048 sprites, for different (700KB) 2048 sprites, the problem stopped.
  • So I thought it must be down to the file size, but then while experimenting further, I discovered that 200KB 2048 sprites using the same main colours (snow colours like white/grey/blue) as the 1.6MB 2048 sprites, they STILL cause the issue. So it appeared the colours themselves were causing it. The working 700KB 2048 sprites were mostly greens.
  • So then I re-coloured the 200KB 2048 snow coloured sprites to blue to test, and they work FINE. I really thought I had cracked it here and just needed to tweak the colours due to some weird colour related bug.
  • But then after doing so and the 2048 sprites in question were no longer glitching, the glitch passed on to the only other 2048 sprite in the scene (an interactable game object) which is not snow coloured at all (bright red) - It’s never done it on that one before. So its almost as if the glitch works its way through the sprites in the scene until it hits one it can mess with.

I REALLY appreciate any help, advice or suggestions on this! If it comes to it, I’ll have to admit defeat and keep the max size of the snow coloured sprites at 1024 but that really makes me feel uneasy as I worry the problem will surface again down the line.

Thank you so much!

Have you tried playing with the atlas modes on your sprites? There’s probably not a lot of benefit to atlassing huge sprites, so for anything with size 2048 or larger you could try disabling that. I don’t recall the name of the relevant setting, unfortunately.

and check device log for possible warnings/errors

As far as I am aware the size of the source images has no effect on the size of the packaged sprites or textures in Unity, due to how GPU-compatible compression works. However, the content of source images can certainly impact the sprite packing (e.g. different empty pixels could lead to it being packed differently), which could move the issue to another sprite, or potentially work around it in some cases.

Thank you for the suggestion but I am not using atlases (yet)

Awesome, thank you. I will give that a go

Interesting. Ah yes, you are right they all appear 4mb in the inspector. Hmm ok I will see what difference other edits to the content of the images makes… Maybe it is just some freak occurrence packing as you said. Thanks very much

Unity atlasses things for you automatically. See: Sprite (2D and UI)

Depending on what version of Unity you’re on, it either uses Sprite Packer (older) or Sprite Atlas (newer). Finding and tweaking the options for those could allow you to work around whatever issue you’re hitting on devices.

As well as logs as suggested by mgear, have you tried a different device, or building with different texture compression options?

Hey. Thanks for your reply again. I have just done another 10 hours of testing/tweaking etc and haven’t fixed it completely but think I now have a workaround that will suffice…

Thank you for pointing me in the direction of the atlas the settings you mentioned, I had a play with them as well as other sprite settings but didn’t manage to remove the issue through them unfortunately.

Then I tried a few little things I found in other threads (which might not even be the same issue but thought worth a shot). I’ll link these here in case someone in the future might find them useful:

https://discussions.unity.com/t/735394
https://discussions.unity.com/t/750887
https://answers.unity.com/questions/1192957/corrupted-sprites-in-builds-only.html
https://answers.unity.com/questions/1196020/sprites-appears-corrupted-in-standalone-build-but.html

Finally I decided to just go with the downgrade to 1024 in the problem scene - Which I thought was a guaranteed workaround… It did remove the issue from this scene… BUT THEN THE ISSUE STARTED APPEARING IN OTHER SCENES in other 2048 sprites! I couldn’t believe it.

So then I gathered a couple of additional Android phones so in total I have:

  • Samsung S6 Android Version 7.0
  • LG V30 Android Version 9
  • OnePlus 6 Android Version 11

I appreciate they are all quite dated but it’s all I have access to right now.

Anyway, the only one the bug/glitch shows up on is the LG (which is the one I have been using up to now). The S6 and the OnePlus are fine with both 1024 or 2048.

I haven’t finished testing yet because I have downgraded the LG’s display to 1080 from 1440 in the settings and when using the build with the downgraded sprites… I haven’t seen the glitch yet. I need to carry on testing this tho, as I have only done about 10 sessions. But at the very least that’s a lot better than the guaranteed every session to see it up until now.

I am hoping it proves to be resolved @ 1080 because maybe I can just force the game to run at that or something. I will see what else I can figure out when I get back to it tomorrow.

Think I am going to downgrade all 2048 sprites in the project to 1024 too. I tweaked the problem scene layout a bit and 2048 won’t be missed so makes sense to replicate that in other applicable scenes.

Cheers!

Final update in case anyone needs in future.

Resolved via loading large sprites from resources.

The lower 1080 settings on the LG did reduce the frequency of the glitch, but it wasn’t fully gone until started using:

  • Resources.Load() on the start of scenes to load the larger sprites.

  • Destroy() said sprites just before leave a scene.

  • Resources.UnloadUnusedAssets() at the begining of the next scene.

Thanks for the replies. Much appreciated!

1 Like