Sign in to follow this  
jwezorek

screen resolution issues across various Apple devices

Recommended Posts

Briefly, what will happen if I write my game to an iPad2 (1024x768 pixels) and then run it on an iPad3 (2048x 1536) without me doing anything? What do old pre-ipad3 games do if you run them on an iPad3? Should I include logic for scaling up or letter/pillar-boxing or will this be taken care of by magic?

Share this post


Link to post
Share on other sites

First it depends on the language you are using for your game. If you use Apple's IDE (Xcode) and Objective-C language with your game engine development then you will not need to any math for image sizes, devices will take care of it (even iPhones). You'll need to provide high-res images in your project for high resolution devices, devices will automatically choose best images for the application. 

 

But if you use OpenGL + C++ language for your game probably you'll need to calculate scaling depending on the device.

Share this post


Link to post
Share on other sites
But if you use OpenGL + C++ language for your game probably you'll need to calculate scaling depending on the device.

 

Or just set up an appropriate matrix with the resolution you want to handle (and the GPU will take care of everything else).

Edited by Sik_the_hedgehog

Share this post


Link to post
Share on other sites

My game is on top of cocos2d-x, which means basically C++/OpenGL ES.

 

However, when I emulate ipad3 resolution in the simulator, my game is scaled up by magic. Is this what will happen on an actual device? because I'm fine with this behavior for now. Ultimately I'd like to re-render my artwork to the higher resolution but I think I could release like this, if this is the real behavior.

Share this post


Link to post
Share on other sites

@sik_the_hedgehog: Yes, you are correct.

 

@jwezorek: Your project probably compiled in Xcode and this means that your Resource files are in your Xcode project, not in Cocos2d-x library resource. This kind of solution gives enough information to the device about your images. So, it'll work like native Xcode project and device will be able to select best image.

 

You simply need to provide HD images (with @2x at the end of the name, for example put player@2x.png for player.png image) but always use normal file names. More info: http://stackoverflow.com/questions/9650530/ipad-retina-display-suffix

 

Also don't trust the simulator appearance, try to see the results on real device. It may seems OK on simulator but on a actual device results may be worse because of the retina display.

Share this post


Link to post
Share on other sites
Still confused.

...if I follow these image file naming conventions files will get loaded conditionally based on whether or not the ipad has a retina display, fine, but not seeing how this helps me unless the screen coordinate system is somehow being taken care of too e.g. if I position something on the screen at (50,100) it actually gets positioned at (100,200) on a retina display. Is this what happens? Edited by jwezorek

Share this post


Link to post
Share on other sites

@2x image variants and viewport scaling are completely different things.

 

In terms of scaling, It's quite trivial to retrieve device information for pixel density, screen size, etc. I'd imagine somewhere in the cocos2d-x framework there are checks for all of those specifics that drive the initial set up at run time.

 

(50,100) should always be (50,100) in your game logic. Anything else is a terrible way to work IMO. The "auto" scaling you're seeing should be nothing more than varying values in the GL viewport being created by cocos2d-x according to varying hardware.

 

I rolled my own game/rendering engine and had to set all of this rendering logic up, most middleware should just be ready to roll. I have unified coordinate logic between SD/HD devices and also coordinate conformity between iPhone and iPad - so multiple factors across three scales (iPhone SD, iPhone HD/iPad SD, iPad HD) bringing every (50,100) into the same relative screen location.

 

Would be very surprised if cocos was any different by design. Or if it couldn't at least be made to behave that way easily via some setup flags.

Share this post


Link to post
Share on other sites
Would be very surprised if cocos was any different by design. Or if it couldn't at least be made to behave that way easily via some setup flags.

Yeah, I think what you describe must be what cocos2d-x is doing by default (changing the relevant GL viewport properties based on the resolution of the hardware)

My only question now is what about sprite sheets? If I provide two versions of a sprite sheet image, sprite_sheet.png and sprite_sheet@2x.png do I have to provide two versions of the .plist file? Edited by jwezorek

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this