What is design resolution?

cocos2d-x C++
#21

Hadn’t the time for it, yet.

I updated my post, cause your resolutions don’t match your drawings. You are saying that your design resolution is 640x480, but your screen size is 704x480, but in the drawing your red square is smaller than the black one.

Regarding the red square being the screen size.
Screen size is smaller than the design size:
For the first image it will be P, because your screen resolution width is smaller than your asset width and the bottom left corner is always 0,0 screen resolution wise. The complete screen is your maximum drawable, so the origin is always at the left bottom edge of your screen resolution.

Screen size is bigger than the design size:
In the second image it will be Q, because your screen resolution width is bigger than your asset width, and so is able to show your complete asset. You will get black borders on the side and this will be treated as displayable area. Never the less, the origin will stay at the left bottom edge of your screen resolution.

If you have the policy show all, the black borders will be treated as non displayable area. like your device screen ends at the inner side of the borders. This will move your origin to the inside and the origin will be at P in the second picture.
The origin for the show all policy would be still at P in the first picture, as it can never extend further as your device screen resolution.

The origin can only move inwards and never extend the device screen resolution, if you have the show all policy. With policies like fixed width/fixed height, the origin will stay at the left bottom edge of the screen resolution.

#22

Edited. I was wrong. That will teach me to post without writing a quick program to check!

Now I am totally confused again myself!

1 Like
#23

No, always in the left bottom corner of the screen resolution.

#24

This will not be the case, as the origin will be at the bottom left corner of the device resolution.

If you use kResolutionFixedWidth, and the design resolution width is smaller than the screen resolution width, a sprite at 0,0 will appear in the bottom left corner of the screen. 0,50 will paint it 50 pixels to the right.

If your design resolution width is bigger than the screen resolution width it will crop the asset, but the origin will still be at the left bottom corner of the device resolution. The origin will not move outside the device resolution.

The visible origin is at 0,0 but the asset origin(which you don’t see) is at 0,-50.

The visible origin can never extend the screen resolution, it can only move inwards with the show all policy, as this policy remaps the screen resolution to the design resolution.

#25

Hi mate,

Nice tutorial… but still i am left with a lot of questions, which is quite obvious.
For the time being, leave cocos2d-x about how it manages to scale things.

First thing first, if I am not specifying any designResolutionSize() then what is the default design resolution that cocos2d-x picks…??

say i have an app and i am primarily designing it for the android tablets, now as they come in hell lot of different resolutions, that’s surely a pain.
so, when you are saying setDesignResolutionSize(1024,768)
what exactly do you mean…?? coz as i understand design resolution has nothing to do with the scaling of the assets.
say if the screenSize.width > 1024 , then use the assets greater than that (for example)
why is the designResolution required… ??

at the end of the day, it’s just the sprites in the app that’s need to be displayed and scaled accordingly to the resolutions of different android devices.

Explain this to me first, then i will ask next level of question.
so here i am posting it on the fourms, hope you help… :smile:
@Maxxx

#26

  1. If you don’t give it a design resolution then cocos can’t scale as it assumes yu made the resources for the screen size it is running on.

  2. What is design resolution?

OK, lets say you create a background image for your game and you create it 1024 x 768.
Now you create a sprite to suit that resolution - you might just paste your sprites on a copy of the image to make sure they look OK, and the size is right. Your design resolution - 1024 x 768. Your spright may be 64 x 64 pixels

If you now run your program on a screen that is 2048 x 1536 (i.e. exactly twice the resolution of your design resolution) then cocos2d-x can easily scale up your image by doubling its size (in both directions) and it will fit on the new screen perfectly. Your sprites will also be doubled in size, and the game will look exactly the same - just twice as big!

But wait! How does cocos know it’s twice as big? Twice as big as what?

Twice as big as the Design Resolution!

So Design resolution is how Cocos knows how much to scale.

Hopefully that helps!

#27

Yep - but in order to scale, cocos needs to know two things - the size the sprite was designed at , and the size of the screen to display it on. If you don’t tell it what size it was displayed at, how could it scale?

1 Like
#28

Superb… Excellently described @Maxxx

Now, the second set of question is -

  1. Say, i am using the designResolution of 1024 x 768
    unlike you’ve described in the example as twice the design resolution,
    assume that the device has a resolution which is of different aspect ratio
    or something that will not scale exactly as twice. What will happen. ?

  2. Say i am making 3 set of assets for my game.
    1024 x 768
    1920 x 1200
    2560 x 1600

and it’s a game lay out in landscape mode.
[link of apk][1]

