Hi,
I have a project with 3 separate folders (for iphone, ipad and ipadhd) in my Resource folder filled with assets.
In AppDelegate I set the search path according to device resolution.
Is it enough or I have to set design resolution as well?
Regards,
Mike.
Yes. Set the design res… I use 1920x1080 for my games.
Please read this thread: What is design resolution?
It explains what is design resolution. Yes, you need to set it.
@IslandPlaya can you explain, why you choose this resolution? Because it’s your desktop screen resolution?
And doest it works well against ipad’s retina resolution that is higher then what you use?
It doesn’t matter what design res you choose. It is the virtual design resolution. I chose 1920x1080 as a suitable compromise for my games. You may have different choices, but I suggest you can’t go far wrong with 1080p.
I think Fradow may agree…
Can you explain in few words: why do I need to specify design resolution?
Well, in fact it does matter a lot, as you are creating your assets for it and down-/upscale them for the other resolutions.
If your design resolution is to low, assets will look smudged on higher resolutions. If it is to high, you will also gett patterns and distortion.
You have to select your design size which is a compromise between good upscaling and downscaling and you have to use the appropriate image filters, when scaling.
It’s not really the virtual design resolution, but the effective resolution for a 1:1 mapping to a device resolution(it’s the resolution you made the game for).
Cause you have to create your assets and layout for a specific resolution. Based on that resolution, your assets and layout will be scaled to different device resolutions.
Without the design resolution, there is no way for the engine, to calculate those scaling factors.
if engine is gonna handle my scaling then why do i make different assets.
I mean I understand the resolution policies but don’t know how to use resolution policy in accordance with same sprites made for different screen size and resolution?
To get rid of/compensate blurring, patterns and distortion.
If the engine scales your assets, it will introduce a lot of artifacts. Your assets will just look bad and crappy.
Creating assets for the most popular resolutions ensures crisp and fantastic looking assets.
You load the resolution specific sprites by setting the search path for those resolutions. The policy just defines, how it should compensate the difference between the closest asset resolution you are providing and the device resolution.
E.g. always scaling a single axis, both axis, keep ratios, invalidate ratios or doing no scaling/stretching at all.
So, having compromised design resolution (somewhat around ipad’s 1024 x 768) and 3 assets folders (SD/HD/HDR) the game should looks fine on most devices?
@iQD big thanks for your clarifications!
@iQD
Hi, i think I’ve started getting more clearer picture after referring to your answers and wiki again.
Just one more doubt…
I set my design resolution to be fixed height. Also, i set the position of my sprite to the center of the screen. But when I run it on my device. Instead of showing the sprite in the center of the screen. It starts the 0,0 of the sprite and matches it to the 0,0 of the screen!!
Why does it happen? Any idea…
Is it enough or to give more better idea about my problem, shall I upload exact things about what I was setting and along with pictures on my screen?
Also, see this thing…
In cocos2d-x, this is approach… resource res->design res->screen res…
So, here why do I convert in design res… I mean its fine that that is how API is designed, but on what basis I must select this design resolution because I am using this API because I want to adapt to every design resolution and so why shall I give my design resolution over here!!! Its a bit confusing? You got my doubt right!!
Also, please check whether I am correct: And just tell me one thing along it…
From WIKI:
//get screen resolution (NOT PHYSICS SIZE)
Director::getInstance()->getOpenGLView()->getFrameSize()
//get design resolution (NOT PHYSICS SIZE)
Director::getInstance()->getWinSize()
//get design resolution’s visable area size ?1
Director::getInstance()->getVisibleSize()
//get origin of the visIble area of design resolution ?2
Director::getInstance()->getVisibleOrigin()
Just see first 2 things in bold… I think I am correct.
For the next 2 things,
?1) Is it in terms of physics size or what? IF NOT then how is it different from getWinSize()
?2) I’ve seen origin mostly to be 0,0 . So, can you please tell me case where it is not…
Does it talk about devices which have bar at the bottom of the screen, like mostly in android device which don’t have physics button for going to home.
If so, then to mention again, I’ve a device which is like this but its origin is also always 0,0 !!!
Yes it should, except for the 2k Pads. Or the ones coming out in the future, having 4k or even 8k(just a prototype now 
)
1080p would be a good compromise as a design resolution, acting as a base for up- and down-scaling. Select your design resolution in a way, that it could act as a 1:1 mapping(for devices, which really have that resolution) and also as an in-between resolution, so both factors for up- and down-scaling are about the same.
E.g. the factor for down-scaling is about X and the factor for up-scaling is about the same X. Both factors should not differ a lot. but prefer down-scaling to up-scaling, as the latter has to increase the original pixel size of the asset and they will look blurry.
Three different resolutions are adequate. HD being your design resolution and SD and HDR are scaled, with HDR being some 2k resolution.
If you are using a texture packer, which offers automatic scaling and asset optimization, you should not use that, as it will not generate the crisp images you will get with other techniques.
Scale your assets with third party libs/tools like ImageMagick and pack those assets with the texture packer, disabling all optimization options. Also use PVR and compress them(this is loss-less compression, not to be mistaken with PVRTC, which is lossy compression), with pre-multiplied alpha, as it saves you a lot of space and increases performance. If you want the best fidelity possible, you should go with lossless compressed RGB8888. Actual devices can handle it with a breeze. If you want to go with older devices, you should check out other modes like RGB4444 or even use dithering. This depends on different assets. Menus need other modes/fidelity as backgrounds or fast moving sprites, animations and so on, if you want to optimize for RAM usage. You have to care much less on actual devices, as they all come with 1GB/2GB of RAM(newest ones even higher).
A little old, but you should check out those links(the stuff for iPhone also fits Android):
http://allseeing-i.com/Performance-tips-for-Cocos2d-for-iPhone
For the perfect scaling algorithms(well there is not really a perfect one, so let’s call it best options), check out those links:
http://www.imagemagick.org/Usage/filter/
If you don’t want to read all this high valued information, and you should, you can scroll down to the bottom and just read The Best Filter? conclusion.
With 3.2 and kResolutionFixedHeight?
Your origin(0,0) is always in the left bottom corner, if you don’t change it with OpenGL calls. Yeah, upload some things and also post your code.
You don not select a design resolution. It is set only it only once and only have one of it, not multiples. You let your app calculate the scaling factors at start-up, based on the device resolution. You adapt your assets to the device screen resolution, not the design resolution.
Check out this link, to see how to set design resolutions, resource/asset resolution and paths(you have to adapt the calls to the 3.2 naming convention, as the wiki is a little outdated here.
http://www.cocos2d-x.org/wiki/Multi_resolution_support
Can you post the link?
Is the (NOT PHYSICS SIZE) also in the wiki or is it your interpretation?
This is the maximum physical size, the device screen resolution, your device is supporting. The so called EGL view(a full-screen view). Compare it to the maximum resolution of your monitor.
The screen size is always the physical size.
This is the design resolution, you designed your game for. It’s just calling _openGLView->getDesignResolutionSize();
This is the same as getWinSize(the design resolution size), except you are using NO_BORDER as policy, as NO_BORDER is stretching your assets.
E.g. the device screen is 640 in width. So the pixel resolution would be 640. You have an asset, which is 500 in width.
This would not change the OpenGL points, as you would just get black borders and your asset would fit perfectly without stretching or scaling.
But NO_BORDER stretches the asset, so you don’t get black borders. The stretching remaps the resolution of 640 to the 500 pixels, so your virtual screen would be 500 in width now.
The physical resolution is still 640 in width, but the asset with 500 pixels in width now fills the entire screen width. So getVisibleSize would now report 500 pixels as screen width, instead of 640.
Size GLViewProtocol::getVisibleSize() const
{
if (_resolutionPolicy == ResolutionPolicy::NO_BORDER)
{
return Size(_screenSize.width/_scaleX, _screenSize.height/_scaleY);
}
else
{
return _designResolutionSize;
}
}
It returns the origin of your screen, the location where the coordinates of 0,0 start.
It is always at bottom left, except when using NO_BORDER. As NO_BORDER is stretching the asset form the center point, it will return the center of your screen. Why they did that? Beats me 
Maybe cause it is more convenient.
Vec2 GLViewProtocol::getVisibleOrigin() const
{
if (_resolutionPolicy == ResolutionPolicy::NO_BORDER)
{
return Vec2((_designResolutionSize.width - _screenSize.width/_scaleX)/2,
(_designResolutionSize.height - _screenSize.height/_scaleY)/2);
}
else
{
return Vec2::ZERO;
}
}
Not on the first one. The screen resolution is always the physical resolution, aka the maximum resolution of your device. Just like the maximum resolution of your monitor.
In terms of design resolution. It’s the same as getWinSize, exept for NO_BORDER: See explanation above.
In case you are using NO_BORDER. Then it is in the center of your screen.
The bar is just part of the frame. If does not add more pixels, if it is disabled. The asset will be just stretched.
If there is a bar, the origin is 0,0 at the bottom left corner above the black bar. If the bar is not visible, it is still at 0,0, but in the bottom left corner, where the black war ought to be.
The origin is always at 0,0, except with NO_BORDER.
Ya its my interpretation, actually…(the bold ones are my interpretation)
/////////////
I already checked the below link.
Also, I actually didn’t get what you explained for this part.
I wanted to say that when we do setDesignResolutionSize(x,y,ResolutionPolicy)
In this above statement, we give x and y as our design resolution.
So, on what basis we should give our design resolution?
/////////////
For FixedHeight Resolution Policy, I’ll upload them tomorrow morning as I am not on my computer right now…
Rest everything explains nicely
On the basis of your resolution, you designed the game for.
If you decided to design the game for 1080p, the design resolution would be 1080p.
If you decided to design it for 4k, it would be 4k.
You decide at which resolution the game would look best at, and then design it for this resolution, which you set with setDesignResolutionSize(x,y,ResolutionPolicy).
Hi @iQD
What is the effect of setting contentScale factor in case of exact fit resolution policy!!
Thanks
It’s the same effect for all policies. It set’s the overall scaling factor from physical resolution to design resolution, but the exact fit policy alters the assets by stretching them to their maximum physical resolution. This will invalidate your aspect ratio.
No, I actually meant that… If I use setContentScale factor after setting my resolution policy then shouldn’t it be worthless because it won’t do anything!!!
I mean, if design resolution has to take over, it will definitely make my graphics fit the entire screen(yeah aspect ratio is changed-doesnot matter, as I just want to know the concept ) without considering what my contentScaleFactor is??
Or, am I thinking in wrong sense…?
It is not worthless, as it always calculates the scaling factor between device resolution and design resolution. The graphics cannot be made fit, if it does not know the scaling factor up front. The scaling factor is determined by the axis relationship you choose. E.g. the height.
The factor is also used to map the OpenGL coordinates from the design resolution to the device resolution.
The exact fit policy works on the asset resolution. It stretches the assets by using the scaling factor and the difference between the design resolution and the device resolution.
E.g. Device resolution height is 640. Design resolution height is 320. The device width is 720. The scaling factor is 2.0. Your asset is 100x100. The asset width is not stretched from 100 to 720, but first scaled by the factor 2.0 in both axis to 200x200. After applying the factor, the asset is stretched to the device resolution, giving you an asset of 720x640.
Without applying the scaling factor first, your asset would also end up just being 720x640 but without being first scaled in both axis by the scaling factor, which would be just wrong, as the asset would not have been scaled accordingly to the scaling factor.
Well, not totally. You always have to scale all the axis first, to get the correct asset size for applying the policy.
You seem to think, that the scaling factor is only for resolution purposes, but it is also for mapping the OpenGL coordinates.
Just make an experiment:
Do a scaling on the original asset, followed by a single stretch in both axis.
Then do a single stretch on the original asset in both axis(without the scaling) and compare the final images.
Are they exactly the same?
I get what your saying, that setting a scale factor is useless, as the engine could set it automatically based on the design resolution, device resolution and the policy.
To find out, why the engine is relying on setting that factor by hand, someone would need to dig deep into the engine. May it is because of some design decisions, caching off the transformation matrix prior to applying the policy.