Jump to content
  • Advertisement
Sign in to follow this  

Supporting Multiple Resolutions w/o Duplicating Assets

This topic is 2149 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

The company I work for develops iOS apps for children. We currently support all devices going as far back as the 3GS. That being said, our apps would run on the the following resolutions:

480x320 - original iPhone

960x640 - retinal iPhone

1136x640 - iPhone 5 Retina

1024x768 - iPad

2048x1536 - iPad Retina


We're currently using Unity and a on-size-fits-all approach where we use a generic resolution of 1366x768. This produces a few problems:

-This resolution doesn't fit anything exactly so it skews our graphics making our artwork kind sort of fuzzy on everything

-All assets have to be noticeably larger resolution textures on smaller devices (128x128 only takes up 80x80 pixels, for example)

-Massive performance issues due to filtrate bottlenecks

-Memory issues due to larger textures (the 3GS doesn't load)


Just to address that fill rate issue further: our games are small click-and-react types right now and just about every scene uses a padded 1024x1024 background texture and a 1024x1024 texture atlas for our game object. We're drawing maybe 18 - 20 things onscreen at a single time in yet, we still have very choppy frame rates.


What we'd like to do is develop a game with the following criteria in mind:

-Use one universal app

-Keep the game under 50MB

-Try to stay away from DLC to download assets that don't fit into the 50MB, if possible


My approach would be to develop all of our assets based on a generic viewport of 1024x768, which is based off of the original iPad's resolution. Then, just crop for the iPhone's 960x640 display (I'm ignoring the iPhone 5's 1136x640 display for the time being). I'd use a 480x320 display for the 3GS, iPod 4 and iPhone 4 to avoid fill rate catastrophes. I'd generate the low-res textures by rendering the high-res ones in the bundle to a texture at 50% scale, then release the high-res ones from memory. Loading will take much longer on these slower devices, but at least we don't need to keep track of duplicate assets that'll bloat our bundle.


Another approach would be to use a generic viewport of 1136x768 to account for the iPhone 5 and low-res iPad resolutions. Then, continue with the crop-n-scale routine mentioned above.

Share this post

Link to post
Share on other sites

Can also avoid using bitmap images, instead stores assets as vectors and convert to bitmap as required for the required resolution.

Vector assets are typically much smaller than bitmaps, so file size / load times usually have a good tradeoff. it also avoids getting ugly artifacts from downsampling/upsampling your bitmap art.

Share this post

Link to post
Share on other sites

What's the art style of the game? If its sprite-like, one option would be to ship assets for the lower of each bracket (that is, 480x320 and 1024x768), and then upscale rather than downscale, perhaps using an algorithm like Scale2x, or give the user the option to specify which of several upscaling algorithms they like best. You could also, optionally and perhaps for cost, offer "HD" DLC for those with the higher-resolution screens.


For the Retina 5, I'd either expand the viewfield or letter-box as appropriate -- and perhaps slide UI elements outwards so as to cover less of the playable screen.


If text and UI feature heavily in your game, you might also consider providing just UI and text at native resolution and scale for all devices, and rendering them as such. This actually goes quite a way towards "fooling" a user into not noticing the low-resolution so much -- Back in the day, Unreal running on the software renderer would render the game at 320x240 and the UI at 640x480; you never noticed the low resolution while you were in the action. Rendering UI at full resolution can also serve as a subtle visual queue for what's UI and what's not -- for example, as a hint regarding UI elements that might respond to touch, though if the entire screen responds to touch this may not work in your favor.

Edited by Ravyne

Share this post

Link to post
Share on other sites

I think we came up with a workaround. What we'd do is crop the 1366x768 width-wise to 1024x768 for everything, and use that for all iPads. Going retina it too heavy for mobile devices. Next up, we'd have two sets of assets for backgrounds: 1136x640 for iPhone and 1024x768 for iPad. All other assets that would fit in the room could be drawn at iPad-resolution, and scaled-down programmatically for iPhone. Scaling down with linear filtering seems to look nice, and although we're still adding many more pixels to the screen for these smaller screens, we don't have to double everything which allows us to meet managements goal: keep it under 50MB.


EDIT: I'd like to mention that the iPhone 5's 1136-width for native resolution is obviously too large to fit into a texture, so we crop the width down to 1024 on each side. That way, the main part of the texture takes up 1024x640 of the 1024x1024 texture. The sides that were cropped get added in the unused region of the 1024x1024. They have to be rotated to fit properly.

Edited by Vincent_M

Share this post

Link to post
Share on other sites
Sign in to follow this  

  • Advertisement

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!