Instead of adjusting the resolution, I recommend writing a self resize/repositioning algorithm.
What I do is have my artists design all the sprites for a 640x960 wireframe, then when the game loads on any device, I get the raw size of the screen in pixels, calculate the best fit ratio, and resize/position all objects based on that ratio. Not a plug go look at “Qach” in the app store and android market (its free), and load it up on an iPhone 3gs, iPhone 4, iPad, and/or android device and you will see it properly size and align on any screen it is placed on. That is ALL the same code path, and generated on the fly at load time. You may get a minor amount of “drift” based on changing aspect ratios, but I use an “align for” declaration that tells my algorithm if it should use the height, width, or “best fit” ratio when it places and scales the object. This is also a good method going forward since we have no confirmation what resolution the iPhone 5 / ipad 3 will have…
“wireframeDimensions” is the original layout size of your assets. We generally design everything around a 960x640 wireframe. Thus all assets are scaled to 1 when on a 960x640.
Scale your sprites with the return value of getScaleRelativeToDesignWireframe, and position them with the return value of getPointRelativeToDesignWireframe. The point value you pass to getPointRelativeToDesignWireframe will be the original position based on the 960x640 wireframe (or whatever wireframe you chose).
I enable retina, but I do NOT use the hd extension for my sprites. All of my sprites are based on 960x640, thus when you get the scale using getScaleRelativeToDesignWireframe on a 480x320 device, it will actually return 0.5, if you usehd extensions, it will probably return the wrong size values because cocos2d does an internal conversion on load. Recap - enable retina, using sprites that would have a 1x1 ratio on 960x640 (or whatever you design wireframe is), DONT use -hd extension.
Using “RELATIVE_TO_BEST” will make sure that all of the assets will fully make it on to the screen, although asset drift will be more prevalent.
Ok, so there is a “bug”, but its not one that needs to be fixed per say… Let me explain.
Currently the line:
if(scaleRatio == heightRatio)
is used to test if we need to default to stepping our calculated point in the x or y directions. This will work fine for any device that returns either equal values of PTs and Pixels, or equal ratios of Pts and Pixels. Example, “Pts = 320x480 Pxs = 320x480 is OK” & “Pts = 320x480 Pxs = 640x960 is OK”. However “Pts = 320x480 Pxs = 360x920 would NOT be ok”. This is because the ratio of pts/px width is not equal to the ratio of pts/px height. So:
if(scaleRatio == heightRatio)
would always return false. Now the only time this could possible happen would be if a device was released that had some seriously confused points/pixel ratios, and since iPhone is the only one that I am aware of that even uses the Pts part of this equation, then I dont feel that is something most people need to worry about. However I will take the time to fix it soon, and post a more bullet proof version.
The algorithm is designed to find the location of the incoming point based on either the Width or Height ratios, not both. That is by design, since we “want” the point drift to make sure what we are displaying always ends up on screen no matter what the resolution. Thus finding a “center point” which relies on both width and height ratios working together wont work. Unless you simply call the function twice, once with a point holding your X value with a relativeTo value of Width, and once with a point holding your Y value with a relativeTO value of Height. By using the X value of the first, and the Y value of the second you will have generated a point that is scaled and stepped by both ratios. I do this as well when I need to have such things as screen center points, or things aligned to edges without drift, or when aligning to the edges of other sprites. For example, this should return the center of any screen if you are using a design wireframe of 640x960
Santosh: Yes, the artists based all of the images off of 960x640 and only one set were used. The algorithm was designed to scale and position a sprite based on drift.
If you want to port an existing cocos2d-iphone game to Android you definitely want to consider Apportable which lets you cross-compile your Objectve-C code to Android platform.