suggest me the correct resolutions i should pick
in this game, the x-axis should be preserved.

Also, assume that i’ve picked the design resolution as 1024 x 768
it’s a logical thing.
but in order to view the game, i need a tablet (an android device in general)
say that device has resolution set of 960 x 640
In general, will it affect the design, if i choose the design resolution as same described above
and the device having different resolution. ?
How can i visualize the 1024 x 768 grid within different screen sizes ?
[1]: https://app.box.com/s/vzorgopuj69vn9fx13z7

#29

@Maxxx I made some calculations, I dont know whether they are accurate or not !!

I am posting the links here
these are the stats from the unity website.

Now, if i am about to target android devices the most common aspect ratio is 16:9
which equals to 1.77 on division.

I’ve listed some of the common resolutions on the android line up and they are -

  1. 1024 x 600
  2. 1280 x 700
  3. 1920 x 1080
  4. 2560 x 1440

they all have the same aspect ration of 16:9 resulting to 1.77 on division.
now for my game (any game with FIXED_WIDTH policy) the width is important right ?

as you’ve stated earlier -

the game acquires the design resolution based on the screen resolution (if design resolution is not specified)
So, the grid of the design resolution fills the screen entirely.
now, all we need to perform scaling.

Thus, the third set of question is -

  1. The default design resolution is the screen dimension and so we can get the design resolution anyway if we don’t even specify, that’s how cocos2d-x pipeline handles devices of different size.
    right ?

  2. Scaling of assets needs two thing - one is the resolution of the asset and is the design resolution.
    we have the default design resolution (say 2560 x 1600 ; which is also the screen size)
    say i have an asset of size 2500 x 1440 (randomly said )
    therefore, can we direct the game to different assets folder based of the if else ladder on choosing the right resolution ( by comparing the width of the screen and the one specified in the if - else condition ) ??

#30
  1. Your design resolution is 1024 x 768 and you display with a fixed width policy.

So imagine your device screen is 1024 x 600

Cocos will have to leave the scaling at 1:1 because it can’t scale the 1024 below or above (that’s what fixed width means) so you will lose 168 pixels (84 top and bottom) from your image, no scaling takes place.

Imagine your device screen is 1024 x 800

cocos again has to leave the scaling at 1:1. so now you have black bars top and bottom with a total width of 32 pixels (800 - 768)

Those were the easy ones!

Now, imagine your device screen is 1200 x 800
Cocos needs to scale the 1024 up to 1200 (because you told it fixed width) so it multiplies by 1.171875
And the fixed width policy tells it to keep the aspect ratio - so it multiplies the height by the same number - so the height becomes 800 * 1.171875 = 937.5 - which is 137.5 larger than your physical screen - so you lose that many pixels (68.75 at the top and bottom)

Hopefully you get the idea?

Your question 2 I don’t really follow what you are asking? Here’s some comments, though.

If you can decide on an aspect ratio for your resources that will scale up or down to fit most of the screens you want to support, without either losing too much from the top and bottom or having too wide black bars top and bottom, then that will start you off.

For your fixed width policy that means you want (probably) the aspect ratio that is the widest/shortest out there.

As a wild example, imagine you created your assets at 10,000 x 20

*** Edited to correct figures as pointed out by @iQD

Scale that to a 1024x768 screen, and your visible height would only be 2 pixels - massive black bars!!

create your asset as 3000,3000 and on 1024 x 768 screen it would be 1024 x 1024 - losing 256 pixels (if my maths is right!)

** end edit (thanks @iQD)

You get the idea?

You just need to find the aspect ratio that covers the screen aspect ratios you want to support as closely as possible.

so do the aspect ratio thing first.

Once you have decided on that, you can decide how many sizes of assets you want to provide.

e.g. you might have one high resolution asset to supply sprites for the two or three highest resolution screen, one medium resolution for the majority of the mid-range screens, and one low resolutions for hte older screens with lower resolutions.

This allows you to provide assets with the same aspect ratio at different resolutions, so scaling doesn’t get too bad.

Now one of the problems I came up with was that, to support fixed width or fixed height, supplying a single aspect ratio at three resolutions didn’t seem to suit all of the devices.

Which is when I created my spreadsheet at https://docs.google.com/spreadsheets/d/11YZN4cajRCUktdq72HQbLZfc6vreBA78-KDjGvR46Jw/pubhtml?gid=0&single=true

You can see on there that I am looking at four resources, at 1.33, 1.77, 1.5 and 1.78 aspect ratios - each covering different device sizes and resolutions

