[devel] Creating Hi-Res/Low-Res App in Cocos2D v0.99.4 and v0.99.5

cocos2d for iPhone » Programming » cocos2d internals

[devel] Creating Hi-Res/Low-Res App in Cocos2D v0.99.4 and v0.99.5

(194 posts) (42 voices)

Started 1 year ago by ishadow
Latest reply from luky300

Tags:

12…7 Next »

ishadow
Member
Hi
I would like to share with you solution that I came up with, to actually have a Hi-res App that is also working smoothly on iPhone 3G in lower resolution. It's rather tutorial for beginners.

Standard screen dimension iPhone has is 320x480 (480x320 landscape). New iPhone 4 has 640x960 (960x640).
To turn on Hi-Res graphics in Cocos2D you have to add following line in AppDelegate
```
[director setContentScaleFactor:2];
```
This actually change screen dimension to hi-res, and is also working on older devices simply scaling down the graphics. It would be ok, but performance loss is just unacceptable on iPhone 3G. In my application I got only 15-20 fps for just drawing 480 x 320 background and 2 buttons.

All you have to do, to actually use new hi-res retina display and also retain good performance on older devices is to do few things:
1. Set director in right mode(AppDelegate):

//set "float _scale" global variable using singleton, or some other way
```
if([[UIScreen mainScreen] respondsToSelector:NSSelectorFromString(@"scale")])
	{

		if ([[UIScreen mainScreen] scale] < 1.1){
			NSLog(@"Standard Resolution Device"]);
			[director setContentScaleFactor:1];
                        _scale=1;

		}

		if ([[UIScreen mainScreen] scale] > 1.9){
			NSLog(@"High Resolution Device:");
			[director setContentScaleFactor:2];
                        _scale=2;
		}
	} else{
         //this means we run on iOS<4.0 and only low-res is valid
         _scale = 1;
        }

Now depending on device you have screen 320x480 (480x320) or 640x960 (960x480). To unify code scale width and height:
		_size = [[CCDirector sharedDirector] winSize];
		_size = CGSizeMake(_size.width/_scale, _size.height/_scale);
```
Now _size should return 320x480 (480x320) and we should work with these dimensions. All we have to do now is to scale every object we draw on screen and multiply position with _scale. Let's draw a sprite on position (55,103) for example:
```
CGpoint position = CGPointMake(55,103);
CCSprite *sprite = [CCSprite spriteWithFile:@"sprite.png"];
sprite.position = (55*_scale,103*_scale);
sprite.scale = _scale/2;            //sprite should be prepared for hi-res
[self addChild: sprite z:10];
```
Using this method we should have displayed hires sprite on retina display and low res on older phones. This work 2-3 times faster than just inserting [director setContentScaleFactor:2] in AppDelegate.
More speed could be achieved if we had graphics in lowres and hires version and use proper one instead of scaling hires object.

Hope this helps:)
PS. This is actually a wrap up from other threads on this forum.
Posted 1 year ago #
asinesio
Member

So, you're using the same assets for iPhone 4 and iPhone 3G? Do you notice any issues with quality on the 3G?

Also, it seems like you could encapsulate this logic by overridding CCSprite's setPosition/setScale methods with your own subclass, e.g. "CCScaleAwareSprite". Then you don't need to copy/paste the same lines of code each time you add a sprite.

Thoughts?

Posted 1 year ago #
ishadow
Member
Assets are scaled down just fine on 3G. There are of course performance issues when your using bigger images, but it's still possible to maintain 45-60 fps with png background + 2 TMXLayers(32x32 tile) on screen.

Creating own subclass is not always the good way in this case. You have to setPosition/setScale to every object that is displayed: CClayer, CCSprite, CCMenuItem, CCTMXTiledMap etc.
You can also add one more method in your Scene:
```
-(void) MakeScaleAware: (CCNode *) node{
  node.position = ccp(node.position.x *_scale,node.position.y*_scale);
  node.scale = _scale;
}
```
There are many ways to write it nice and clean, but my point was just to tell you how you can do that.
Posted 1 year ago #
JonKean
Member
I think the ideal solution, is for Cocos to represent screen coordinates in two different ways. As 'points', that are agnostic to the device screen scale (same way Apple UIKit components work, where retina display has same point resolution as older devices). And as 'pixels', where it's actual discrete pixels you're working with (Retina screen pixel resolution would be 2x older devices).

