What is design resolution?

[naghekyan]

From http://www.cocos2d-x.org/wiki/Multi_resolution_support I don’t understand what is design resolution size. But this is very important as content scale factor is being calculated based on resource size and on design resolution size. Resource size I understand like the canvas size one with the full screen background image is drawn by the artist. Usually they draw for iPad retina 2048 x 1536. So what is design resolution size, and how I should get/calculate that?

P.S. need help understand what design resolution is? and Which design resolution to use? are actually the same questions but also unanswered.

[TheRC]

Hello!

Design resolution is an auxiliary variable, which is necessary so that you can build your layouts without thinking on what screen it will be displayed.

Carefully read this part of the guide

designResolutionSize

All of your game’s coordinates are based on design resolution, no matter what the size of your device screen. If the UI layout of your game is the same on all resolutions, you only need a single set of coordinates.

I will try to explain a little more detail and imaginatively.

1. Take a blank sheet of paper and draw on it for our future layout of the screen.

2. Now draw a grid with comfortable for you size. This will be your design resolution size!

In the example this is (15, 10).

3. Add the code Director::getInstance()->getOpenGLView()->setDesignResolutionSize(15, 10, ResolutionPolicy::SHOW_ALL )

Ok, now you can define the coordinates parts of the layout, using your grid!

In our example, the coordinates of the sun will be (3, 6) and the coordinates of the Play button - (11, 4).

So now you can build your layouts based on your own coordinate grid. And until not worrying about different screens devices.

4. In addition to the coordinates you need to think about the size of sprites. To do this you need to have several sets of images in different sizes and Director::getInstance()->setContentScaleFactor().

I also recommend you read this.

P.S. Oh no, what the forum did with my layout of text!?

[TheRC]

I just want to clarify another 2 moment:

1. I was drawing such a large grid only for simplicity the example, this is incorrect. In fact it should be something like (800, 600) or (1280, 800).

Choosing the design resolution size I think - “for simplicity, I like to think that I work in one screen resolution and let this resolution will be equal to (800, 600)”.

2. Although now you can use constant values ​​for specifying the coordinates of objects. This method is not recommended. Will be better to calculate the coordinates in the process using the FrameSize and a ContentSize, as it is done in “Hello world”.

[naghekyan]

@TheRC thank you very much for the details answers. I understood that Design Resolution is a new coordinate system, that you sent with any scale you want. In you example it is 15x10 scaled coordinate system for positioning. But I have few more questions, as it is not completely clear to me, how those this multi-resolution thing work. Please, if you could answer that would be a great help.

1. Is there a recommended way to set Design Resolution depending on screen or resource size?

2. There are 5 different policies. Only one introduces distortion as aspect ratio is not preserved. It is in case of Exact fit policy. But in case of Fixed Height and Fixed Width I also expect to see distortion because of aspect ratio violation. Otherwise I see not difference between No border, Fixed Height and Fixed Width. They all preserve aspect ratio and they appear on screen with some cropping and with no borders. What is the difference then?

3. How visible size and visible origin is calculated?

4. http://www.cocos2d-x.org/wiki/Detailed_explanation_of_Cocos2d-x_Multi-resolution_adaptation is the last example it is written:

In my game, i need fully display of Y axis of the background picture. However, the X axis can be cut.

To reach this goal, i need the X axis to be cut both in these two processes.

I choose setContentScaleFactor(RH/DH) for first process. Second process have two choice kResolutionNoBorder() or kResolutionFixedHeight().

But http://www.cocos2d-x.org/wiki/Multi_resolution_support is Chart 2:

