My suggestion is that we set a reference resolution to work in; so if you're targeting the iPad's native resolution but also want to run on the iphone, you'd do something like so:

[[CCDirector sharedDirector] setReferenceResolution:ccp(1024, 768)];
...
[mySprite setPosition:ccp(100,100)];

If I understood correctly the feature, I think it wouldn't work when the code is already resolution independent.

For example:

[[CCDirector sharedDirector] setReferenceResolution:ccp(1024, 768)];

// I use this code in a lot of places
CGSize s = [[CCDirector sharedDirector] winSize];
...
[mySprite setPosition:ccp(s.width/2, s.height/2)];

On the iPad it will place the sprite at (512,768),
but on the iPhone it will place the sprite at (120,80) (actually I don't know if I did the math correctly) and not at (240,160).

If people want the reference-resolution feature (this means loading bigger images in iPhone which might not always be possible since 2nd generation devices supports up to 1024x1024 textures while 3rd generation (and possible the iPad) supports up to 2048x2048 textures), I would be cheaper to scale down the game.

Something like this:

scale factor =  device_resolution / reference_resolution;
[scene setScale:scale_factor];

// if you are scaling down the game, don't forget to generate mipmap images.

IMHO, the game would look better if users have 2 different sets of images: high res images for ipad, low res images for iPhone.

Cool - I removed the hack from my post and just told people to get the latest release.

riq,

thanks! you are doing a great job! thanks again!

P.S. i'm running any template, and it's still in 320x480, how can i run it in iPad resolution? Thanks!

x0661t: yes, sure.
Please, see this thread:
http://www.cocos2d-iphone.org/forum/topic/4145

riq,

so, we can checkout svn?

SVN r1753 is resolution independent (iPad compatible): director, camera, effects, max texture size, (and even the tests) work on iPad in 1024x768.

if its called over and over (like multiple times per second) id define a var to hold the cgsize, if not and its only called sometimes, it really doesnt matter.

and eoin.
the if statement is necessary to set the correct size for the iPad if the screen size is detected to be that size, so you first set the size to iphone/ipod size and only change it if its an ipad. essentially the same as an if else but cleaner.

I was trying to do a quick local hack. The problem is that this function is constantly being called. Ideally you would want to do something like this:

CGRect rect;
// Get screen dimensions
rect = [[UIScreen mainScreen] bounds];

and use rect.size.width, rect.size.height

But I don't think you would want to do this over and over here. I haven't delved into the mechanics enough to know if the Director already sets these values to private variables initialized once on startup that can be accessed. That would be ideal - and yeah, no #ifdefs.

But I figured there was no point in getting into a detailed solution since I'm sure one will be coming soon.

Is the If statement even necessary. Why would w = frame.size.width/ 2, and h = frame.size.height /2 where frame was previously assigned [UIScreen bounds]? Is the call to UIScreen bounds expensive?

mitchallen why would use use an ifdef?

why not just use something like

float w = 480 / 2;
float h = 320 / 2;

if (CGRectEqualToRect([UIScreen mainScreen].bounds, CGRectMake(0, 0, 768, 1024))) {
w = 1024 / 2;
h = 768 / 2;
}

There appears to be some reported bugs on poor FPS performance in the sim for 3.2

https://devforums.apple.com/message/161171#161171

I've posted a temp hack to get around the hard-coding in Director.m: http://mitchallen.com/iphone/archives/506 . I tried it with code based on the Sprite demos and it seems to solve scaling on the iPad - at least in landscape mode.

I think the confusing issue here is that, as we all should know, the iPhone Simulator is useless for judging device performance of OpenGL. It's not even attempting to emulate the hardware but merely rendering its own OpenGL as if it were a Mac application.

So, what to make of the slow performance in the iPad simulator? On the surface, it seems ridiculous that our burly Macs can't handle something the little A4 supposedly can, optimized though it may be. Than again, perhaps the simulator itself is also poorly optimized.

Without hearing something from Apple, its hard to be sure about what is going on.

@Blue Ether thanks.

I guess at this stage we have to assume our games won't be graphics bound when upscaling to the bigger res. The A4 details seem a bit sparse at the moment. Riq, is there anything else to consider when scaling our games up to 1024x768?

I have no performance issues on my MacBook running iPhone apps in compatibility mode at either 1x or 2x, for whatever that is worth. But yes I do have problems when I start scaling everything up to fill the screen as a native iPad app.

@graphG: Max texture size in OpenGL ES 2.0 is 2048x2048. The ratio of screen size to max texture size is now not quite as good as it is on iPhone, but it should be good enough.

@Drunknbass yes I've compiled for iPad with the native screen size, and the performance is bad, 12-30 fps, where as the original app at the original resolution runs at 60fps on a gen 1 device.

As @ Barney said, I guess we have to keep the faith, and assume the new hardware can handle an increase in res without killing the framerate.

Does anyone know any specs on the GPU part of A4? i.e what is the maximum texture atlas we could use etc.... Sorry for the noob questions!

I have right clicked on my target and select Transition. Then changed my active target to the -ipad version.

But when I go to run in the simulator, I get the error:
"Failed to launch simulated application: Unknown error."

Am I missing something obvious?

are all these tests(w/ bad performance) using iphone compiled apps scaled to 2x? has anyone tried a full ipad screen sized eglview and see if it still runs as poor?

Hi @Barney

Yeah that's sensible, certainly seems the best way to approach this until we have a device to play with. Reports are coming in that the A4 is quite a monster so we should be cool!

@graphG....Considering past release cycles we can probably expect some Game specific updates as it gets closer to launch. I definitely encourage going into the forums or the bug reporting tool and providing feedback.

I think the most important thing for us in the interim is to make sure we have a good solid design and try not to deviate too far from the foundation laid in the current devices on the first go.

I'm hoping the device is going to at least be capable of scaling up the performance of the 3GS to the larger screen surface so most of our current games should be expected to function even if we ramp up the graphics quality accordingly.

The real question is how far we can go beyond that, but hey we're still talking Cocos2D so we should be okay.

Barney

@Barney interesting.... This is going to be crazy to get a game out for launch, if we can't test on the device how can we be sure it'll perform well!

I'm only getting about 24fps on a fairly beefy Mac Book Pro when I go to full resolution. The fan runs like its about to about to spin off the axle.

Let me know how your performance is, I am having real issues getting my game to run above 30fps in the simulator, see my other post.

Right click on your target and select Transition. Then change your active target to the -ipad version...

Have you guys got your projects working well in the simulator?

I've transitioned my app and have an iPad specific target. When running it my app is simply being scaled to 1024x768, blurring everything... etc. I'm not seeing the behavior you describe nsxdavid ('with the graphics all in the lower left of the screen').

> Correction, I think cocos2d DOES understand the bigger screen resolution... just that your app may or may not. :)

