I begun trying Unity for iOS 2D development.

I am curious about how to work with retina devices. The first thing I did was create a 1136x640 solid rectangle sprite and throw it into my scene, then run the game on my iPhone 5.

My expectation was that this image would perfectly fill the screen - that is, the retina would "kick in". Alas, this was not the case: my sprite was much smaller than the iPhone's screen.

Then I saw the main camera game object, and played around with the size property. By default is was like 5, but I determined that the number I needed for my sprite was somewhere around 3.2.

This works and looks fine in my phone. But I am unsure if this is how I am suppose to do things: what is the correct way of supporting retina images? I feel like guessing the size property of the main camera is a bit hackish. Actually, how do I know if Unity is indeed using retina?


1 Answer 1


Unity provides the Screen class which provides the current resolution and the screen's current DPI.

Unity won't have a concept of "kicking in Retina" though.

The game will simply run at a higher resolution if Retina technology is present on the device, and in fact, a common "hack" (that I would discourage the use of) to detect Retina is to simply check if the game is running on an Apple device that supports it.

Now there are Android devices and PC displays that have even higher DPIs so you should use a device-agnostic method to detect high-DPI screens.

And a small note, I'm not sure if you were just testing the DPI, but your example sounds like what you wanted was a "pixel perfect" camera, where 1 pixel directly corresponds to 1 unit in Unity. The formula I've used to get the correct size to do this is:

screenWidth / ((( screenWidth / screenHeight ) * 2 )

This provides a value that can be used with the size variable of an orthographic camera.

  • \$\begingroup\$ Do I have to provide images for standard and retina resolution? If I provide only standard, won't it look odd in retina display? If I provide only retina, I suppose that it will be overkill on an older device. \$\endgroup\$
    – Saturn
    Sep 16, 2014 at 1:35
  • \$\begingroup\$ I've used two sets of textures in the past, and I've seen others use that method. I highly recommend it, since down-scaling also has problems besides memory usage. Providing programmatic support for the two sets of textures make switching at runtime trivial. I know one toolkit uses a naming convention, in which retina resolution versions of textures append "2x" to the original name. This allows the toolkit to load those textures on certain devices. You can easily implement something similar, based on naming, folders, or even an in-editor manager that builds metadata. \$\endgroup\$ Sep 16, 2014 at 2:42
  • \$\begingroup\$ I forgot to mention this (I remembered it a bit later), but all of these things also make for a great "HD" release. That also lets you take advantage of some more aggressive performance saving techniques on older devices, resulting a smaller less-demanding build for them, and a fully featured version for newer devices, without bogging down those builds with extra assets. \$\endgroup\$ Sep 16, 2014 at 4:28

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .