Jump to content

  • Log In with Google      Sign In   
  • Create Account

Supporting Multiple Resolutions w/o Duplicating Assets


Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

  • You cannot reply to this topic
3 replies to this topic

#1 Vincent_M   Members   -  Reputation: 638

Like
0Likes
Like

Posted 28 August 2013 - 04:32 PM

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.



Sponsor:

#2 Digitalfragment   Members   -  Reputation: 842

Like
0Likes
Like

Posted 28 August 2013 - 06:09 PM

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.



#3 Ravyne   GDNet+   -  Reputation: 7321

Like
0Likes
Like

Posted 28 August 2013 - 06:58 PM

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, 28 August 2013 - 06:59 PM.


#4 Vincent_M   Members   -  Reputation: 638

Like
0Likes
Like

Posted 03 September 2013 - 10:52 AM

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, 03 September 2013 - 10:54 AM.





Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.



PARTNERS