Any suggestions on how to take advantage of the extra space and have our apps run at true 1024x768? (Instead of 480x320 being scaled up to 1024x768).

Cheers,
d.

Confirming... coscos2d seem ready for large screen resolutions out of the box! NICE!

yea, Cocos2d works fine with the extra real estate

Correction, I think cocos2d DOES understand the bigger screen resolution... just that your app may or may not. :)

Here's some tips:

Take your existing cocos2d project:

Find the target for it in the groups. Right click and hit Transition. It will create a new target (and some other things).

You can now build your app two ways:

EIther as an iPhone app that will work in the iPad simulator (with the 2X button)

Or as a native iPad app with the graphics all in the lower left of the screen (because cocos2d doesn't understand the iPad's screen resolution yet)

Switch between them by changing the active executable in the drop-down.

-- David

Sounds like a good start.

I'm interested if anyone else has managed to figure out how to toggle between 1x and 2x iPhone modes in the iPad Simulator? Also, it appears as though the OpenGL viewport is not cropped or masked in any way. Objects moving in from off-screen are visible! It's quite hilarious and disappointing. Not sure if this is just a Simulator issue though. EDIT: Turns out this was because I wasn't building the project the correct way. My bad. Need to use Project/Transition to get things working right.

I'm somewhat concerned about the implications of the following statement for gaming apps:

'(New) An application’s interface should support all landscape and portrait orientations. This behavior differs slightly from the iPhone, where running in both portrait and landscape modes is not required. For more information, see “Designing for Multiple Orientations.”'

Hope there is some leeway for gaming apps here- otherwise yikes!