koobas.hobune.stream
2D Sprite Graphics Glitching, Skewing, Flickering, Crazy, Haywire
Every so often on Windows PCs, two different 2D projects from different Unity versions have the graphics go haywire. Sprites skewing, glitching and... well, doing what the title says. It's difficult to describe precisely, so here's a video demonstrating the general effect: https://youtu.be/fco5uP3Suvs
This comes from a project built in Unity 5.x, and now it's happening again in 2017.2 with an entirely different project. Some facts:
- Games are developed on OS X, where it doesn't appear to happen. It's worst on our Windows 7 PC (in builds and the Editor), but it's also happened mildly in 8.1. Specs:
Windows 7: Intel Pentium CPU G630 @ 2.70GHz, Dual Core, 64-bit System, 6GB RAM
Windows 8.1: Intel Celeron CPU N2830 @ 2.16GHz, 64-bit System, 4GB RAM
- It varies in extremity from not really happening to practically unplayable. No constant that I can find, no conditions regarding performance, the PC's workload or anything like that.
- In the 2017.2 project it's most likely to happen in scenes with lots of sprite tiling, but in the video there isn't a single tiled sprite.
Anyone ever seen anything like this, or have any ideas as to what might be causing it?
Update 1:
It behaves about the same regardless of whether VSync is set to "Don't Sync" or "Every V Blank", but interestingly, setting it to "Every Second V Blank" makes it extra bad--and on both Windows 7 and 8.1.
Gif from the 2017.2 project: 
Screen resolution/full screen doesn't seem to matter, and even with the "Every Second V Blank" madness it only really seems to happen when sprite tiling is involved (again, in the newer project)--and in fact, possibly only when there is more than one tiled sprite on screen.
Update 2:
Been digging and trying things out here and there, but still no real headway on this. Couple of new notes:
- Witnessed it happening bad on the "Every Second V Blank" setting on a gaming powerhouse Windows 10 PC. Specs seem unrelated at this point.
- It doesn't seem to happen if I remove the animations from the tiled zones (cycling through an array of sprites via SpriteRenderer.sprite, not Unity's animation system). Not sure that this makes sense with the older Unity 5 project, but then, nothing here really does...
- Attempts to replicate the issues from a ground-up small project haven't panned out so far. Same settings and setup, but something's apparently missing...
I'll keep digging, but I'm really surprised that this issue has happened to us on two completely different projects across two different versions of Unity while no one else seems to have ever seen it before. As it stands we can't release a game that does this, but if this was just a general Unity bug it seems like someone would have encountered it by now...
Update 3:
Found a correlation between the animation speed and the intensity of the effect, and were able to reproduce it consistently in a bare-bones project. Sent it as a bug report to Unity, and will keep this updated with any new developments.
Update 4:
Unity's response: "We have been able to reproduce this bug and have sent it for resolution with our developers."
Guess that answers the question. Thanks to all who assisted via the comments!
I'd start with the basics: update all video drivers, test-disable anti-virus during install and play, run as ad$$anonymous$$istrator, physically clean problematic machines- particularly video cards and cpu fans.
Thanks for your response. Those kinds of issues don't seem terribly likely across two PCs though (and a desktop and laptop at that), plus it's happened on someone else's PC while they were testing a game for us.
$$anonymous$$ight be screen $$anonymous$$ring from not having a vertical blank (vblank) sync in the quality settings?
Hey, thanks for your response. It's definitely not your typical screen $$anonymous$$ring, but since you asked I just double checked what (if any) effect VSync has on the newer (Unity 2017.2) project...
It behaves about the same regardless of whether VSync is set to "Don't Sync" or "Every V Blank", but interestingly, setting it to "Every Second V Blank" makes it extra bad--and on both Windows 7 and 8.1. I added a gif to the original post.
Screen resolution/full screen doesn't seem to matter, and even with the "Every Second V Blank" madness it only really seems to happen when sprite tiling is involved (again, in the newer project)--and in fact, possibly only when there is more than one tiled sprite on screen.
Looks like either some funky badly formed geometry mesh, or back buffer junk due to not clearing the camera.
Sprites are all based on layer order. I went ahead and changed the Z value of the bits in question because why not, but no go. Thanks though.
Can you confirm that, the transforms of the sprites that freak out, don't actually change their global transform values - not even for a single frame? (I'm assu$$anonymous$$g it's your camera bouncing up & down in the image, not the tiles)
Thanks for checking back. It is indeed the camera bouncing up and down, and the problem tiles are perfectly stationary.
I suspected they were SUPPOSED to be stationary, but it kinda looks like some parent transform of them might be flickering to a different scale value, or somehow generating a "skew" transform. I would suggest a double check: just Debug.Log() each objects name and its transform's global pos,rot,scale. (it still runs in final-builds as long as you don't turn debugging off. After execution, the log will be found at: https://docs.unity3d.com/$$anonymous$$anual/LogFiles.html
Another test to potentially narrow down the issue: Does this ever occur if the project is BUILT on a PC, rather than OSX?
"It doesn't seem to happen if I remove the animations from the tiled zones (cycling through an array of sprites via SpriteRenderer.sprite, not Unity's animation system)."
$$anonymous$$ay I suggest a few sanity checks inserted at this point.. e.g. confirm the sprite is not null, confirm the sprite Rect, UV is as expected., they all have the same vertices values.. and so on.
A variant would be to ensure your array is filled with only ONE different sprite- and see if the effects can be reproduced trying to "animate" that.
Hey, thanks for sticking with this.
Filling the animation array with the same sprite has the same result as disabling the animation, so it does seem to be changing to different sprites that bothers it.
Checked the rect, textureRect, uv, vertices and triangles both while the glitch was in action on a build and while it wasn't in the editor and nothing seemed out of the ordinary. $$anonymous$$ight be even stranger if there was a problem here seeing as the game works fine on OS X and often on Windows when V Sync isn't at 2, but I guess most anything is worth checking at this point...
It's also strange that while this is similar in nature to the problem from the old Unity 5 project, that one has no Tiled-drawn sprites in its scenes whereas Tiled seems to be the only constant in the new project's issues. Even stranger, I couldn't get the old project to do the problem even with V Sync at 2 on my Win8.1 PC (only one I have access to at the moment).
Hmm I suppose you could try to "animate" a different sprite- build-test, and then do the same for every sprite in the array. Or maybe you could do this in code.. change the single sprite being "animated" every 10 seconds or so, to narrow down which one it is (assumes it is a problem with one of the sprites).
Also, the sprite fields I recommended were just a few of the ones I'd check. Take a look at the sprite doc page to see other that might be worth checking.. like "packing$$anonymous$$ode" (I don't know what this one does.)
Other thoughts- how are these sprites loaded from assets? Perhaps the issues are related to how the different systems want to convert say.. a .png to a texture, and then convert it to a sprite. I would EXPECT all that stuff to be standardized across systems, but I've found myself wrong about that more than once.
Unity has confirmed this behavior as a bug with the following in response to a report:
"We have been able to reproduce this bug and have sent it for resolution with our developers."
Not sure when it's getting resolved, but I guess this finally answers the question.
Update: Issue Tracker
