A fast, easy to use, free, and community supported 2D game engine
@MattRix @jptesung: Thanks. Yes, it will be fixed in the next release.
Probably I'll add a new method on the director:
[director setContentScaleFactor:2]; // I will deprecate this method
BOOL success = [director enableRetinaDisplay]; // This method will be the official one to use.
if ( success ) {
// it means that it was able to set the iPhone4 in Retina Display.
// it will fail if it is called on the rest of the devices like iPad, iPhone3GS, etc...
}@jptsetung: I'll add a "enableRetinaDisplay" method. That method will do exactly that. It will set the iPhone4 in RetinaDisplay mode. It means that it will 1 Point == 4 Pixels (2x2 pixels).
The iPad doesn't support RetinaDisplay mode. The iPad, at least in iPad mode, 1 Point == 1 Pixel.
If I'm missing something, please let me know.
PS: If in the future the iPad supports a sort of RetinaDisplay mode, that method will support it too.
PS2: As the cocos2d RetinaDisplay guide says, you'll be able to load "-ipad" resources in the near future.
Hey Riq, what jptsetung is talking about is the iPad's "iphone emulator" mode for non-universal apps(the one with 1x and 2x zoom). In the 2x zoom mode it's basically identical to the Retina display, there are 960x640 pixels, and the UIScreen's scale is 2. Because it's possible for the user to switch from 1x to 2x zoom while it's running, it's best just to treat it as if it's always in 2x mode. It really makes games and apps look *way* better on the iPad, and code-wise, it acts almost identically to the Retina display, with just a couple minor tweaks to account for the fact that the scale could be 1 or 2 at the start.
@Matt-Rix: Ahh... Ok... I understand. I'll try to support that in the next release.
I agree - on iPad you want highres but we should also consider the memory situation... iPhone4 has much more memory.
Perhaps we somebody wants some kind of mixed mode: E.g. using scaled lowres textures for the background and high res for the foreground.
Or load RGBA4444 for the background images where as we can use RGBA8888 on iPhone4?
I think with the current API this should already be possible...
Yes. Thats currently what I hate about the iPhone-Development - but what would be worse on other platforms (e.g. Android)
With only iPhone classic + iPhone 3G things were easy.
I now own 4 iPhones and one iPad. They all got different ios versions, memory and speed and resolution... and I don't wanna start buying iPods too.
This is why getting resolution independent is so important. I think cocos should develop in a direction where hardware and OS abstraction is done as much as possible. The less you have to think about the hardware the more you can focus on development.
Blue Ether
Member
How exactly does Cocos handle the HD scaling for Zwoptex sprite sheets? When we adapted one of our games, we found that the values from the -hd.plist were being doubled again by Cocos. So, if the SD version was 32 wide, and the -hd version was 64 wide, then the resulting sprite was 128 wide. We're using Beta 3, but we don't use Sprite Frame because the project pre-dates their existence. It uses a homemade getRectForSprite method. It seems as though Cocos expects that the SD plist is being used for the HD sprite sheet, and is trying to compensate, when in fact the plist is explicitly for the HD version.
Our quick fix was to divide all the values in half for the HD sheet, but this doesn't seem to be ideal.
@Blue Ether: I think that this guide explains how the zwoptex .plist works:
http://www.cocos2d-iphone.org/wiki/doku.php/prog_guide:how_to_develop_retinadisplay_games_in_cocos2d
If it is not clear, please let us know what part is not clear so we can improve it.
eshirt
Member
@Blue Ether - I posted a bit about my experience using Zwoptex files and -hd on this post: http://www.cocos2d-iphone.org/forum/topic/10146
Reading you post, it's possible that you're -hd Sprites were named "XXX-hd.png" when you made the sprite sheet. I think this could result in CCDirector reading the -hd .plist, then when it sees the -hd sprite name, it tries to scale it up again. I may be wrong, though - I'm not sure if the Director will automatically scale your sprites when it finds the -hd suffix.
Like @riq said, it's pretty clear already, but when I first read the wiki, it took a few minutes to realize exactly why the -hd sprites shouldn't use the -hd suffix. If someone wants to take my wordy instructions from my post and edit them down to something more suited for the wiki, be my guest :)
Blue Ether
Member
No, the -hd sprites in the sprite sheet have the same names as the sd sprites.
So, as an example, we have:
in spriteSheet.plist:
-mySprite.png (32x32 @ 16,16)
in spriteSheet-hd.plist:
-mySprite.png (64x64 @ 48,8)
So, there are two plists, containing images with the same identifiers. When in HD mode, the texture rect for mySprite.png ends up being 128,128 @ 96,16. The sprite is created using "spriteWithSpriteBatchNode:rect:", and we can verify that the Rect being passes has the correct values (i.e. the values from the correct entry in the HD plist), but somewhere along the line after this point, the values are all doubled.
You must log in to post.