For my projects I'm using a hack to accomplish this, with two macros that convert between screen->pixel and pixel->screen. On an older device both macros effectively do nothing, but on Retina display they scale up or down as needed. Then I use whichever coordinate system is appropriate for each situation.
```
static CGFloat scale = 1;
<p>void initScreenScale() { // called once before anything else
    UIScreen *mainScreen = [UIScreen mainScreen];
    if ([mainScreen respondsToSelector:@selector(scale)]) {
        scale = mainScreen.scale;
        CCLOG(@"screen scale: %1.0f", scale);
    }
};
inline CGFloat getScreenScale() {
    return scale;
}
inline CGPoint pixelToPointCord(CGPoint pixel) {
    return ccp(pixel.x / getScreenScale(), pixel.y / getScreenScale());
}
inline CGPoint pointToPixelCord(CGPoint point) {
	return ccpMult(point, getScreenScale());
}
```
Posted 1 year ago #
roli
Member

It seems that there are many different solutions to the same problem. I am still trying to decide if I even want to add hi-res support in my new game. I was actualy thinking about using the old low res mode until all low res iOS devices are gone from the market. Then wait another year or so and simply stop supporting the low-res devices completly.

For now I would realy like to have a way to display hi-res content on the retina display and use the low-res content on the other devices but use the same logic for both. So I can use the old logic on both screens. Any ideas on how that could be possible? Because I am in the middle of my game right now and I realy don't want to change everything just to support a few hi-res devices.

Posted 1 year ago #
Matt Rix
Member
Hey guys, so I basically figured out how to do this over the last couple hours... Took a lot of plinking around, but the actual solution doesn't require that many changes. I might write a blog post about it tomorrow. Basically it lets you use your old low res graphics, code, coordinates and all that, but it can also pull graphics from high res images so that they're nice and crisp - and keeping the coordinates low-res. You can even use @2x images to do it so it's pretty seamless. It works basically like Apple's point system. I'm doing this in 0.99.5 alpha, so I don't know how different it would be for other versions.

I've only tried it with Projection2D, I imagine it will work with Projection3D as well. The steps are kinda confusing, and they involve changing the director in a couple places.

