screen resolution issues across various Apple devices

Started by
6 comments, last by jwezorek 11 years, 3 months ago
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?
Advertisement

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.

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).

Don't pay much attention to "the hedgehog" in my nick, it's just because "Sik" was already taken =/ By the way, Sik is pronounced like seek, not like sick.

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.

@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.

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?

@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.

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?

This topic is closed to new replies.

Advertisement