I just finished developing a 2D side scroll game for the IPad using Cocos2d and Box2d. Now we want to make an IPhone 4 version of the game, but I'm still not sure what is the best way to do it.

I was thinking to just create a new target on my project, remove all the current resources from the Build Phases and create a new Resources folder with all the assets of the game scaled to the new resolution.

Of course this approach would take a lot of work, specially from the designer, since there are a lot of images on the game, 30 levels with 3 layers of parallax, and over 100 animations between all the elements, plus the SVG levels that map physics world (we are using level SVG parser).

I would also have to check all the touch functions and the sprites with a hard coded position (mostly Hud and the Menu). I did tried to use the win Size for this, but I'm pretty sure there are sprites with fixed positions.

I know that checking the Menu and Hud position should not take much time, but I'm worried about the time it could take to scale all the images, and specially the SVG files that map the physics of the game.

I would like to know if I'm in the right path regarding the porting of the game or if there if someone have though of a better easy solution.

I tried modifying the gluLookAt eye z parameter, but this didn't work really well. I haven't work with OpenGL since college around 3 years ago, and I don't remember very well the math behind the low level pipeline of it. Anyway, I don't think that modifying the Cocos2d rendering steps could work for my problem.


closed as off-topic by MichaelHouse Nov 8 '13 at 15:27

This question appears to be off-topic. The users who voted to close gave this specific reason:

  • "Questions about "how to get started" or "what should I learn next" cannot reasonably be answered with anything other than opinion polling and therefore are off topic for the site. For more information on how to ask a better question, see the help center" – MichaelHouse
If this question can be reworded to fit the rules in the help center, please edit the question.

  • \$\begingroup\$ By iPhone 4, do you mean iPhone with iOS 4 or the actual iPhone 4 device? Because if it's the latter, the retina display has almost the same resolution as the iPad (960x640 vs. 1024x768). So there's not much converting to do.. maybe limiting the viewport a bit will do... \$\endgroup\$ – bummzack Oct 24 '11 at 21:20
  • \$\begingroup\$ It's IPhone 4, and thanks for the comment, I found out I didn't had retina display support enabled on cocos2d ([director enableRetinaDisplay:YES]). \$\endgroup\$ – David Martinez Oct 25 '11 at 17:41

That sounds like a solid path you are taking.

You will most likely need to scale down your textures (unless they aren't already high res) and change the hard coded positions. When I am creating an iPad game (with the intention of porting to iPhone) I create two copies of each texture and any hard coded position I create as constants to make them more manageable.

Depending on the game, you may have to reduce the draw calls or limit the amount of sprites/textures on screen.

Also don't forget about text, sure you can try to scale everything down by half. But your text may look blurry or too small.

  • \$\begingroup\$ Thanks for the answer. Yea I should have created some constants for position and stuff. Well now I know better for my next game :) \$\endgroup\$ – David Martinez Oct 25 '11 at 17:45

The way you are trying to port your game is the standard format. but I think you can easily try scaling all your game to 1/2 when your game starts. Something like glpushmatrix(MATRIX_IDENTITY / 2). but even using this method you have to convert touch positions manually and you also might run out of memory due to high resolution textures.


You also need to be aware of the device's memory. An iPad is more powerful than, say a 3DS, which in turn is less powerful and an iPhone4.

You really need to focus on which iphone you are going to develop for as well. As I think most aps aim for 3GS and that allows you to play on 4 and above with no problems.

  • \$\begingroup\$ We are only porting for IPhone 4 so memory and Cpu are not an issue. \$\endgroup\$ – David Martinez Oct 24 '11 at 19:20
  • 1
    \$\begingroup\$ CPU is always a problem :) \$\endgroup\$ – Sean O'Brien Oct 24 '11 at 20:10

I mentioned in my comment to the question, that your assets need little to no modifications, since the iPhone 4 (960 x 640 px) has almost the same resolution as the iPad (1024 x 768 px). If a slightly smaller viewport doesn't have a negative impact on your game, then you can basically leave your assets as they are.

In cocos2d, high-res assets (for retina display) use the -hd suffix, as opposed to the @2x suffix introduced by apple. So you might want to add a -hd suffix to your existing assets and create scaled down versions without the suffix if you plan to support iPhone 3GS and older.

More importantly though:, the native unit for coordinates on iPhone and iPad is not pixels but points. The screen of an iPhone has 480 x 320 points (if it's a retina display, one point contains 4 pixels). The screen of the iPad has 1024 x 768 points. So while your assets probably don't need scaling, your coordinates are vastly different.

You might be tempted to simply scale all your stuff down, but in case of physics, this could result in quite different results (differing object mass, etc.). You should not change your physics-world at all, only perform the scaling on the view (eg. multiply coordinates with another factor (PTM_RATIO) than used on the iPad).

If you didn't use any easy modifiable constants to convert from physics-units to device-units, then you'll probably have a lot of work ahead of you now :)

Here's an interesting post about creating an universal app (iPad, iPhone 3, iPhone 4). It might help you tackle some of your problems.

  • \$\begingroup\$ Thanks for the answer. Cocos2d does give support for the use of native unit in point and pixels, SetPosition use the point coordinates while SetPositionByPixel use the pixel coordinates. I used a PTM_RATIO but I don't think I have to change it. Anyway, this is all in theory, I should start testing the IPhone deployment today at the afternoon, so by tomorrow I should have a lot of questions :P \$\endgroup\$ – David Martinez Oct 26 '11 at 17:17

Not the answer you're looking for? Browse other questions tagged or ask your own question.