Notes on Resolution Independence on 0.12.x
adent42
Key Master, Head Chef, Executive Chef, Member, PRO Posts: 3,170
Since there was some confusion about how the Resolution Independence feature works with the current version of Creator and the new devices/OS - we’ve compiled this summary to help clarify how the feature works.
NOTE: This applies to Creator version 0.12.6 and above.
iOS Universal / iPhone Apps
If you check Resolution Independence for an iOS Universal or iPhone Apps:
Your images will be renamed to @3x and be used on:
- iPad Retina - 2048 x 1536 (for iOS Universal)
- iPhone 6+ - 2208 x 1242
Your images will be resized to ⅔ original size and saved as @2x for use on:
- iPad - 1024 x 768 (for iOS Universal)
- iPhone 6 - 1334 x 750
- iPhone 5 - 1136 x 640
- iPhone 4 - 960 x 640
Your images will be resized to 1/3 original size and saved as the original image name for legacy iPhones (480 x 320)
This means your images should ideally be built targeting iPad (Retina) and iPhone 6+ and be 3x your actor size.
The idea is to match the image size to devices of similar resolution.
If the image sizes don't work for you, you can disable Resolution Independence. Disabling RI will do no resizing and load the images you include in the project on all platforms. In this situation, we depend on OpenGL to resize the images appropriately.
iPad Apps
This change is in QA right now but should be ready by the end of today. If you check Resolution Independence for an iPad App:
Your image will be renamed to @3x for use on iPad Retina.
Your image will be resized to ½ original size and saved as @2x to be used on non-Retina iPads.
The same ½ image will also be saved as the original image name again for completeness.
This is allows us to use the same size checks we do for iOS Universal. This will get you clean ½ resize on iPad only apps as before. Only the image name will be different.
Mac Apps
If you enable RI for Mac, we will now resize for Retina. Your image will be renamed to @2x. It will then be resized by half and saved as the original image name.
We'll also be adding the following features soon:
Legacy RI. If you've already designed your game for @2x RI only, what we'll be doing
is only writing out the original image @2x and half sized 1x images. This requires an
engine change so won't be available until 0.12.9 or so.Custom RI. This is basically like turning off RI, but in this case you will be
expected to include images to match the resolution target buckets above.The ability to toggle RI on publishing!
So this is how things are, and will likely shake out for the 0.12 final release.
I know that people will have some problems with this, namely that iPad non-Retina images will not resize evenly/sharply on iOS Universal. In these cases we suggest turning off RI if you see problems with your artwork.
If your project has problems with this system, please PM me the publishing portfolio link to the game so we can see the issue. This will help us come up with a better system for future releases.
I'd also like some input into the Custom RI feature. As a user would you rather upload the game with everything set up in the gameproj, or would you rather provide a separate zip file with all of your images renamed properly (sort of a way to patch the project)?
I hope this clears up any confusion about how RI works.
Cheers.
Comments
Will the maximum pixel dimensions increase beyond 2048 x 2048?
http://jamie-cross.net/posts/ ✮ Udemy: Introduction to Mobile Games Development ✮ Learn Mobile Game Development in One Day Using Gamesalad ✮ My Patreon Page
Here is the feature request for that
@adent43, do tiled images, with a fixed tiling size on actors, accommodate the difference in @x treatment of images between iPad and iPhone projects?
MESSAGING, X-PLATFORM LEADERBOARDS, OFFLINE-TIMER, ANALYTICS and BACK-END CONTROL for your GameSalad projects
www.APPFORMATIVE.com
Thanks for the info, very useful, and seemingly lots of options to mitigate some of the inevitable aliasing issues that comes with Apple's new 3x size.
The questions are coming . . . .
If I were going to make a Universal build in future, I would prefer to create all the images myself and upload them in a .zip file.
But this begs the questions:
what size should I set the scene in Creator;
do I make my images for actors 3 times as big as I would have in the past for an iPad or iPhone 4 or 5;
and which set of images do I use in Creator to set up the gameproject, x1, x2 or x3 images?
How will the Creator be able to handle previewing the game for all devices?
For iOS Universal as described in the OP, the scene would be 1024 x 768 as it is now.
You make your images 3 times the size of the actor (you are effectively building a 3072 x 2304 project).
If I understand your question, it would be x3.
>
>
>
>
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
>
>
I got a little lost here, these two set-ups seem to be initially identical but produce different results ?
With one we build a Retina iPad project, check RI and get a ⅔ sized file for use on non-RI iPads.
With the other we build a Retina iPad project, check RI and get a ½ sized file for use on non-RI iPads.
Maybe I'm not understanding it right ?
I suppose I could sum up my confusion by asking 'what is an iOS Universal app', if I were to build an iOS Universal app how would it be different from an iPad Retina app ?
Again, all the usual caveats, maybe I'm not fully understanding how this all works, but . .
If we were to build an iPad iOS Universal app (full screen image 3072 x 2304) and switch off RI (forcing the non-RI iPad to use the source images) then non-RI iPads will be in danger of having images sixteen times larger than they need or are able to display !
For example let's imagine a 256 x 256 pixel actor in this scenario. In the previous system this actor would have used a 256 x 256 pixel image derived from the 512 x 512 Retina source.
But if the non-RI iPad is forced (through switching off RI) to use the source files then it will get a 768 x 768 pixel image, and as 768 sits above 512 within the powers-of-two rule the image will occupy a 1024 x 1024 pixel chunk of memory, sixteen times the memory footprint of the 256 x 256 pixel actor size.
And even then it will still not solve the issue of images not resizing evenly/sharply as we are just swapping one way of mapping 3072 to 1024 for another, the math is unfortunate for the standard iPad in this new scheme however we arrange it, but I guess Apple are thinking about the future rather than worrying about their oldest iPads.
. . . . . .
One last question, what size images will be used for a Retina iPad running iOS7 when a Universal build is displayed ? From what I understand iOS7 doesn't use the 3x conventions, will these machines use the 2x assets ?
Cheers in advance for any clarification.
@Socks I think you're questions have finally cleared up for the issue me and why everyone is having such a hard time with this change.
The assumption behind our scheme is that images are 3x the size of actors an iPhone 3 (the way Apple looks at it too in all of their documentation).
But if you start with your app assuming iPad as the base resolution, then what makes sense is to do halve the size of the images instead of 2/3 because that more closely matches the image sizes we're looking for and give us a nicer resize.
So it feels like, what we should be doing is this:
If you start from an iPhone App for Universal, we do the 1, 2/3 scalings (assuming you've created your assets to 3x the size of the actor).
If you start from iPad, we do the 1, 1/2 scalings (assuming you've created assets for 2x the iPad).
The trade offs are as follows.
If you start from iPad as the basis for your Universal app, the RI images will be a bit larger than the would ideal for an iPhone only app (they'd be about right for a iPhone 6 and an iPad, but just a tad big for RI phones). Under this scheme:
1536h images for iPad RI and iPhone 6
768h images for iPhone 6-4.
If you start from iPhone, the images are larger than they need to be for the iPad RI and iPhone 6+ app then they need to be, but they're about right for iPhone 5 RI. Under this scheme:
1920h images for the iPhone 6+ / iPad
640h images for the iPhone 4-6
So if everyone understands this, I think this is what I'm going to have to implement tomorrow.
To give an example of what's going to happen and how you should take advantage of RI:
Starting with iPad as your base. Make all of your images 2x your actor size.
We will rename all of your images to @3x. We will halve your images and name those @2x (to keep the loading code the same as it is now).
Starting with iPhone as your base. Make all of your images 3x your actor size.
We will rename all of your images to @3x. We will 2/3 your images for RI using @2x.
I think that makes everyone happy in terms of image size trade-offs. I'm going to sleep on this, but please chime in with questions. I REALLY don't want to change this again!
THIS MAKES SENSE AND I LOVE THIS SOLUTION!
www.appdore.com || appdore twitter || appdore facebook
Lol
I don't blame you, nor envy you in this particular task, it can't be easy trying to make 3 fit neatly into 2 (Apple should have gone with 4x), but what you've suggested seems like a pretty decent compromise with a degree of flexibility, so thanks for the clarification.
My only question is what would a Retina iPad running iOS7 use if - for example - you built an RI Retina project, as the 3x system only applies to iOS8 would the iOS7 machine use the 2x images ?
Maybe we should all wait for the new iPad launch today as it will probably throw another spanner in the works.
Universal Binary Template - Universal Binary Template Instructions Rev 4 (Short) - Custom Score Display Template
I thought about that, but as Apple only just introduced this new 3x asset system they are unlikely to introduce anything that would fall outside that system so soon, so in theory even if they introduced a 3072 pixel iPad today it would work just fine with a 3x system, and it wouldn't cause any issues with the GS resolution scheme outlined here.
. . . . but, who knows !
what if Apple unveils a new iPad resolution today,lol.
@adent42 is there a major difference between setting RI and just letting Open GL handle the resizing (non RI)? What are you doing different with respect to resizing that Open GL wouldn't do or vice versa?
Our games http://Donkeysoft.ca
Mass developer suicide in Texas will occur...
www.appdore.com || appdore twitter || appdore facebook
From what I understand Open GL would be resizing larger files on-the-fly from the full size assets, so a lot more processor intensive.
I think this will work nicely, but I do agree we wait until today's announcement is over to see if there are any other kids in the pool.
Send and Receive Data using your own Server Tutorial! | Vote for A Long Way Home on Steam Greenlight! | Ten Years Left
Funnily enough, it isn't that terrible. In some of my games, the full size assets are retina iPad ready (a couple of them full-screen, so 2048x2048 in memory size), and the app runs very decently even on an ancient iPhone 4.
What @Socks writes is true and the older the device the larger the performance penalty. Also you have no control over the image scaling mode that iOS uses. Certain images may see significant pixelation and/or artifacts after being scaled automatically (which basically holds true in all situations unless you supply all image/image@2x/image@3x variations of the images yourself - which looks like may be a possibility with GS)
Thank you @Socks for investing the time into this very important area and of course thank you @adent42 w/team for showing that you are open to discussions in order to find the best possible solutions!
Now that is great thinking there!
As long as Apple don't give us another new surprise within the next hours...
One big question remains. If my understanding is correct there is only code in IOS8 for loading @3x image assets. Have you found a way around that so you will be able to load @3x images on IOS7 and IOS6? (I would suspect that you have not but I would love to be wrong on this one). If not then the around 50% of the IOS devices that are running IOS7 or older would load the @2x images (for retina) which in fact would be the non-retina image assets at 1024x768 (assuming we provided 2048x1536 which would be set as the @3x images).
I think we can all relax for another year, no new resolutions !
Thank God for that!
Universal Binary Template - Universal Binary Template Instructions Rev 4 (Short) - Custom Score Display Template
@pHghost said:
Yeah, it will all depend on the particular game, I imagine a well designed game will probably get through all this resolution mayhem unscathed
On a slight aside, generally speaking the powers-of-two (Po2) rule will fight with the new 3x system somewhat. If you are careful in sizing, sticking to the Po2 rule to ensure efficient memory use and making your actor - for example - 256 x 256 pixels, then when the image is downsampled to 2/3rds size it will still take up exactly the same amount of memory as the source image - as the Po2 rule is based on halving (or doubling), an image sticking to the rule needs to be at least halved to make it down to the next memory allocation size, anything short of this (like 66.6666% / 2/3rds) will mean it will still occupy the same amount of RAM.
It might not be a big issue, and like you say even an iPhone4 might be fine depending on the game, but it's something to bear in mind when designing your assets.
If you are taking the 3x 2x 1x route (rather than the 2x 1x route), then in situations where you have assets floating around values that will translate to Po2 values when reduced to 2/3rds size it might be a good idea to be alive to this.
For example when building your master (3x) project and you have a 390 x 390 pixel actor, then reducing it to 384 x 384 won't save you anything on your master sized project (3x), but it will save a massive 75% of memory usage on the 2/3rds sized project, as 390 x 390 pixels translates to 260 x 260 pixels, which under the Po2 rule will see the asset allocated a 512 x 512 pixel chunk of memory (just like the 390px source), whereas reducing it to 384 x 384 pixels will translate to 256 x 256 pixels, which uses just 25% of the memory of 512 x 512 pixels.
Anyhow, just something to bear in mind if your game has dozens of aliens flying around the place.
From what I can tell (and I'm opened to being corrected, as all this stuff is new to all of us) there is little point in 2/3rds assets being created at all, in the overwhelming majority of scenarios we would just be creating a second set of images that would occupy the same amount of RAM and place the same strain on the processor as the master source (3x) images - but with the added bonus of using up a little more of the user's HD/SS/Flash storage for the additional asset set, the only real argument to be had is whether the GS servers do a better job at resizing than Open GL.
Don't thank me ! I'm not the poor soul who has to make all these clashing numbers play nicely together !
Okay... the publishing update has been pushed to match this system! Sometime later tonight I'm going to update the OP to match what was finally decided. I was also able to get the Legacy Resolution Independence checkbox in! So if you can't upgrade your game to 3x art, you have an option aside from turing off RI.
Great stuff !
@Sock the big argument for the 2/3 sized images is loading time. A 2048x2048 image would be cut down to a 1365x1365 image, which comes out to about 44% of the file size. This is an extreme example, but it's a good one to note. Since each game is different, I'd say test your game with Retina On and Off and see whether loading time is worth odd image scaling.
I see, yes that makes perfect sense, I'd not even thought about load times !
Yep, testing is the way forward I think, but I reckon you've pretty much nailed everything, even iOS7's inability to load 3x assets is addressed by the iPad 2x 1x route.
Great stuff, a good outcome from Apple's untidy maths.
@Socks and @adent42 Thanks for working so hard at sorting this out, particularly with suggestions an ideas flying all over the place.
What about pixel art, that need to use nearest neighbour as the resize method, wont they be ruined as they'll most likely be anti aliased in the process?