- 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!