Chart 2: *Resource Size = 1024x768 ; Design Resolution Size = 480x320 ; Target Device Screen Size = 800x480 ; RH/DH ![](= RW/DW; NoBorder Policy_

And as you can see in the image there are right and left borders, whereas the policy is No Border. Is there a contradictions? Also as you can see X axis in not cut. Instead there are borders.

[ricardo]

“Design resolution” is a somewhat confusing name, but think of “logic resolution”.

[TheRC]

@naghekyan I am glad that it was useful to you.

Is there a recommended way to set Design Resolution depending on screen or resource size?

I think it depends on the layout and on your preferences. I use to design resolution the smallest of my resource resolutions.

There are 5 different policies. Only one introduces distortion as aspect ratio is not preserved. It is in case of Exact fit policy. But in case of Fixed Height and Fixed Width I also expect to see distortion because of aspect ratio violation. Otherwise I see not difference between No border, Fixed Height and Fixed Width. They all preserve aspect ratio and they appear on screen with some cropping and with no borders. What is the difference then?

You are right,
EXACT_FIT can distort the picture if the aspect ratio in the screen resolutions and design resolutions is not the same.
SHOW_ALL show the whole picture without distortion, but may appear with horizontal or vertical black borders.
NO_BORDER show the picture without distortion, but may not be visible part of the picture.

FIXED_HEIGHT guaranteed show the whole picture vertically, but horizontally picture can be trimmed, or vice versa may appear with vertical black borders, if the picture was not wide enough.
FIXED_WIDTH guaranteed show the whole picture horizontally, but vertically picture can be trimmed, or vice versa may appear with horizontal black borders, if the picture was not wide enough.

The difference between NO_BORDER and FIXED_HEIGHT (FIXED_WIDTH) is that in the case of use FIXED_HEIGHT the borders may appear, or may not appear.

!!!
And now, most importantly, all this is true only for the conversion of the design resolution in screen resolution.
It is all just transform the intermediate picture which was calculated for design resolution. Here is the answer to your fourth question. But first things first.

How visible size and visible origin is calculated?

You can get the visible size and visible origin of the calling Director::getInstance()->getVisibleSize() and Director::getInstance()->getVisibleOrigin(). It calculates the engine itself.

And as you can see in the image there are right and left borders, whereas the policy is No Border. Is there a contradictions? Also as you can see X axis in not cut. Instead there are borders.

This is correct. Just in these two examples used different resource resolutions.

In the first case, the author had in mind, he has a fairly broad picture, and, if necessary, he can sacrifice a part of this width. Therefore, does not appear any borders, after transformation from resource resolution to design resolution. Then follows the transformation from design resolution to screen resolution.

In the second case, vertical borders appear after after transformation from resource resolution to design resolution because the resource image is not wide enough. And does not appear any new boundaries aftertransformation from design resolution to screen resolution. But the old boundaries are not lost as yet been calculated in the previous step.

Thus, if you intend to use this tactic, you should make sure that your image was wide enough and you could easily sacrifice the left and right side.

Unfortunately I do not have time to do high-quality images for this.

[TheRC]

@ricardo For me, the logic is - “I think about this resolution when working on my design(layout)”.

[naghekyan]

@TheRC thank you very much. This is a great help even without pictures.

In the second case, vertical borders appear after after transformation from resource resolution to design resolution because the resource image is not wide enough. And does not appear any new boundaries aftertransformation from design resolution to screen resolution. But the old boundaries are not lost as yet been calculated in the previous step.

So once selecting design resolution we should keep in mind that we can introduce borders because of them too not only because of the the screen size if we use FIXED_HEIGHT or FIXED_WIDTH, right? This makes things complicated.

FIXED_HEIGHT guaranteed show the whole picture vertically, but horizontally picture can be trimmed, or vice versa may appear with vertical black borders, if the picture was not wide enough.

I have never noticed in wiki a sentence about borders for FIXED_HEIGHT and FIXED_WIDTH. Also in images there is no borders too. Also in both links there are notes that you could or it is recommended to use FIXED_HEIGHT and FIXED_WIDTH instead of NO BORDER. Some equivalency notes are present there too. For example:

However, kResolutionFixedHeight is different, design resolution is
equal to visable area, VisibleOrigin is always (0,0). getVisibleSize() =
getWinSize()，kResolutionFixedHeight reaches the same result, but
simplify the code.

kResolutionFixedHeight and kResolutionFixedWidth are evlove from
kResolutionNoBorder, it’s highly recommand you use these two policy in
your new project.

This policy is appropriate for the game, which the Y axis needs to be
full display, and X axis can be cut.It should use with
setContentScaleFactor(RH/DH)

In general you can use this mode like the No Boder mode, but there is no
need to use VisibleRect methods. If you place a sprite at (0/0) it will
always be in the lower left corner of the screen, If you place the sprite at
(winSize.width/2, winSize.height/2) it will be in the center of the
screen.

These ideas make me think that in case of FIXED_HEIGHT and FIXED_WIDTH policies, the deign resolution is refined so that you will see the image as it is in the case of NO BORDER policy. But in that case it should be either stretched and distorted, or they will be the same compared with NO BORDER and the existence of FIXED_HEIGHT and FIXED_WIDTH is not justified anymore.

EDIT: I have tested the chart 2 Chart 2: *Resource Size = 1024x768 ; Design Resolution Size = 480x320 ; Target Device Screen Size = 800x480 ; and even if there was policy NO_BORDER, there were borders from left and right as it is in the wiki page. So NO_BORDER, FIXED_HEIGHT and FIXED_WIDTH don’t guarantee no border. So strange and confusing, huh?

You can get the visible size and visible origin of the calling Director::getInstance()->getVisibleSize() and Director::getInstance()->getVisibleOrigin(). It calculates the engine itself.

I have used these functions a lot, but I don’t understand the logic of their calculation. In the last example of http://www.cocos2d-x.org/wiki/Detailed_explanation_of_Cocos2d-x_Multi-resolution_adaptation there are some notes about visible origin in case of FIXED HEIGHT and NO BORDER, but I don’t understand how they are calculated, and why visible origin in case of FIXED policy in in (0, 0).

EDIT: Generally I understand that visible size should be equal to design resolution keeping in mind that in case of FIXED_HEIGHT and FIXED_WIDTH policies design resolution, hence the visible size, can be recalculated. But visible origin is not clear how it is being calculated.

[TheRC]

@naghekyan Thank you for your praise.
The first thing I want to say that it just seems complicated. When I first read about the multi resolutions, I wanted only to panic and close all its.
A huge advantage is that when you once configuring multi resolution, you can forget about them, keep in mind only some minor restrictions of your layout.

So once selecting design resolution we should keep in mind that we can introduce borders because of them too not only because of the the screen size if we use FIXED_HEIGHT or FIXED_WIDTH, right? This makes things complicated.

Yes, we should have this in mind when choosing a design resolution, as well as the contentScaleFactor. But you are also right in that FIXED_HEIGHT (FIXED_WIDTH) refined the design resolution, what can prevent the appearance of boundaries.
Chart 2 it is a good example of how to incorrect choose of the design resolution, contentScaleFactor and ResolutionPolicy.

These ideas make me think that in case of FIXED_HEIGHT and FIXED_WIDTH policies, the deign resolution is refined

You are right, I did not pay attention to this detail.

I have used these functions a lot, but I don’t understand the logic of their calculation. In the last example of http://www.cocos2d-x.org/wiki/Detailed_explanation_of_Cocos2d-x_Multi-resolution_adaptation there are some notes about visible origin in case of FIXED HEIGHT and NO BORDER, but I don’t understand how they are calculated, and why visible origin in case of FIXED policy in in (0, 0).

I can not yet explain it without a certain amount of pictures. And not sure how to make it short and not complicated.
I note only that the visible size is also influenced by such things as the action bar in Android, which occupies part of the screen.

How about if I take a little time to think about how best to present examples and send to you the draft of a more detailed guidelines for review? But I need some time for this, as I am very busy before the release of our first game.

Maybe someone from the pro or cocos team can do it faster and better?
@slackmoehrle ?

[naghekyan]

@TheRC if you will be able to help, then it will be great help. But please don’t worry now as you are busy. My biggest conclusion about this topic is that wiki page is not enough detailed, there is a lack of examples, visible size and origin calculation mechanisms are not described, though they are used in explanations, and also there are missing good recommendations in which case how to solve the problem of muti-resolution support again on real examples. This is very important part of the game, and it should be very easy to solve this kind of issues.

[TheRC]

@naghekyan Thank you for your comments, it is very useful. I’ll try to help.
Now I have some sketches, I’ll do the writing guide in parallel with my main job as far as possible.

[naghekyan]

Thanks in advance.

[iQD]

Think of design resolution as the resolution of the game you are building it for. E.g. you want to build the game for a 1080p resolution, than this will be your design resolution.
All assets are designed for that resolution, without any distortion, as they are mapped 1:1. You also set your limits, absolute/relative offsets of your assets to that resolution.

When it comes to mapping the game/layout to different device resolutions, you have to scale it accordingly. This scaling can be accomplished with different policies. Distortion free or with distortion, down-scaled or up-scaled.

But in case of Fixed Height and Fixed Width I also expect to see distortion because of aspect ratio violation. Otherwise I see not difference between No border, Fixed Height and Fixed Width. They all preserve aspect ratio and they appear on screen with some cropping and with no borders. What is the difference then?

Why would you expect such a thing? Fixed Height and Fixed Width tells the renderer/layout engine to do a distortion free mapping of your design resolution axis onto your device screen resolution axis(height or width). Nothing will get distorted, as it will preserve the aspect ration.
The design resolution axis, which is larger than the device screen resolution axis, will get cropped, as it does not fit onto the screen. If x is larger, then the asset in the x axis will be cropped. If y is larger, then the asset in the y axis will be cropped.
Using No Border, it will stretch the asset in the appropriate axis, to get rid of the black borders, as the asset will be to small to fill one axis. This is the difference between Fixed Height/Width and No Border. No Border will always scale the asset, so the complete device screen is covered with the asset. The former policies will only scale to fill in one direction. So with FH/FW, there are cases, where one axis will not be cropped. E.g. The asset resolution in one axis is smaller then the same axis of your device resolution.

E.g. your design resolution is 480x640. Your device is 480x704. 704/640 is 1.1. If you choose Fixed Height, it will stretch the asset to 704 in height and 528 in width. As the device’s display is only 480 in width, the asset will be cropped in width.
A second device is 540x704. If you choose Fixed Height, it will also stretch to 704 in height and 528 in width. As the asset in width is smaller, than the device in width, you would see black borders on both sides.
You can set up the policy. so that the black borders are drawable content, and the coordinates map even into the black borders, or the virtual coordinate system is exactly the content you are seeing. Then there are black borders, but they are not part of drawable content. It’s like your device screen resolution ends at those borders. This would be the difference between the Fixed Height/Width and the Show All policy.
Another option would be the Exact Fit policy. This will, in both cases, stretch the asset to the maximum resolution of your device screen resolution, hence violating the aspect ratio.

I guess I will provide some drawings, which show the connections and overlays of the mappings available, when I have time.

[iQD]

but I don’t understand how they are calculated, and why visible origin in case of FIXED policy in in (0, 0).

They are calculated this way:
Calculate the ratio of the device resolution and apply the factor to the fixed design resolution axis, to get the resolution of the other axis.

Device Resolution: 800x480px
Design Resolution: 480x320px
CCDirector Window Origin: 0/0
CCDirector Window Size: 534x320px

Ratio: 800/480 = 1,666666666666667
Policy: Fixed Height
Window Size: apply ratio to the design resolution height. 1,666666666666667 * 320 = 533,3333333333333

Don’t get confused, as the resolutions are in landscape mode.

The reason, why the origin starts at 0,0 is, cause the drawable area starts at the outside of the black borders as a drawing rect. A drawing rect also starts at the left bottom corner and has a width and a height. The borders itself, add up to the drawable area.

[naghekyan]

@iQD thanks for your help too. So it was wrong to think that Design Resolution is equal to visible size. What about visible origin? How it is calculated?

[iQD]

Design resolution is only the visible size, if you have a 1:1 mapping aka your device screen resolution is the same as your design resolution.

What about visible origin? How it is calculated?

The visible origin is always calculated to the left bottom corner.

[naghekyan]

The visible origin is always calculated to the left bottom corner.

In the left bottom corner of the Design Resolution rectangle?

[iQD]

No, if your mapping is not 1:1. and so in the device resolution rectangle. The rectangle is the screen of your device.
Yes, if your mapping is 1:1. In this case, the asset is exactly the screen of your device.

[pabitrapadhy]

Hi @iQD i need your help in clearing the concept more extensively.
I’ve been through all the above posts.

In the above posts you’ve stated that… you will be helping us understanding the concept more clearly by giving some visual knowledge. If you’ve already done that please post a reply.

also… i’ve attached two images for my understanding at the beginning level, then i will be asking more questions.

the first image contains the design resolution grid which is assumed to be of 640 x 480 px

the first screen size is 704 x 480 px
so, the grid is extended outside the screen resolution
i am assuming the FIXED_WIDTH policy.

the second screen size us 704 x 540
same FIXED_WIDTH is assumed here
and… the grid is getting shortened, i.e. remaining within the height of the screen.

For the first set of question, i want to know that
what is the visibleOrigin whether it is P or Q

describe it for both the assumed images.
i hope you would surely help me…

@iQD @TheRC

[catch_up]

Just see if this helps
http://www.pooperp1g.com/2014/11/cocos2d-x-v3-x-multi-resolution-support/

by @Maxxx