How should I handle 1080p/4k sprite atlas switching in a Unity 2D game?

Hi, everyone

I’m working on a 2D game in Unity, and I’m trying to figure out the best workflow for handing multiple sprite resolution tiers, mainly 1080p, 2k, 4k.

I’ve been struggling with this for nearly a week, and I still can’t find a workflow that feels clean and practical. Everything just feels awkward and overly manual.

My current understanding:

I see two main approaches:

Option A: Use Sprite Atlas Variant

  • Prepare only the 4k source assets
  • Generate lower-resolution atlas variants from the 4k atlas
  • switch atlas tier depending on quality settings

This sounds simpler, but I’m worried that:

  • visual quality of the generated lower-resolution variant may not be good enough, especially around image edges
  • if a specific 1080p asset looks bad, I won’t have much control over fixing it individually

Option B: Prepare separate source assets for each tier

For example:

  • 4k source sprites
  • 2k sources sprites
  • 1080p source sprites

Then create separate atlases for each resolution tier and switch them at runtime.

This sounds more controllable, which I prefer, because I can manually optimize a specific tier later if needed.
However, this approach also creates a lot of extra work. It feels like I would have to manually replace every sprite in the scene through code.

And then there is the Animator, which feels like the most painful part.
How is this usually handled?

Do people create separate animation clips or states like:

  • Idle_1080p
  • Idle_4k
    and then switch between them using something like Animator.Play()?

If so, how do you handle switching cleanly?
Do you also have to worry about animation timing and preserving the current playback state?

As for PPU and pivot, I think I’ve mostly figured those out already.

If anyone has experience with this kind of workflow, I’d really appreciate hearing your thoughts or seeing how you approached it.

Thanks a lot.

By the way, I feel like this should be a fairly common problem, but Unity’s built-in workflow for this still feels much more manual than I expected. I actually found an abandoned tool called 2d tool kit(which is long time ago abandoned), that has a cool freature called sprite collection that can solve my problem, too bad I can’t even buy that tool now, it‘s delisting from Unity AssetStore now.

screenshot of my game

That’s the way to go. Let Unity handle the downscaling.

Well in that case: only offer 4k sprites. I mean you aren’t going to manually review and modify each and every 2k and 1k sprite. Do you have time for that?

The lower resolution sprites will naturally have degraded image quality. Just accept that, or at best, modify the source 4k art where downscaling distorts it in a very bad way.

Most definitely not. Or so I hope. It’s the same sprite, just lower resolution, this should be as transparent as possible.

Use the Sprite Library and Resolver component.

FWIW the 1080p resolution is commonly referred to as “2k”. So you probably meant 4096, 2048, 1024 (squared) texture dimensions.

Also: do you really need a 1k variant? That’s 16x fewer pixels and memory usage. Typically a game would only need at most two variants, the full resolution and the low resolution version for GPUs with limited memory. In other words: the PC version and the mobile/web version.

Especially given that screenshot I wonder if this needs any variants at all. It’s not high-resolution (fine detail) kind of art eg it probably won’t have noticably degraded quality between 4k and 2k sprites. You’ll see it of course, but the player won’t. :wink:

Thx!

Not really, I just want to reserve a way to fix when things get off with Sprite Variant

I thought 2k is 2560*1440(QHD)

Still, thx a lot, bro.
:wink:

You aren’t entirely incorrect actually.

Most accurately “2k” is the 1080p resolution in both cinema and computing. But then came the QHD monitors and “1080p” was already a widely established technical term (if not “brand” aka “Full HD”), so the marketers thought “hmmm 2560 pixels sounds more like ‘2k’” and that’s how “2k” shifted or expanded to include the “2.5k” monitors.

Nowadays we also have “5k” spanning a wide range: 5120 pixels wide but with varying heights of 1440 at 32:9, 2160 at 21:9, and 2880 at 16:9.

hey bro, I succeed with static Sprite
but something went off with animator.
when I switch the tier of the Animator Sprite, the animator just switch back next frame


Thx a lot.

the static sprite switch successfully
but the animator sprite switch failed
I use GetSprite to change

Anything with Animations / Animators / Mechanim needs to be debugged too:

Only consider the code AFTER you have done this critical step:

Always start with the Animator state machine and prove it works in isolation, no code at all.

Here’s more reading on how to do that:

Once you are 100% confident in the animator, move onto the code:

By debugging you can find out exactly what your program is doing so you can fix it.

Use the above techniques to get the information you need in order to reason about what the problem is.

You can also use Debug.Log(...); statements to find out if any of your code is even running. Don’t assume it is.

Once you understand what the problem is, you may begin to reason about a solution to the problem.

Remember with Unity the code is only a tiny fraction of the problem space. Everything asset- and scene- wise must also be set up correctly to match the associated code and its assumptions.