Hi people,
when starting a new project (for Android and iOS devices in mind) - which target resolution do you guys usually primarily design for? I know about all that dynamic scaling stuff etc. but when it comes to “optimal” display (without letterboxing etc…) - which resolution/ratio do you usually target first?
thanks
Marco
We have to recommend (in particular because Apple is being pretty vocal about it) that you base your content area on a 320 point system. Because iPads are more square and most phones are more rectangular (most are 16:9 today) and many Android tablets being somewhere in between, making your width 320 and your height 480 will be your best starting point.
How to defeat the black bars from letterbox can be done in one of two ways. Both require backgrounds that are bigger than the screen you’re running on. Let’s think about a Vertical app for this example. An iPad needs more space on the sides so your background needs to be bigger than the 320 points (the math works out to 360). Then for the 16:9 phones, they need more than 480 points of height (the math works out to 570 points). What is this points you ask? Well today’s screens are clearly not 320x480 pixels, they are some scale factor bigger.
Going with Apple devices, those screens are now 2x the number of pixels and 3x the number of pixels. The Retina iPad is usually considered 4x the number of pixels. By using points, we stress the idea that the content area is not a pixel measurement but a relative area.
So if you make your backgrounds 360x570 and either use the config.lua presented here: or you use the standard 320 and 480 values and use display.acutalContentHeight and display.actualContentHeight to get the bottom right corner, and display.screenOriginX and display.screenOriginY to get the top left corner, then you can position your items where you want. In the second idea, somethings may be positioned at negative x, y coordinates. Others might be positioned outside of the 320 and 480 values, but that’s why you use the calls I mentioned. The blog listed in the first one will guarantee that the top, left is 0, 0 and that bottom, right is display.contentHeight, display.contentWidth. You do have to think a little differently about positioning.
Then as long as your dynamic size factors deal with @2x and @4x assets, and you build your assets for the @4x size and then size them down to the @2x size and then the base size you should be good to go.
Rob
Thanks a lot for this detailed answer, Rob! Much appreciated!
Marco
Can I just add that we actually start with the largest resolution and scale down for other devices (our last project used 1600*2560 as its base size).
We do this because we have found that objects being dragged will move much more smoothly if you start with the larger resolution. If you use 320*480 as your base scale, and then scale up, the screenwidth is divided into 320 increments. This means that you need to move 3 or 4 pixels on the larger screen in order to move an object 1 “base pixel”.
That’s a bit hard to explain, but is very easy to see it happening. Just make a simple app where an object can be dragged at 320*480, and play it on a hi res device. Then try to drag the object a tiny tiny amount (1 pixel), and it won’t move until you’ve moved 3 or 4 pixels, which makes it stutter. Depending on your game this might not be an issue though.
thanks. Interesting! Don’t you experience memory problems on devices with low resolutions (which usually also have less available memory) with your approach?
thanks
Marco
I use 2048x1536 or 1536x2048 as my base and then just detect the offset (if one exists) with screenOriginX/screenOriginY.
I haven’t hit any memory issues but keep my graphics pretty optimized.
Thanks a lot! Could you give me a small example how you detect the offset?
thanks
Marco
A 2048x1536 image is in effect a 2048x2048 texture in memory. With 4 color channels, that means that that image is taking up 16MB of memory. iPhone 4’s and iPad 2’s only have 512M of memory and the OS takes up a lot of that. It doesn’t take too many of these files to eat up memory. Also when you’re on older hardware its more computationally harsh to downsize these images.
You can always move things fractional amounts with Corona. Moving something for .x to .x + 0.25 will move it one pixel on 4x devices.
Moving things fractional amounts wasn’t the issue. The problem was detecting fractional amounts of movement in the touch event.
In your touch function if you print out your event.x and event.y values you will see they are never fractional, they are always integers between 0-320 (if content width is set to 320). This means that you have to move your finger multiple ‘screen pixels’ on a hi res device before it detects that you’ve moved 1 ‘content pixel’. As I say it may be fine for most games, but you do lose some of the precision that you get by setting the content width/height to a higher value.
I agree with Alan here in that touch-coordinates cannot be fractional.
I’ve made a compromise and used 1026 x 684 to reduce memory requirements. Basically “iPad 1 resolution adjusted for a 4:3 aspect ratio”
I always design for exactly 2048x1536. This is the resolution of the retina iPads so I know things will look nice on even the top-end of devices. I only use one set of graphics - the highres one - and make sure all important content fits on the iPad screen ratio. iPhone 5 etc… just get to see more of the screen, but it is non-essential info. And then I just design smartly, to be honest, e.g. for full screen graphics, I would use a 1024 x 1024 blurry background scaled across the screen, with a smaller sharp and high-res image in front on part of the screen.
Of course your projects need to allow for this kind of setup.
@Rob, When i said 2048x1536 I wasn’t meaning to make your graphics 2048x2048 that would be silly 
I for one always use 2048x1536 as base “resolution” for anything from objective-c, java, openGL, directX, corona etc and so forth as it makes my life “a lot” easier to be able to support multiple devices,resolutions without swapping graphics or upsizing them or increaseing your package size with all your x2,x3,x4 etc images.
That being said @Rob is correct about the memory footprint which is why you need to be smart about how you manage your assets most if not all of the applications and/or games I have made have never gone over 40mb in texture memory. I test on iphone 4 all the way up to iphone 6+ now, and on the android side i test all the way back to the original droid and nook, all the way up to samsungs latest and nexus7’s etc.
And sure if you make all your graphics 2048x2048 and don’t use spritesheets etc. you are going to find yourself in a hurt really fast so like anything get all the input you can and then just make the best choice based on your situtation.
Just my two cents.
Interesting. That means you use one spritesheet (where assets are in retina iPad resolution) for all devices?
I’ve been assuming that using such a hi-res spritesheet/imagesheet on, let’s say an iPhone 4, would have a significant impact on performance and texture memory, so I’ve been creating my 1x, 2x, 4x sheets.
Disclaimer: What I do is not the views of Corona and/or any other developer just my own personal experience and you should get all input before making any changes to your app/game
I only design 1 size and use zoomEven in my config file and detect offset etc.
Using 1x, 2x, 4x is great when you want he best performance you can get but it has been my experience that if done right you don’t even need the headache. I have done this in the past only to find some devices having issues or not looking right or stretching etc. I really don’t like my images stretched, I am ok with them being shrunk down but hate them scaling up, I also am not a big fan of big downloads which can happen when you have a ton of assets and use 1x,2x,4x images and I have played with all resolutions.
I actually make my photoshop files at 2048x1536 “HOWEVER” what I don’t do is make any sprite sheet > 1024, and using some smart logic I can swap them in and out when i need them keeping my video memory footprint very low.
This does take some knowledge ahead of time knowing when and where to load imagesheets and the best place to add an image to a imagesheet for example putting a menu button inside of a game imagesheet isn’t the best way to go unless that image button is used a lot during game play. etc. and so forth.
But this is all just my own personal opinion and the best way for my apps/games
Asking what is the best resolution is like asking someone what is better php/.net or c# vs vb.net, mysql vs mssql etc. you are always going to get a different answer depending on who you ask
Thanks Christopher.
An interesting approach that I might just try myself 
If you make your background image 1536x2048, the texture size is 2048x2048x4.
Rob
I don’t use background images I build them on the fly with a imagesheet
But yes you are right about that
We have to recommend (in particular because Apple is being pretty vocal about it) that you base your content area on a 320 point system. Because iPads are more square and most phones are more rectangular (most are 16:9 today) and many Android tablets being somewhere in between, making your width 320 and your height 480 will be your best starting point.
How to defeat the black bars from letterbox can be done in one of two ways. Both require backgrounds that are bigger than the screen you’re running on. Let’s think about a Vertical app for this example. An iPad needs more space on the sides so your background needs to be bigger than the 320 points (the math works out to 360). Then for the 16:9 phones, they need more than 480 points of height (the math works out to 570 points). What is this points you ask? Well today’s screens are clearly not 320x480 pixels, they are some scale factor bigger.
Going with Apple devices, those screens are now 2x the number of pixels and 3x the number of pixels. The Retina iPad is usually considered 4x the number of pixels. By using points, we stress the idea that the content area is not a pixel measurement but a relative area.
So if you make your backgrounds 360x570 and either use the config.lua presented here: or you use the standard 320 and 480 values and use display.acutalContentHeight and display.actualContentHeight to get the bottom right corner, and display.screenOriginX and display.screenOriginY to get the top left corner, then you can position your items where you want. In the second idea, somethings may be positioned at negative x, y coordinates. Others might be positioned outside of the 320 and 480 values, but that’s why you use the calls I mentioned. The blog listed in the first one will guarantee that the top, left is 0, 0 and that bottom, right is display.contentHeight, display.contentWidth. You do have to think a little differently about positioning.
Then as long as your dynamic size factors deal with @2x and @4x assets, and you build your assets for the @4x size and then size them down to the @2x size and then the base size you should be good to go.
Rob
Thanks a lot for this detailed answer, Rob! Much appreciated!
Marco
Can I just add that we actually start with the largest resolution and scale down for other devices (our last project used 1600*2560 as its base size).
We do this because we have found that objects being dragged will move much more smoothly if you start with the larger resolution. If you use 320*480 as your base scale, and then scale up, the screenwidth is divided into 320 increments. This means that you need to move 3 or 4 pixels on the larger screen in order to move an object 1 “base pixel”.
That’s a bit hard to explain, but is very easy to see it happening. Just make a simple app where an object can be dragged at 320*480, and play it on a hi res device. Then try to drag the object a tiny tiny amount (1 pixel), and it won’t move until you’ve moved 3 or 4 pixels, which makes it stutter. Depending on your game this might not be an issue though.