Firstly, you have to make sure you set the contentScaleFactor BEFORE you set the director's openGLView, but makes sure you set the projection AFTER you set the director's openGLView(there's currently a bug where the projection gets reset to the 3D default when you set the openGLView).

In CCDirector you scale the projection by the contentScaleFactor using glScalef in setProjection. It looks like this:
```
case kCCDirectorProjection2D:
			glViewport(0, 0, size.width, size.height);
			glMatrixMode(GL_PROJECTION);
			glLoadIdentity();
			glOrthof(0, size.width, 0, size.height, -1024, 1024);
			if( contentScaleFactor_ != 1 && isContentScaleSupported_ )
				glScalef(contentScaleFactor_, contentScaleFactor_, 1);

			glMatrixMode(GL_MODELVIEW);
			glLoadIdentity();
			break;
```
In CCDirector's convertToGL there are a couple lines that scale the coordinates by the contentScaleFactor, I had to comment those out, because we aren't actually using 2x coordinates anymore, just 2x assets.
```
//if( contentScaleFactor_ != 1 && isContentScaleSupported_ )
//	ret = ccpMult(ret, contentScaleFactor_);
return ret;
```
In CCSprite's setTextureRect, I have this:
```
if([[CCDirector sharedDirector] contentScaleFactor] != 1)
{
	CGRect doubleRect = CGRectMake(rect.origin.x*2,rect.origin.y*2,rect.size.width*2,rect.size.height*2);
	[self updateTextureCoords:doubleRect];
}
else
{
	[self updateTextureCoords:rect];
}
```
What this does is it basically doubles all your texture coordinates(assuming you're using an @2x high res texture atlas at this point).

I know the above explanation is super confusing, but I think it'll give some people ideas for how to go about this. Hopefully we can figure out how to streamline this and include it in Cocos at some point, because I'm sure a lot of people would like to do this.
Posted 1 year ago #
jptsetung
Member

Matt's approach is the best to keep great performances on the 3G. I also wish this will be added to Cocos.

Posted 1 year ago #
Matt Rix
Member

Yeah I'm still trying to work out the best way to implement it cleanly. If you set the contentScaleFactor to 2 on the iPad, you can also get your retina graphics on the iPad(without having to make it a universal version or anything like that). It works surprisingly well. The beauty of this technique is the fact that you get to use high res textures, but basically nothing else has to change. My BitmapFontAtlases aren't working yet, but I haven't really looked into that. I don't think it'll be hard to make them work either.

Posted 1 year ago #
Matt Rix
Member
Ok, a couple more notes.

First of all, if you have blurry textures, make sure you're not using 0.99.5 alpha, and instead, you should use the develop branch. The artifact fixing technique gives blurry textures. This took me a while to figure out :)

Secondly, one more little change needed to be made so that transitions work. Because of the fact that we want all our coordinates to remain 320x480, you have to put these lines at the bottom of the winSize getter in CCDirector:
```
if(contentScaleFactor_ != 1)
{
	s = CGSizeMake(s.width/contentScaleFactor_, s.height/contentScaleFactor_);
}
return s;
```
Posted 1 year ago #
Dragyn
Member

Matt -

I think I'm following your code, at least in theory. I would love to see a more fleshed out blog post, like you mentioned possibly writing, perhaps with sample implementation/use code using both low res and hi res graphics. I know we've had a lot of threads on different aspects of retina display support, but it would be nice to see your (apparently) simple approach fully fleshed out as a one-stop-shopping tutorial post.

If it could eventually be merged into cocos itself, all the better!

Posted 1 year ago #
Matt Rix
Member

Hey Dragyn, yeah I'd like to write a post about it. I'm still in the process of creating all the retina graphics and such for Trainyard, and doing some other tweaks, which is why I haven't written it yet. I'll be spending the rest of the day on all these little things I've gotta do, so a blog post probably won't come till tomorrow. I think I might make an actual sample project that anyone can use, just so everyone can see how it works.

I think once Riq takes a look at the idea, he'll be able to figure out the best way to implement it in a way that doesn't adversely affect any other parts of the framework.

Posted 1 year ago #
yar00n
Member

Matt

Your method seems very nice indeed. I would like to see the blog/example code you're suggesting. I'm already half way with my game so I'd like to see the concept in action before I start refactoring.

In any case: thanks for your efforts! If your methods does indeed function as described then it's definitely the easiest solution I can imagine.

Posted 1 year ago #
kimle78
Member

Hello Matt, I couldn't get your solution quite working. I'm using the cocos2d-iphone HelloWorld template app. v0.99.5-beta. My background image sprite gets drawn, but it's not in the correct position.

Few questions:
1. I see that the default projection is 3D. Do I need to set that to 2D in the AppDelegate?

2. How do I tell cocos2d to load my hi-res vs non-hi-res image? Do I need to include the code snippets from the beginning of this thread?

3. Just clarification, I should be calling [director setContentScaleFactor:2] in the AppDelegate, right?

If you can post a simple project that would be quite helpful!

Posted 1 year ago #
Matt Rix
Member
Yeah sorry I haven't posted an update yet. I had a couple more issues to work through and I've been busy with other work stuff.

If you're using sprites in an atlas, the code I posted for CCSprite's setTextureRect should work. If you're using CCSprite's initWithFile or spriteWithFile, you'll need to put this in CCSprite's initWithFile instead of rect.size = texture.contentSize;
```
if([[CCDirector sharedDirector] contentScaleFactor] != 1)
{
	rect.size = CGSizeMake(texture.contentSize.width/2,texture.contentSize.height/2);
}
else
{
	rect.size = texture.contentSize;
}
```
Posted 1 year ago #
Matt Rix
Member

Also, I should note I'm currently working to make this work for iPad as well. It's almost there, but I discovered that the iPad app acts slightly differently depending on whether it starts in 1x scale or 2x scale. That's the last part I have to work out to make it fully work properly.

Because I'm supporting iPad and iPhone(note that it's not actually a universal app, but just high res on iPad), I'm checking if either the UIScreen's scale is 2, OR if the app is an iPad app in the AppDelegate, if it is, then I set the contentScaleFactor to 2.

What I'm doing is I actually set a simple global BOOL called isHD to true if it's HD(iPad or iPhone 4) or to false if it's any other device.

I then have a macro called GetPNGFile(@"someImageName") that will either load someImageName.png or someImageNameHD.png - this way I don't have to rely on @2x images, which don't get loaded on the iPad.

I set my projection to 2D, I think it's probably possible to make it work with 3D projection, but I haven't tried it. Make sure you set your projection AFTER you set the glview.

Posted 1 year ago #
Dragyn
Member

Matt - I'm a little confused by your comments about the iPad. When you say it'll use Hi Res on an iPad, but NOT be a universal app, how does that work? Does that mean the app, when loaded on an iPad, will still be at the iPhone-size window (with the 2x trigger in the corner), but the graphics will be the same high res as the retina display within that mini-screen? Or at 1x does it use the standard res iPhone images, and at 2x uses the High Res images?

(We all appreciate your level of expertise and deep digging on this issue. I haven't tackled retina or iPad yet, mostly because of the conflicting info regarding how to handle via the SDK, and how to handle via cocos. Thanks for all your help thus far!)

Posted 1 year ago #

Joethemonkey101
On probation

Here's the errorless code, put all together.

[[CCDirector sharedDirector] setContentScaleFactor:2];

	float _scale;

	if([[UIScreen mainScreen] respondsToSelector:NSSelectorFromString(@"scale")])
	{

		if ([[UIScreen mainScreen] scale] < 1.1){
			NSLog(@"Standard Resolution Device");
			[[CCDirector sharedDirector] setContentScaleFactor:1];
			_scale=1;

		}

		if ([[UIScreen mainScreen] scale] > 1.9){
			NSLog(@"High Resolution Device");
			[[CCDirector sharedDirector] setContentScaleFactor:2];
			_scale=2;
		}
	} else{
		_scale = 1;
	}

	CGSize _size = [[CCDirector sharedDirector] winSize];
	_size = CGSizeMake(_size.width/_scale, _size.height/_scale);

Posted 1 year ago #

Matt Rix
Member

Dragyn:

The iPad version doesn't switch between graphics, it always uses the Retina sized graphics, so when you choose 2x zoom, it's nice and crisp(not blurry), and at 1x zoom, it still looks nice(because all the 2x graphics are exactly half-sized). It really didn't feel right calling Trainyard universal without actually making a proper iPad version, but I think this is a great compromise; the game won't be listed as universal, but any user that does try it on an iPad will be pleasantly surprised with the sharp graphics.

Posted 1 year ago #
itlgames
Moderator

HI, I'm too investigating the hi-res/low-res, but @ishadow one thing I noticed on your code, you have this comment:

//this means we run on iOS<4.0 and only low-res is valid

But please correct me if I'm wrong, the iOS4 has nothing to do with hi-resolution, it's the iPhone 4 and iPad, right? I mean, I can run iOS4 on my iPhone 3G or my iPod Touch 2G.

Posted 1 year ago #
Dragyn
Member

Actually, that code comment is mostly accurate with the structure of ishadow's code. Since the code is looking for the ability to use "scale", which was released with iOS4, then if you can't find "scale", you're running on older version of iOS. The if...then...else block of code looks for scaling ability, and how much it can scale (hi-res or lo-res), and the else (where the comment is) is only reached if it doesn't understand the question of "scale".

Since the retina display is only on the iPhone 4 (which ships with iOS4), you can assume you don't have hi-res mode on a lower OS. That being said, I'm not 100% sure about "scale" on iOS 3.2 (the iPad OS). So it might be more accurate to say it is 3.1.3 or prior if it reaches that point in the code.

Posted 1 year ago #
Andreas Loew
Member

In my upcoming game I do it this way: I got all the sprites in highres and create a highres and lowres sprite sheet using TexturePacker. So I get sheet1-sd.png + sheet1-hd.png.

Before loading I detect if it's a high res device or not.
I have one main layer which is parent of all the sprite sheets and other content.

For highres:
* Load -hd version of the sheet
* Set scaling of main layer to 1
* Set sprite scaling to 1

For lowres:
* Load the -sd version of the sheet
* Set scaling of main layer to 0.5
* Set sprite scaling to 2

This results into having the same pixel sizes: 960x640 for all devices.
The only thing you have to be aware of is that if you add a sprite as child of another sprite you have to set the scaling to 1 otherwise it gets too big since scaling factors multiply.

Posted 1 year ago #
itlgames
Moderator

Wouldn't be more reliable to check the screen size? if we detect something bigger than 480x320 then we now we are on a hi-res device then we can apply any scale logic.

Posted 1 year ago #

Andreas Loew
Member

I use this code to determin hd / sd:

UIScreen* mainscr = [UIScreen mainScreen];

    CGSize screenSize = CGSizeMake(320, 400);
    if([mainscr respondsToSelector:@selector(currentMode)])
    {
        screenSize = mainscr.currentMode.size;
    }

    BOOL isHD = NO;
    switch ((int)screenSize.width)
    {
        case 640:
            // iphone4
        case 768:
            // ipad
            isHD = YES;
            break;
        default:
            // old stuff ;-)
            isHD = NO;
            break;
    }

Posted 1 year ago #

Matt Rix
Member

If you check width you'll run into problems if they do something like release an HD iPad, just check the UIScreen's scale and see if it's 1 or 2, easy.

To check if you're on iPad, check if the device name contains "iPad".

Andreas, the way you're doing your scaling is basically the inverse of my way. I'd recommend doing it so that you're working in 320x480 values, because that's the same way Apple's UIKit stuff works. To me, it doesn't really make sense to ever work in 640x960 directly.

Also, I know it's taken me FOREVER to get this blog post done. I think I'm gonna finish it up tomorrow night in time for my iDevBlogADay post on Tuesday.

Posted 1 year ago #
jptsetung
Member

@Matt, Great news.
@Andreas, I think that your way is also taking a lot of memory on old devices as you work with 960x640 images.

Posted 1 year ago #
Andreas Loew
Member

@jptsetung: No. I use low res images on old devices and high res images on new devices. I work in a pixel space of 960x640 but the device renders only 480x320 since the main layer scales everything down before rendering... Cocos does not render each frame - it sums up all transformation matrices and then draws the elements.

@MattRix:

Right - asking the resolution is better. And perhaps the default case should be high res and not low res since future devices will be high res.

But: Calculating in highres is better since you get better accuracy. You can place elements pixel perfect in the high res space and the scaling down to lowres will find a fitting position. E.g. if you got boxes which should be directly aligned. You can round the pixel for a perfect fit.

If you scale up from lowres and do the rounding in the layer before scaling you'll end up by placing objects only at every second pixel. So it is better do calculate in highres and scale down.

The operations do not consume more memory nor time since there is no painting action in highres. As I already mentiond in the response to jptsetung cocos applies the matrices and then starts painting using the opengl.

Posted 1 year ago #
slipster216
Moderator

The route I'm taking is to work in the highest resolution and scale down. And since the iPad and iPhone have different aspect ratios, you have to account for the extra space either by adjusting your layout or having widescreen bars on the iPad version. To avoid layout issues, I'm doing the later. So in essence, all my images are sized for a 1024x683 screen, which scales to 960x640 on iPhone4, and 480x320 on the earlier iPhones. What's nice about this is that I work in a single coordinate space and only have to set the content scale to width/480 to get the correct results.

Posted 1 year ago #
sabshire
Member

I'll be interested in seeing this in a blog post that ties everything together as it is a bit confusing tying everything together from all these pieces and interspersed comments.

Posted 1 year ago #
itlgames
Moderator

@slipster216, wouldn't that affect badly to pre iPhone 4? As you are loading bigger textures when don't really need it. I would keep in mind previous devices as there are still lot of people with iPhone 3G and iPod Touch.

Posted 1 year ago #
slipster216
Moderator

I'm going to load a low res version of my texture sheets on the older iPhones.

Posted 1 year ago #

RSS feed for this topic

12…7 Next »

Reply »

You must log in to post.