I’ve been working on a game without using those @2x file extensions (I didn’t even know about it until recently). I’m just wondering if it’s really necessary. I’ve just been scaling my images to fit any device screen by stretching it. I tried updating my game to use that method but it’s really tedious and time consuming. Plus some of the graphics I have were already small so if I were to try to double the size it would just look really blurry.
If you’re graphics are small, it doesn’t matter if we resize them up or you do it in software, they are going to look blurry. We don’t know what you’re doing in your config.lua as far as setting up your virtual screen, so we can only speculate right now.
1. You’re using the recommended 320x480 screen size and letting Corona SDK manage your content area on larger screens. In this case, your 1x graphics have to be designed for a 320x480 screen. There are no phones being sold today that are that low resolution (well some really low end phones maybe). On a 5 year old iPhone 4 we are going to have to double your images in both directions to make it work on a 640x960 screen. Today’s iPhone 6 family and the latest Android phones are at least that size or bigger. No tablet is that low resolution. So off the bat your graphics will be blurry on almost every device. Having @2x and @4x images is almost imperative.
- You’re using a larger content area and your graphics are designed to fit that content area. Then you are less likely going to have to stretch images, perhaps only on tablets and 1080p devices. On older devices we will have to downsize the images which could start running into memory and performance issues. The big drawback here is our widget library is designed around a 320px content area. Apple wants things still done in a 320 point system. Android is a bit more DPI based, but they want a 160 dpi screen which works out to a 320 point screen.
3. You’re targeting tablets first with a really large content area. Here your images are all designed for large screens. On most devices you’re going to cause Corona SDK to have to downsize them. But because a @4x image is really 16x the memory foot print of an 1x image, you’re going to push the boundaries of what the smaller devices can do and it will impact performance.
In an ideal world, you would provide all three classes of images, use a 320x content area, let Corona SDK pick the best image for the screen you’re on. The main drawback is this will inflate the download size of the app.
Rob
Appreciate the response. It appears that using the 2x and 4x method is what I’ll have to do. I’m really confused when it comes to what size to make my backgrounds and other image files now :(. The way I was doing it before was simple. No matter what size the background was I would just centerX, centerY and /2 to make it fit the screen perfectly but now that I’m going to be using different size images, I really don’t know how to load the images into the game.
There is a very simple formula assuming you want to support both iPhones, iPads and the wide variety of Android devices. Using a 320x480 base, to keep images on the same scale, across devices, iPads will need to have a 360px wide image (assuming portrait) while just about every other device will be happy at 320px. Some Android tablets might want around 340px. So to fit all devices, your backgrounds should be 360px wide. Now the 480px assumes a short iPhone (iPhone 4s and earlier) and IPads. Most Android Phones and the new iPhones are more HD TV in shape (16:9) which means they are tall (portrait). 480px is too short for these devices. 570px fits most devices. So using this simple setup your 1x backgrounds should be 360x570. It’s important to understand that on every device part of this background will be off screen. These are called “bleed areas” from the printing term where ink would bleed out of the desired print area and you have to leave some margin that will get trimmed. Any way on a portrait iPhone and Most Android devices, the sides will get cut off since it’s only going to show 320px of the 360px. For iPads, it’s going to show the full 360px, but take 480px out of the vertical and the rest gets cut off.
Then for your @2x double the size to 720 x 1140 and the @4x would be 1440 x 2280. Use display.newImageRect() using the 360 and 570 for the width and height and center the image on the screen.
Rob
Hi!
I don’t use multiple image sets at all! And personally I believe that for most games it is not necessary, unless you have specific requirements. For a lot of games you can get away with only using the high resolution assets as one single set. Just make sure the images you have are high quality enough so they don’t look blurry on high-end devices.
What I do is always design for iPad Air resolution ( 2048 x 1536 ) and scale down for lower end devices. There are specific circumstances that requires multiple image sets, but I do find that this issue is grossly overrated and only makes things overcomplicated.
If you make your images specifically for the lowest quality devices, then the images will be blurry when scaled up for high-end devices. However, when you design for high-end devices from the start, the images will scale down to low-res nicely in most cases - and keep your game size down as well. It is only in cases where you have soooooooooooooo many images that they would not fit in memory on lower end devices that things could require multiple image sets.
All of this is my personal opinion. Your mileage may vary, but I am making high quality BIG games, using only one set of images.
What type of game are you making?
I’m making a physics based puzzle type game. Kinda hard to explain.
Can you give me an example of how you would load your images into the game? Code-wise. And what sizes are you using for backgrounds and such?
That’s a bit of a “too general” question I’m afraid, and well documented in lots of guides and tutorials here. There are a couple of things you need to decide yourself before starting regarding different screen proportions. How do you want your app to behave / adapt inbetween iPad or iPhone (5 or 6, the tall ones I mean)? The proportions are very different, so how do you want to go about this?
I usually design for iPad, and add “extra visible space” on the taller devices - but the core gameplay and mechanics are on the portion of the screen that fits within iPad screen proportions. For Bombaroo! it was different: I designed for iPhone, and on iPad I had two graphics background images left and right filling out the extra space that I had on iPad.
Codewise, I use imageSheets because they are the most efficient. Buy Texturepacker. It is essential when using Corona.
As a novice noob, I can tell you what I did for my first iPhone app last month, and it seems to work fine. I based all art assets on an iPhone Plus at 1242x2208 because it’s at the high end of the resolution spectrum for now, and then I use zoomEven scaling in config.lua. Then I just created a single set of images, no x2 scaling, etc. I understand that this could result in memory issues on older devices, but I’m only concerned about backward compat down to iPhone 4 and pretty modern Android phones and tablets, and the app I did isn’t too complicated. It randomly displays 1 of 20 different background images and plays a random sound when the device is shaken. One of the 20 backgrounds is also coupled with particle effects as a “jackpot” response.
For full-screen elements like background images, the zoomEven config.lua scaling will “trim” off part of those full-screen images on devices with different aspect ratios than the iPhone Plus, but you can dictate which part gets trimmed in a few ways. I usually choose to trim the bottom edge of those elements by positioning them at y = 0, the top edge of the screen. I spawn the full-screen files like this: variableName = display.newImageRect(“mybackgroundimage.jpg”,1242,2208). Then you can either center them on the y axis, or position them at y = 0 to pin the top edge to the top of the device and have the bottom be trimmed on different aspect ratios.
With regular use of object.anchorY = 0, you can still perfectly position your interface elements and other graphical objects precisely where you need them to go using this method, and with zoomEven, your graphics will all scale down or up and won’t look blurry if you created them at 1242 x 2208 (until devices with larger resolutions appear).
Here’s a copy of the config.lua I’m using:
--calculate the aspect ratio of the device: application = { content = { width = 1242, height = 2208, scale = "zoomEven", xAlign = "left", yAlign = "top" } }
I know this isn’t best practice, but it might work for what you need for now.
Oh, I forgot to add that I use a Photoshop template at 1242 x 2208 to create all of my graphics to scale, so what I do is make a blank Pshop file at 1242 x 2208, and then within that file for a top nav bar, for example, I’ll make it the full width of the file, so 1242 pixels wide, but only 150 pixels tall since it’s just a nav bar, or something like that. Then I’ll pull that object into its own Photoshop file, which will then be 1242x150, and save it out to .jpg or .png that way as a 1242x150 element. That way its size is relative to the other graphics in the app, and I can create all of my graphics in Photoshop (or whatever image editing tool you’re using) to relative scale.
If you’re graphics are small, it doesn’t matter if we resize them up or you do it in software, they are going to look blurry. We don’t know what you’re doing in your config.lua as far as setting up your virtual screen, so we can only speculate right now.
1. You’re using the recommended 320x480 screen size and letting Corona SDK manage your content area on larger screens. In this case, your 1x graphics have to be designed for a 320x480 screen. There are no phones being sold today that are that low resolution (well some really low end phones maybe). On a 5 year old iPhone 4 we are going to have to double your images in both directions to make it work on a 640x960 screen. Today’s iPhone 6 family and the latest Android phones are at least that size or bigger. No tablet is that low resolution. So off the bat your graphics will be blurry on almost every device. Having @2x and @4x images is almost imperative.
- You’re using a larger content area and your graphics are designed to fit that content area. Then you are less likely going to have to stretch images, perhaps only on tablets and 1080p devices. On older devices we will have to downsize the images which could start running into memory and performance issues. The big drawback here is our widget library is designed around a 320px content area. Apple wants things still done in a 320 point system. Android is a bit more DPI based, but they want a 160 dpi screen which works out to a 320 point screen.
3. You’re targeting tablets first with a really large content area. Here your images are all designed for large screens. On most devices you’re going to cause Corona SDK to have to downsize them. But because a @4x image is really 16x the memory foot print of an 1x image, you’re going to push the boundaries of what the smaller devices can do and it will impact performance.
In an ideal world, you would provide all three classes of images, use a 320x content area, let Corona SDK pick the best image for the screen you’re on. The main drawback is this will inflate the download size of the app.
Rob
Appreciate the response. It appears that using the 2x and 4x method is what I’ll have to do. I’m really confused when it comes to what size to make my backgrounds and other image files now :(. The way I was doing it before was simple. No matter what size the background was I would just centerX, centerY and /2 to make it fit the screen perfectly but now that I’m going to be using different size images, I really don’t know how to load the images into the game.
There is a very simple formula assuming you want to support both iPhones, iPads and the wide variety of Android devices. Using a 320x480 base, to keep images on the same scale, across devices, iPads will need to have a 360px wide image (assuming portrait) while just about every other device will be happy at 320px. Some Android tablets might want around 340px. So to fit all devices, your backgrounds should be 360px wide. Now the 480px assumes a short iPhone (iPhone 4s and earlier) and IPads. Most Android Phones and the new iPhones are more HD TV in shape (16:9) which means they are tall (portrait). 480px is too short for these devices. 570px fits most devices. So using this simple setup your 1x backgrounds should be 360x570. It’s important to understand that on every device part of this background will be off screen. These are called “bleed areas” from the printing term where ink would bleed out of the desired print area and you have to leave some margin that will get trimmed. Any way on a portrait iPhone and Most Android devices, the sides will get cut off since it’s only going to show 320px of the 360px. For iPads, it’s going to show the full 360px, but take 480px out of the vertical and the rest gets cut off.
Then for your @2x double the size to 720 x 1140 and the @4x would be 1440 x 2280. Use display.newImageRect() using the 360 and 570 for the width and height and center the image on the screen.
Rob
Hi!
I don’t use multiple image sets at all! And personally I believe that for most games it is not necessary, unless you have specific requirements. For a lot of games you can get away with only using the high resolution assets as one single set. Just make sure the images you have are high quality enough so they don’t look blurry on high-end devices.
What I do is always design for iPad Air resolution ( 2048 x 1536 ) and scale down for lower end devices. There are specific circumstances that requires multiple image sets, but I do find that this issue is grossly overrated and only makes things overcomplicated.
If you make your images specifically for the lowest quality devices, then the images will be blurry when scaled up for high-end devices. However, when you design for high-end devices from the start, the images will scale down to low-res nicely in most cases - and keep your game size down as well. It is only in cases where you have soooooooooooooo many images that they would not fit in memory on lower end devices that things could require multiple image sets.
All of this is my personal opinion. Your mileage may vary, but I am making high quality BIG games, using only one set of images.
What type of game are you making?
I’m making a physics based puzzle type game. Kinda hard to explain.
Can you give me an example of how you would load your images into the game? Code-wise. And what sizes are you using for backgrounds and such?
That’s a bit of a “too general” question I’m afraid, and well documented in lots of guides and tutorials here. There are a couple of things you need to decide yourself before starting regarding different screen proportions. How do you want your app to behave / adapt inbetween iPad or iPhone (5 or 6, the tall ones I mean)? The proportions are very different, so how do you want to go about this?
I usually design for iPad, and add “extra visible space” on the taller devices - but the core gameplay and mechanics are on the portion of the screen that fits within iPad screen proportions. For Bombaroo! it was different: I designed for iPhone, and on iPad I had two graphics background images left and right filling out the extra space that I had on iPad.
Codewise, I use imageSheets because they are the most efficient. Buy Texturepacker. It is essential when using Corona.
As a novice noob, I can tell you what I did for my first iPhone app last month, and it seems to work fine. I based all art assets on an iPhone Plus at 1242x2208 because it’s at the high end of the resolution spectrum for now, and then I use zoomEven scaling in config.lua. Then I just created a single set of images, no x2 scaling, etc. I understand that this could result in memory issues on older devices, but I’m only concerned about backward compat down to iPhone 4 and pretty modern Android phones and tablets, and the app I did isn’t too complicated. It randomly displays 1 of 20 different background images and plays a random sound when the device is shaken. One of the 20 backgrounds is also coupled with particle effects as a “jackpot” response.
For full-screen elements like background images, the zoomEven config.lua scaling will “trim” off part of those full-screen images on devices with different aspect ratios than the iPhone Plus, but you can dictate which part gets trimmed in a few ways. I usually choose to trim the bottom edge of those elements by positioning them at y = 0, the top edge of the screen. I spawn the full-screen files like this: variableName = display.newImageRect(“mybackgroundimage.jpg”,1242,2208). Then you can either center them on the y axis, or position them at y = 0 to pin the top edge to the top of the device and have the bottom be trimmed on different aspect ratios.
With regular use of object.anchorY = 0, you can still perfectly position your interface elements and other graphical objects precisely where you need them to go using this method, and with zoomEven, your graphics will all scale down or up and won’t look blurry if you created them at 1242 x 2208 (until devices with larger resolutions appear).
Here’s a copy of the config.lua I’m using:
--calculate the aspect ratio of the device: application = { content = { width = 1242, height = 2208, scale = "zoomEven", xAlign = "left", yAlign = "top" } }
I know this isn’t best practice, but it might work for what you need for now.
Oh, I forgot to add that I use a Photoshop template at 1242 x 2208 to create all of my graphics to scale, so what I do is make a blank Pshop file at 1242 x 2208, and then within that file for a top nav bar, for example, I’ll make it the full width of the file, so 1242 pixels wide, but only 150 pixels tall since it’s just a nav bar, or something like that. Then I’ll pull that object into its own Photoshop file, which will then be 1242x150, and save it out to .jpg or .png that way as a 1242x150 element. That way its size is relative to the other graphics in the app, and I can create all of my graphics in Photoshop (or whatever image editing tool you’re using) to relative scale.