I think this might be overkill - but it looks to me like it would cover all current devices quite well!

1 Like
Optimal design resolution and assets folders formation (how to choose one?)
#31

  1. The design resolution = device resolution if you don’t specify it, yes.

is that what you meant to say (my bold bit added)

it sort of needs three things - the asset resolution, the design resolution and the screen resolution.

I think what you are asking is:

Don’t specify a design resolution
Supply a different resource based upon screen dimensions

If you don’t specify a design resolution, then I guess you would have to calculate the scale factor based on the “design resolution for the asset you have chosen” - ie you would have to hard-code the scale factor calculation - which is normally resource height / design height by hard coding the design height (you can’t use the system’s design height because it would be set to the screen’s height

I can’t see any advantage in doing it this way!

That’s exactly how you specify which asset to choose.

Or, more accurately, that’s how you can specify which assets to use.

As I have mentioned elsewhere, width (or height) probably isn’t enough to make a decision to suit every occasion.

1 Like
#32

you are right… @Maxxx :smile:

You’ve been through the apk right ?

could you suggest me what should be the design resolution and what asset resolution should i pick to cover most of the android tablets without any problem…??

#33

This is not correct.
As you specified fixed width, it will scale the asset down, not up.

Asset width / Design width = scaling ratio
10000 / 1024 = 9.765625

Asset height / scaling ratio = Design height
20 / 9.765625 = 2.048

So the design height will be 2.048 pixels, not 195 pixels.

Unfortunately your math is incorrect.

Asset width / Design width = scaling ratio
3000 / 1024 = 2.9296875

Asset height / scaling ratio = Design height
3000 / 2.9296875 = 1024

Asset height - Device height = black border height
1024 - 768 = 256

It will lose 256 pixels, not 262.

#34

Thanks IQD - I really must learn to check my posts before I click Send !

I will go and edit the post to avoid confusion by those who look at it in the future - but will reference your post too so there’s a paper trail!

#35

I haven’t looked at the APK as I don’t have access to a device at the moment to run it on.

I can’t make the decision as to what resolutions you want to choose - there is no ‘correct’ answer.

Look at the spreadsheet I linked to - it shows four asset resolutions, and how they fit, scaled, on about every resolution device there is.

You can look at that and decide if that suits you - or you could make changes to your own copy of the spreadsheet and find resolutions that suit your use case.

I haven’t checked if you can copy the spreadsheet that I lined to - if you can’t let me know & I can make a copy that you can play with.

Cheers

#36

This is a question, only a decent designer can answer. It depends on many things. Scaling algorithms, filters, GPU. Different hardware gives different results. You can achieve better or worse results, by choosing the filters and scaling algorithms based on your type of assets. Vector graphics need different settings than foto realistic graphics or stylized ones.

#37

Yes, that’s correct @iQD.

For the time being, i believe we will be targeting android tablets with decent config
and android jellybean atleast.
as the tabs are still not deployed to schools.
all the tabs in the future will be of better configuration.

So we can expect better performance.
As i was concerned about the FIXED_WIDTH, coz i would need that.

I’ve come up with 4 basic resolutions which fits all tablet devices.

1024 x 768
1280 x 800
1920 x 1200
2048 x 1536

if i choose these resolutions, i will directly use conditionals to check
if ( width == 1024 ) use low
like that for others and for all devices with resolutions other than that the low
else if they are > 1080 use the mid and high

so there would be minimun change of the height issue in there
and design resolutions would be same as the above mentioned asset resolutions.

I’ve a strong feeling this would work.
let me try that…

Thanks for all your support…

Happy Coding… :smile:

#38

In case this comes up n someone’s search - the url is now changed

http://pooperpig.com/?p=41

1 Like
#39

Hi,
Looks Like a bump to days old topic but seems necessary.
I have gone through the doc you have posted here https://docs.google.com/spreadsheets/d/11YZN4cajRCUktdq72HQbLZfc6vreBA78-KDjGvR46Jw/pubhtml?gid=0&single=true

I have gone through all the above post as I am new into Cocos2d-x world I’ll come straight to my question.
All the docs related to MultiResolution support seems to be outdated and they are moved into the same now.

What should I follow to design now. As my current design with iPhone5 (1136*640) is looking bed on iPad with no proper solutions so can anybody suggest a design guid for iPhone apps specifically.
Or any new insight with current cocos upgrades I am using Cocos2d-x 3.10 this days.

Thanks in advance.

#40

What do you mean by “looking bad on iPad”? Which iPad (what resolution?).
In what way do you think the docs are outdated?