Given that the last iOS device that uses the 1x images was the 3GS, and that was ions ago, and that all new devices are @2x or @4x, does it still make sense to include @1x images in the apps we distribute?
The reason I ask is these images can take up a lot of room, and we would like to free up some space in our app for other asset.
What do others think? Has anyone tried it?
Thanks!
Andrew
Did you read this?
http://coronalabs.com/blog/2013/09/10/modernizing-the-config-lua/
It would seem that if you are using widgets, then developing for the smaller content size is still recommended as some of the widget UI does not scale well or at all.
If you do go with the larger content size, and let Corona scale images down for you, you should test that later as not all images scale down well. Things with 1px or 2px lines will often scale badly. Those lines might “disappear” in the scaled down image. So something to consider knowing your images.
If you use some widgets like the pickerView, you need to stay with a 320x based content area. But beyond that, the 3Gs has probably dropped to a usage point where you could probably consider doing away with that.
But only you can decide when it’s right for you to drop support.
Rob
Got it. Thanks. This is really useful feedback.
@thegdog, reading that blog post, it seems that it recommends using a minimum of 800x1200 as @1x size images as oppose to 320x480 like previously. Do you know if that works if we also deploy our app to Android as well? My understanding is that if I were to use such a large content area, then it uses more texture memory. My understanding is also that some of the low-end Android devices have very limited texture memory.
So, would that cause memory/performance issues using a 800x1200 for @1x?
Thanks,
Andrew
My understanding is that it could cause some memory issues on older devices, so if you are targeting older devices that would have only used the 1x images, then maybe you need to keep doing it the older way. But if they would have gotten the 2x images, then nothing should really change. Rob would likely be able to better advise here since the games that I am working on really aren’t impacted by memory concerns normally so it’s not something that I have paid attention to that much.
@Rob - can you provide some feedback from the Corona end in terms of if this would cause issues on low-end Android devices?
I am less concerned about older devices, since those will go ahead, but we are seeing lots of $60, $70 Android devices…
Content area aside (you can still have an 800x1200 content area with half sized images for smaller screens), if your smallest image is 640x960 (or if you’re targeting 16:9 devices, 640x1136ish), then you’re dealing with either a 1024x1024 texture or a 1024x2048 as opposed to a 320x480/320x570 image that’s going to be a 512x512 or 512x1024 texture. That may look half the size, but it’s a 1/4 the the size. The 512x512 image takes up 1mb of memory. The 1024x1024 image takes up 4mb of memory.
Your older devices have less memory available RAM.
That larger image has to be downsampled to the smaller size. This takes CPU and bus time to move the image in and out of the GPU and the GPU has to work to do that down sample. Older devices have slower CPU’s and GPU’s. This extra downsizing will slow things down somewhat. Between running low on memory and a slower processor, it’s frequently better to use smaller images.
But as I’ve already said only you can decided if you need to cater to as many devices or possible or if you want to build for modern devices.
I’m going to editorialize here a bit. I’ve got quite a bit of experience in the web development world. There was a time a few years ago where new browsers like Firefox and Chrome would let us do some very cool things and build very modern websites. But there was this evil called Internet Explorer 6. IE6 broke just about everything when it came to modern web development. It was a pain to have to program for. It was a pain to test for. But businesses would refuse to drop support for it because it was still a 5% market share. The idea of telling that amount of people that “we don’t care” about you anymore was hard. Of course it’s not that “we don’t care”. It’s I have 95% of my people I can do more for. Finally it took a few brave souls to make a public stand to say “No more IE6”. It started a movement and more and more others joined the movement to a point where most people dropped support.
People found that they didn’t miss those 5% because they gained more audience without the limits in place.
Now I don’t even remember when people dropped IE7 and frankly IE8 is on it’s way out. We got used to culling the browsers that were holding us back.
I see this as the same thing.
Rob
Did you read this?
http://coronalabs.com/blog/2013/09/10/modernizing-the-config-lua/
It would seem that if you are using widgets, then developing for the smaller content size is still recommended as some of the widget UI does not scale well or at all.
If you do go with the larger content size, and let Corona scale images down for you, you should test that later as not all images scale down well. Things with 1px or 2px lines will often scale badly. Those lines might “disappear” in the scaled down image. So something to consider knowing your images.
If you use some widgets like the pickerView, you need to stay with a 320x based content area. But beyond that, the 3Gs has probably dropped to a usage point where you could probably consider doing away with that.
But only you can decide when it’s right for you to drop support.
Rob
Got it. Thanks. This is really useful feedback.
@thegdog, reading that blog post, it seems that it recommends using a minimum of 800x1200 as @1x size images as oppose to 320x480 like previously. Do you know if that works if we also deploy our app to Android as well? My understanding is that if I were to use such a large content area, then it uses more texture memory. My understanding is also that some of the low-end Android devices have very limited texture memory.
So, would that cause memory/performance issues using a 800x1200 for @1x?
Thanks,
Andrew
My understanding is that it could cause some memory issues on older devices, so if you are targeting older devices that would have only used the 1x images, then maybe you need to keep doing it the older way. But if they would have gotten the 2x images, then nothing should really change. Rob would likely be able to better advise here since the games that I am working on really aren’t impacted by memory concerns normally so it’s not something that I have paid attention to that much.
@Rob - can you provide some feedback from the Corona end in terms of if this would cause issues on low-end Android devices?
I am less concerned about older devices, since those will go ahead, but we are seeing lots of $60, $70 Android devices…
Content area aside (you can still have an 800x1200 content area with half sized images for smaller screens), if your smallest image is 640x960 (or if you’re targeting 16:9 devices, 640x1136ish), then you’re dealing with either a 1024x1024 texture or a 1024x2048 as opposed to a 320x480/320x570 image that’s going to be a 512x512 or 512x1024 texture. That may look half the size, but it’s a 1/4 the the size. The 512x512 image takes up 1mb of memory. The 1024x1024 image takes up 4mb of memory.
Your older devices have less memory available RAM.
That larger image has to be downsampled to the smaller size. This takes CPU and bus time to move the image in and out of the GPU and the GPU has to work to do that down sample. Older devices have slower CPU’s and GPU’s. This extra downsizing will slow things down somewhat. Between running low on memory and a slower processor, it’s frequently better to use smaller images.
But as I’ve already said only you can decided if you need to cater to as many devices or possible or if you want to build for modern devices.
I’m going to editorialize here a bit. I’ve got quite a bit of experience in the web development world. There was a time a few years ago where new browsers like Firefox and Chrome would let us do some very cool things and build very modern websites. But there was this evil called Internet Explorer 6. IE6 broke just about everything when it came to modern web development. It was a pain to have to program for. It was a pain to test for. But businesses would refuse to drop support for it because it was still a 5% market share. The idea of telling that amount of people that “we don’t care” about you anymore was hard. Of course it’s not that “we don’t care”. It’s I have 95% of my people I can do more for. Finally it took a few brave souls to make a public stand to say “No more IE6”. It started a movement and more and more others joined the movement to a point where most people dropped support.
People found that they didn’t miss those 5% because they gained more audience without the limits in place.
Now I don’t even remember when people dropped IE7 and frankly IE8 is on it’s way out. We got used to culling the browsers that were holding us back.
I see this as the same thing.
Rob