[Discussion][SOLVED] Multi Resolution with SD and HD graphics

catch_up · August 15, 2016, 3:30pm

I am working with 3.11.1 and my Resources folder structure is as below

Resources
|_ Fonts
|_ Audio
|  |_ Music
|  |_ Effects
|_ Particles
|_ HD(high quality assets for high resolution devices like xhdpi, xxhdpi)
|_ MD (normal quality assets for lower resolution devices ldpi, mdpi, hdpi)

Only HD and MD are dependent upon the resolution, rest will be common for both HD and MD.
How to select custom path for assets depending upon my pseudo code.

Pseudo code In AppDelegate.cpp

designResolution = 1280, 720 (Height, Width)

//Logic to handle which QUALITY assets to pick
if(frameSize.height > designResolution.height) {
  designResolution = 2560, 1440
  //PICK HD Folder How??
} else {
  //PICK MD Folder? How??
}

//Logic to handle multi resolution resolution scaling factor
director->setContentScaleFactor(frameSize.height/designResolutionSize.height);

I know I’ve to use FileUtils::getInstance()->setSearchPaths(searchPaths); but how do I have to do when there are some common assets and some are different.

EDIT: I think I got the solution. I’ll post it soon after confirming for several scenarios.

Thanks

slackmoehrle · August 15, 2016, 4:49pm

You can set this multiple times.

catch_up · August 15, 2016, 6:48pm

Hey guys,

Want to learn MULTI SCREEN RESOLUTION ?
Where keeping aspect ratio of graphics is really important. Along with which, we also care that high quality graphics doesn’t load in memory for low end devices! Because you want to maintain performance and also no drain battery at the same time.

CONCEPT:
You can go through basic concept at What is design resolution?

IMPLEMENTATION:

There are different approaches for each type of game. In general, below code can work fine for other types, just change type of policy like FIXED_HEIGHT or FIXED_WIDTH, etc…

So, I’ve removed the default code which was present in 3.11.1 related to calculating scale factor as I didn’t need those things. So, only relevant code related to multi screen resolution left is below in my AppDelegate.cpp .

I’ve devices with 800x1280 (16:10) and 1920x1080 (16:9).
I generally think that 16:9 devices are easiest(not necessary best) as it is 1.777 which means max possible height in terms of aspect ration. Similarly, width wise, it is smalles possible!

So, I’ll be designing my graphics for 16:9 (You can do it for whatever aspect ratio but just that this ratio comes to the extreme in )

Note: I can design for 640x360 but then I can’t use these graphics for 1280x720 device because quality will be low.

Though there can be several folders like ldpi, mdpi, hdpi, xhdpi, etc. I won’t complicate logic for my
game and for you. I’ve simply 3 folders
1) sd(simple definition),
2) hd(high definition),
3) shd(super high definition).

Idea of keeping 3 folders and not 2 or 1 is that, shd will take care of devices like Samsung’s or Sony’s high end devices and other high ppi devices… Rest mostly, hd will come into place for all devices between 1280 and 1920 and below 1280 it will take sd. Also, you don’t have to worry about dpi, but just that what are no. of pixels in that device(eg. 1280x720 can be there in mobile or tablet. Doesn’t matter, they’ll use same graphics)

Note:1 Since sd graphics are made according to 1280, which means there is no worry of quality loss <=1280px devices and similarly for hd and shd.

Note2: It’s portrait game. So, I have used HEIGHT as all my comparison factors.

static cocos2d::Size designResolutionSize = cocos2d::Size(720, 1280); //(width, height)

    glview->setDesignResolutionSize(designResolutionSize.width, designResolutionSize.height, ResolutionPolicy::NO_BORDER);
    auto frameSize = glview->getFrameSize();

    std::vector<std::string> searchPaths;
    if(frameSize.height <=  designResolutionSize.height) {
    	searchPaths.push_back("sd");
    } else if(frameSize.height <=  1.5*designResolutionSize.height) {
    	searchPaths.push_back("hd");
    } else {
    	searchPaths.push_back("shd");
    }

    director->setContentScaleFactor(frameSize.height/designResolutionSize.height);

This was related to content scale. Now, I’ll do all my work depending upon %age of screen dimensions that is factors of visibleHeight and visibleWidth and hence now, I don’t have to worry about screen resolution or whatever.

PS: This above concept and code is all my understanding. There are hundred possible way of how you draw your graphics and how you want your game play to be. So, choose what’s best for you.

I checked for real devices 1280x800(16:10) and 1920, 1080 (16:9 ) and virtual device 2560, 1600 (16:10)

In case of any modifications, I’ll keep this post updated.
Feel free to correct me.

EDIT:
Instead of director->setContentScaleFactor(frameSize.height/designResolutionSize.height);

For each of if else block, write,

director->setContentScaleFactor(1);
director->setContentScaleFactor(1.5);
director->setContentScaleFactor(2);

Where 1 is my DR 1280, 1.5 is for 1920 resolution graphics and 2 is for 2560 resolution graphics.
Note, I’ve not written 1280x720, 1920x1080, 2560x1440 because when we say graphics are drawn for 1280x720, it means, we’ve drawn them by keeping 16:9(extreme case in max height and min width) by minimum and the width extends to 960 which will make it as 1280x960(4:3 the extreme case in smallest height with smallest width). That is why I mentioned just 1280 because my game is portrait and I designed my main parts inside 1280x720 and added additional things to width to make it 960 so that it works from all resolution from 16:9(1.77) to 4:3(1.333).
Hence it will also work for 1.5(3:2) and other random resolution that falls within 1.777 and 1.333.
Read more posts for clarity.

Thanks

Magniffect · August 15, 2016, 8:34pm

Hello @catch_up

It’s so cool when people find time to share their experiences with others. This could be a basis for the good guide.

But some ideas seem strange to me.

First let me know more information.

When you say that you design your graphics for 16/9, do you mean that you have drawn your layout of scene considering that it has an aspect ratio 16/9? Do you take into account what part of the layout will be cut off, depending on your multi-res support?
You have three folders. What resolution corresponds to each folder?
It’s strange to me that you select a folder by comparing the available screen size and design resolution. This is correct if resource resolutions in specific folders equal to design resolution or design resolution * 1.5.
As I understand setContentScaleFactor() defines as a resource resolution scaled to fit the design resolution. But maybe your solution is correct in this case.
Also, Do you taking into account that the navigation bar occupies part of the screen on some devices?

catch_up · August 15, 2016, 9:29pm

@Magniffect
Glad that you asked questions and your questions are really great.
I am not sure if you already know multi screen resolution concept but I am assuming you don’t know and I’ll answer one by one.

First of all, on very basic note, multi screen resolution has nothing to do with HD graphics or Low quality graphics. You can assume that you’ve just one set of graphics and scaling it properly is what makes your game capable of adapting for multiple screens… HD, SD, etc graphics are just for enhancing your game graphics so that you don’t load HD graphics on low end devices OR low quality graphics on high end devices.

1) It’s very easy to make graphics for icons/buttons/small part of screen but designing(plus writing scaling factor) for something that crosses the screen from either height wise or width wise is always main concern.

There are SEVERAL APPROACHES(whether your game is portrait/landscape/vertical/horizontal/what kind of vertical/horizontal/board game/etc.). And idea is to learn concept and not each approach. Depending upon our game, we handle graphics and code for multi screen resolution. What @SonarSystems explained for their graphics, it is very general way to explain this concept. Where we design main parts of our graphics in the common area which comes inside all aspect ratios.
https://www.youtube.com/watch?v=67KGqN3-Y&list=PLRtjMdoYXLf4C3yOPOLaQ0XF5RxnDTZ4A

Now, in my case! first of all, I’ve game in PORTRAIT mode and I am making a board game and for me, width matters a lot. It means, I am designing for the shortest width possible in aspect ratio which is 16:9 (1.777). And in my graphic(let’s say patterned rectangle), I’ll put my main things inside this shortest width and then extra part of this graphic can lie out side the screen, I don’t care. In wide width, more part of the patterened rectangle can be seen in narrowest screen which is 1.777 screen, my main part will always be accommodates. Well, you would say, I’ve board game, so why I am just caring about width!! BECAUSE I don’t have anything in my game which I should worry about height wise. Regarding picking POLICY (SHOW_ALL), I may change it. But again, it depends.

With the code above, my main motive was to show that in different design resolutions, I picked different graphic plus aspect ratio maintained!

2) What resolution corresponds to each folder!! Means? Didn’t understand your question properly. But in general, those are my own definition of high quality or low quality… As each of the 3 folders have highest quality of their category, so I think I am safe to assume whatever it is. I don’t have to worry much about edge cases that I am unaware of right now.
Also, as you can read in my code above… px <=1280 are SD (almost all ld and md and some hd will come inside it) 1280< and <=1920 is HD for me, where all hd and some xhd will come and >1920 all xhd and some xxhd should come. And some xxxhd devices will be there but I am safe enough since my SHD graphics are according to higher side of my SDH category… Again, I don’t have to worry about exact things. They’re my way of categorizing. Just that I don’t wanted to keep 4 folders for the very low end devices and neither I wanted to load very high definition graphics for lower kind of medium end devices.

3) I don’t have to compare available screen size, I could have hard coded it as 1280 but but!!!
For me, it’s good practice to keep design resolution same as physics device you have because you can test it easily. I could have kept my design res as 640x360(1.777) instead of 1280x720(1.777) but reason was why should I add complexity! when I have device of 1280x800 It’s good for me. Now, when I’ve written my scaling code, whatever I’ll make graphics according to 1280x720, I can always test on my 1920x1080 very easily for its correctness.

NOTE: Since, 1280x720 is too huge to design graphic. My actual corresponding size in graphic software is too small (157.5, 280) Now, when I export my graphics for SD, HD, SDH, I simply scale my graphics by some factor. And this factor, I don’t calculate, I just tell it that my window size is 1280, 1920(1.5x), and 2560(2x). and it calculates for me nicely. 1280, 1920, 2560 are just dividing lines for pixels that device would be having. Ex. Y can be anything in 2560xY, I just know that Y would be too high for sure to make it easily eligible to pick SHD, and similarly for 1280 and 1920… Note, I don’t have to be so much exact bcoz there are too many cases and I don’t feel like adding complexity.
You can pick folders width wise also if you want! No issues in that.
BUT!! SCALING whether according to width or height MATTERS a lot. In my case, I’ve done it according to HEIGHT(WHY??) IT’S IMPORTANT TO SEE CAREFULLY… I told that, ‘given my game’ it’s much convenient for me to design for 1.777(which is extreme case of height(max) or width(min)).

Which means… suppose if I am putting logo in the middle of screeni in my graphic like below,

then what possible combinations can be in my player’s device!! 2 thing to look at…

A) KEEP SAME HEIGHT, increase width…(decreasing aspect ratio)
Does it look odd to you? It won’t… because my code said that all are 1280px so don’t scale any of the icon or font/image!!

Note: I’ve not decreased width bcoz I just told that I have extreme case of width(min)

B) keep same width , change height (still decreasing aspect ratio)
Does, it look odd to you? I won’t… because my code scaled things down as I told that height is smaller than 1280 which is my design resolution.

Note: I’ve not increase height bcoz I just told that I have extreme case of height(max)
Also, I don’t have to calculate whether the other screens are 3:2 or 4:3 or blabla, they can be anything, and hence the design on right side of my main design are random increment in width/height.

C) Now, you can decrease width/height at same time. Code will adjust automatically just like school’s physics chapter! Work for y and x and combination will resolve by itself.

By keeping extreme case, I’ve simply decreased my pain of calculations, otherwise, I would have lost what to do when… I didn’t complicate.

4) Sorry, I didn’t understand this question.

5) Taking into account navigation bar doesn’t matter because what I tell that you never had that part of screen or what if I say that a new device is manufactured where navigation bar is not there but screen height is smaller by equivalent to height of navigation bar in some device!
Anyways, I’ll be removing navigation bar in my game through code. I’ve put up a topic asking how to remove it.(I know it can be removed)

Don’t try to apply my approach directly to your game even if it is portrait or board game! Because, you must also know how are you designing graphics according to the scaling code you’ve written!
All depends…AFAIK, I’ve written correctly for the scenario, I talked about here.

AGAIN… there are several approaches. You can do whatever, according to what is your game mode-portrait or landscape, game type, how are you designing graphics, and most importantly how do you game to look like etc.
You don’t have to learn all approaches, not even one. Just see the concept. And you yourself can apply to all and anything that can come in future.

Can I change, my RESOLUTION POLICY… Yes, I might! But do I need to change my scale factor logic? No, because that is how I am designing all my graphics…so, if I’ll change then I’ll have to make logic calculations again to ensure things.

Magniffect · August 16, 2016, 12:23am

First of all, calm down. The presence of a large number of exclamation points and caps is not a respectful attitude to the interlocutor. In the end, people can stop wasting time on talking with you.
I had no intention to offend you in my post, just hoping for a little discussion on an interesting topic.

p1. In your previous post you use NO_BORDER, and therefore if you drew your layout believe that the device will be 16/9, and it’s actually 4/3, then I would be a little bit worried in your place since the visible height of the design resolution will be cut.
Maybe you do not have to worry about it in your case. But if another programmer has a background image with important content or large UI, then it becomes a problem.

p2. I mean resource resolutions.
This is resolution for which your resources are drawn.

For example, I have a background image with a resolution of 1920x1080 (in my particular case), and I have a few pictures with the appropriate size for my sprites and menus.
And I put it all in one folder.
So 1920x1080 is one of my resource resolutions corresponds to this folder.

Then I copy the folder and reduce the size of all the images in half.
So 960x540 is another of my resource resolutions corresponds to second folder.

etc.

In some cases, the resources can be drawn for resolutions which have a different aspect ratio.

Why should you worry about the resource resolution? For example, if you do not want to have black borders on any device.

p3. I do not think I understand what you’re trying to say. Considering that you’re talking about the portrait and at the same time say 1280x720. Portrait is 720x1280.

In general, the searchPath should not depend on the design resolution. It should depend on what resource resolutions you have.

p4. setContentScaleFactor() controls how resource resolution and design resolution are related, not the screen resolution and design resolution. Please read the wiki on this site.

p5. Navigation bar gives rise to black borders or cutting of the image in a very unexpected situations

To summarize, if you want to write a useful post on the multi-res support, then you worth to clarify that everything is correct only for your particular case, and describe your case in detail.
Or describe all the cases and how they differ.

catch_up · August 16, 2016, 12:52am

Exclamation is not necessarily put to show rage or whatever you have understood it as. It’s also used as to emphasize on certain line in a paragraph, since it’s a extremely big thing.
And if you really think, I need to calm down, first mind it that I wouldn’t have written such 2 big posts, in one of which I’ve humbly addressed your question in detail!! Moreoever, before saying that to me, you should have realized that I spent 30-40 min writing that answer and rechecking what I wrote!
That also costed me checking on multiple emulators which finally ended up not working for me as they work extremely slow with eclipse… Also, I am in middle of developing my game.

Yes, I am using EXCLAMATION… And it’s not anger or bad thing! It’s simply making the line focus, so that you rem. it.

In fact, I’ve appreciated your questions in my first line itself of my post.
Glad that you’ve found multi resolution topic interesting. Given that what you’re saying to me, I was just simply thinking to remove my both the posts! But since it’s for benefit of community from which I’ve learnt a lot, I am keeping it not as my property but as creating a good community.

I humbly say don’t jump to conclusion so fast. You could have asked what is my reason of putting so many exclamation points.

I understand why you would have said it. I read sometime back there is difference in cultures world wide. I read an article long time back, it described, that giving watch as a gift to a person in China, not keeping doors open for other person passing in switzerland is considered as bad gesture, not saying thank you for it is again considered as bad gesture and so on…

I am taking it on a positive note. So, shall you. Don’t consider small things as bad gesture otherwise, I wouldn’t have spent long time writing that post for you while I was in the middle of my work. Well, I am ignoring your last post for sometime. I am sorry. But I should give priority to my work now.

Magniffect · August 16, 2016, 2:12am

Ok, I understand you now.
But as far as I know rule regarding exclamations and caps is worldwide practise. So be careful using its.

I’m not saying that you should delete your posts.
But your implementation of MRS looks really strange to me. But maybe you just found a creative way to implement it for your case. And in order to understand it, I asked for more information.

p.s.
If you want to test only the multi-res support, you can use win32 project. According to code in the AppDelegate.cpp, you can also use Mac or Linux, but I do not know how.

To do this, you can change this line in the AppDelegate.cpp.

glview = GLViewImpl::createWithRect("HelloCpp", cocos2d::Rect(0, 0, _width, _height + _window_title_height));

_width is width of the screen resolution of your intended device
_height is height of the screen resolution of your intended device

_window_title_height is height of the window title, depends on the version of your operating system, you can calculate this by experiment.
This is needed because if you just write

glview = GLViewImpl::createWithRect("HelloCpp", cocos2d::Rect(0, 0, 720, 1280));

then frameSize.height will be equal to something less than 1280.

If you want to take into account the effect of the naviganion bar, then

glview = GLViewImpl::createWithRect("HelloCpp", cocos2d::Rect(0, 0, _width, _height + _window_title_height - _nav_bar_size));

But you will need to calculate all the possible size of the navigation bar for each screen resolution. This depends on the dpi.

I often use the win32 as it is actually faster.

Good luck with work!

catch_up · August 16, 2016, 6:14pm

Yes, you’re correct. As I also mentioned, I might have to change this but scaling factor logic still won’t change. In 1-3 days, I’ll try this policy out, otherwise, I might change that to fixed height… But I won’t change it to fixed_width. Most likely, I won’t have to change as background in my game is most secondary thing. Only for aesthetics as it’s only a board game.

Yes, mine is also similar to this. It’s like mine 1920(1.5x), 1280(1x) and 2560(2x). It’s just the terminology, you use. Depending upon my screen size(pixel), I can also change my design resolution in my code but that is not good idea. In above 2 sets of comparison(reducing height or reducing width…I none of them I’ve reduced height/width of background. It’s just the screen size according to which more or less portion of bg is coming, hence aspect ratio is maintained). Not sure if this is what you told to be discussed…

Yes, you’re correct. Some people keep width(width/height) first while reporting dimensions and some do height(height/width). To avoid confusion, in general, I simply set “portrait” in AndroidManifest file and you can assume 1280x720 or 720x1280 whatever it is, the larger one is height in case of portrait.

Yes, you’re absolutely correct. It should be.
TL;DR My design and device resolution are same. So, I used that instead of hard coding numbers(1280/1920/2560).
Long
Since, I told in my previous post, that it is always more convenient to keep design resolution same as your available device, hence I kept my design resolution as what device I have and so are the graphics size according to it. I was lucky that I’ve device of extreme case(like I explained for width and height), otherwise most likely, I would have to think different way. Because testing on emulator is really tough for me bcoz devices are really fast.

No, I wasn’t asking you whether you want me to delete or not. It was just that I got a bit furious that in my entire long effort of putting up the post, you simply noticed exclamation or bold letters as the first thing. Where, moreover, I wrote it so that long paragraphs become more readable where exclamation and bold help to bring focus on important points. So, I wanted to delete my posts as I didn’t want to share with you anything. But never mind. My other mind told me that it’s for the benefit of community and keep personal ego out of it. I am not egoistic person so I ignored it as I understand cultural differences.

Thank you for the code. May be if I work on windows laptop, I’ll try it. Right now, I do programming on mac, so may be I won’t be able to try it out. But I’ll try to find out a way to work with genymotion or else I’ll check on my friend’s devices.

As far as I think, navigation height doesn’t matter to me. Or in general, I think it shouldn’t matter. Why do you think, it would? As firstly, I’ll hide it in my game. Secondly, if my game can adapt different screen sizes well, then I don’t have to worry since 0,0 origin will always start from bottom left and in case of navigation bar, it will start from the end of the navigation bar.

I am trying out multi resolution first time with cocos2d-x but doesn’t matter. I know the concept and have applied it to Corona SDK as well as Libgdx and it worked without creating any confusion to me.
And I wrote the code for my cocos2d-x game without confusion and I think it worked so far so good.

In case, I face any issues and change some logic, I’ll keep this post updated and will also notify you.

People are good… People have flaws. Try to ignore them if possible and especially on internet bcoz expressing intentions is difficult using words/exclamations/bold/caps.

If things for my first game turn out well, I might probably, write a tutorial. There were tons of concepts/notes, people shared. But none shared a piece of code explaining even one side of MSR…Nothing helped. I got bored as I thought I’ll never be able to ship my game And I know, Programmer’s Guide never covered it in detail. So, I think, if I can help, I should write a nice tutorial some day. Although, I can write a 50-60 page book on it but I’ll keep it limited to one concept. Simple implementation of MSR was never a big thing but I always looked for that one strategy which covers all kind of MSR for all game types. While in actual there are several strategies but concept is same. I hope I know it correctly

Thanks

Magniffect · August 17, 2016, 12:14am

My question was:

Because the chosen MRS affects to how your layout should look. What aspect ratio should have a background image and how UI should look. Of course, this does not affect the logic.
I can not just take the canvas 720x1280, draw my layout and not have to worry about anything.

As I understand it the MRS in the cocos2d-x is based on three concepts
Resource Resolution (RR), Design Resolution (DR) and Screen Resolution (SR).

And MRS operates in two stages

Converting from the RR to the DR
This is configured using the director->setContentScaleFactor()
Converting from the DR to the SR
This is configured using the glview->setDesignResolutionSize()

note: I did not look deeply into the source code of the engine to see if these steps do happen one after the other. I think this is just a simple abstraction.

So my question was:

Because I wanted to calculate whether there is no problem in the first step for you.
Now when I know more about your game, I think that the problems will not be.

It would be better if I wrote it at the end of my post?
Besides, I also wrote a big post for you.

Can you use the directory proj.ios_mac to build a desktop application for the mac?

I dont know if it does matter for you or does not.
Just keep in mind that the 16/9 and 4/3 is not extreme cases for the aspect ratio, as there is a navigation bar.

Example, I want the landscape orientation, it is important to show the full height of my layout, and not have black borders.
So I use
DR is 1280x720, setContentScaleFactor(RR.height / DR.height)
and setDesignResolutionSize(DR.width, DR.height, ResolutionPolicy::FIXIT_HEIGHT)

How do you think background image with a resolution of 1280x720 (16/9) will be correct in this case?

I do not share, because it is a really a big topic.
And I think to clearly explain the concept and show all the nuances, it is necessary to draw lot of images and show a lot of cases. And it really takes a lot of time and effort.
Otherwise, it will be another one not too clear guide.

And in my experience, people usually do not appreciate when you do altruistic things for them.
Earlier in my life I did a lot altruistic acts. I thought that “today I will help someone, and maybe tomorrow someone will help me.” But almost always people just use you, and will not try to help when you need help.
Perhaps this is because of country in which I was born and live. I’m not sure.
As I see you are from India. I have heard that people are very friendly in this country, despite the economic situation and corruption. If this is true, then you are lucky.

Magniffect · August 17, 2016, 12:58am

I’m still confused by

I understand that frameSize.height is correlated with your RR.height. But are not equal!
What if the device has a screen with the resolution 320x480?
In the classic implementation of the MRS it is supposed to use RR.height / DR.heidht.
So, I think you get changes of scaling.

catch_up · August 17, 2016, 2:53am

Yes, I do take into account. When I say that I designed my graphics as per 16:9, that means whatever I am drawing inside of it(width wise) will always be seen irrespective whatever the screen size is. But on wider screens, black area would come, so yes, I’ve to draw uptil the resolution 4:3 which is 1.33 which has maximum width wrt to height. And most likely there can be devices with much wider width than 4:3, so I’ll make a bit of extra(uncalculative extra just to be safe).

Yes, you’re correct that these 3 are important factors for MSR.

Even I thought exactly the same way… And instead of my current code:
(For below codes, I am removing shd for simplicity)

std::vector<std::string> searchPaths;
    if(frameSize.height <=  designResolutionSize.height) {
    	searchPaths.push_back("sd");
    } else if(frameSize.height <=  1.5*designResolutionSize.height) {
    	searchPaths.push_back("hd");
    }
    director->setContentScaleFactor(frameSize.height/designResolutionSize.height);

, earlier I also wrote the logic as:

std::vector<std::string> searchPaths;
    if(frameSize.height <=  designResolutionSize.height) {
    	searchPaths.push_back("sd");
        director->setContentScaleFactor(1.5*(frameSize.height/designResolutionSize.height)); //NOTE 3/2=1.5 factor here as my sd graphics are 1.5 times smaller
    } else if(frameSize.height <=  1.5*designResolutionSize.height) {
    	searchPaths.push_back("hd");
        director->setContentScaleFactor(frameSize.height/designResolutionSize.height);
    }

But after implementing and running this earlier logic, I realized that cocos2d is handling it by itself and I don’t have to write it separately. It was on the basis of my observation on how cocos2d worked when I implemented it.

Should not though but not sure if writing

glview->setDesignResolutionSize(designResolutionSize.width, designResolutionSize.height, ResolutionPolicy::NO_BORDER);

before

director->setContentScaleFactor(frameSize.height/designResolutionSize.height);

could have made the difference. It’s lame I know Otherwise, as per what you also told, I would have write my code as either with 1.5x as in the above 2nd logic or else if my scaleFactor statement is common for all sd, hd, and shd, I would have to write:

    std::vector<std::string> searchPaths;
    if(frameSize.height <=  designResolutionSize.height) {
    	searchPaths.push_back("sd");
        glview->setDesignResolutionSize(720, 1280, ResolutionPolicy::NO_BORDER);
    } else if(frameSize.height <=  1.5*designResolutionSize.height) {
    	searchPaths.push_back("hd");
        glview->setDesignResolutionSize(1080, 1920, ResolutionPolicy::NO_BORDER);
    } 

    director->setContentScaleFactor(frameSize.height/designResolutionSize.height);

Your question is really valid, and I’ll do more experimentation when I will put background and other things on screen. I’ll get back to this again and confirm you what’s the status…
As I also think that my code should be simply: Bcoz given one set of graphics, cocos in my knowledge, scales everything down or above according to setDesignResolutionSize and not setContentScaleFactor, which in my case is 1 because 1280, 720 are DR as well as RR.

director->setContentScaleFactor(1);
director->setContentScaleFactor(1.5);
director->setContentScaleFactor(2);

Haha, then I would have saved my post as draft And would have still posted it next day.

I never tried working with iOS or mac application. I’ve kind of 10GB left in my laptop, so not sure if I would be able to install iOS/mac packages like I had to do with Android. If they don’t take much space, then sure… I’ll check tutorial for running cocosd2d-x on proj.mac. I’ll do it in 3-4 days. Gimme some time.

Yes, it is extreme case even if navigation bar exist. I mean to say, even if device is of the aspect ratio say 16:9 in total but if available area(for app) is lesser than 16:9 then it won’t treat screen as 16:9 but lesser than 16/9 and scale factor will adjust graphics accordingly. While writing scaling factor code, I feel that main concern should be available area on the screen for app rather than with or without navigation bar.

Without nav bar, complete thing will come. With navigation bar, the screen will not be treated as 16:9(1.777) but for example say 1.7 and since your policy is FIXED_HEIGHT, the extra portion that you would have drawn outside your DR(width wise) will adjust(if you wouldn’t have). Note height will come completely in all cases. It’s just that in case of 16:9 the least portion of your graphics will be seen and as the ratio will become shorted, more and more area of your background(width wise) will start accommodating on your screen. If you would have drawn graphics only for 1280x720 then it will bring BLACK area. If you would have drawn graphics for 1280x960(4:3) then in case of screens 16:9 1280x720 portion would have shown and in extreme case, 1280x960(complete background) would have shown. And since your DR is 1280x720, you should keep all your important things within 720 because 720 <=960 and area under that will always be shown and you can be sure of this while for the area outside >720, you have to keep extra(less important) things.

Note: Drawing graphics for 1280x960 doesn’t mean, your DR changed to 4:3 from 16:9. It just meant that you’ve drawn extra portion width wise to be shown on wider screens than 16:9.

I think that explained.

I see, that your concepts related to MSR are pretty good.

Yes, it’s universal. Most people won’t help. Well, don’t ask help from them And don’t expect help in return. I am not writing this so that you or someone else will help me in future. There are tons of resources here and there. Those people who don’t feel like helping will never flourish. It’s a narrow minded living. Don’t restrain, yourself. If you get free time, help other. If you want to help others but not getting enough time, well, take out some Think about why cocos2d-x is providing you their free and open source framework! Did it ask you anything? Well, we can return to the community if possible

[quote=“Magniffect, post:10, topic:31448”]
As I see you are from India.
[/quote] I feel, it’s not about the country. It’s about the environment(both surroundings and inside body ) is what makes you different. Well, ya, corruption is there in India, but it is probably, one of the most liberal country.

catch_up · August 17, 2016, 3:53am

@Magniffect

I am yet to try but now I understand why it worked for me while you were still doubting how it worked …

Because I had graphics for 1280, 1920 and 2560 which means my
frameSize.height/designResolutionSize.height
and RR.height/DR.height are equal for the case where my devices size are also 1280, 1920 and 2560 and hence I never encountered a problem bcoz my testing device and virtual device I picked .

Since, cocos2d-x handle scaling automatically as per setDesignResolutionSize, I don’t need to do it myself using frameSize.height/designResolutionSize.height which some frameworks do need.
And simply putting 1280/DR.height, 1920/DR.height and 2560/DR.height for each of if else block will help.

Hence below should be correct solution.

I hope we both agree to this thing. I’ll test it and will also let you know.

Btw, I see, that your concepts related to MSR are pretty good. Have you implemented MSR previously in any game with cocos2d-x? I, once, made cocos2dJS game but the engine handled scaling automatically for my one set of graphics. Also, are you professional or student/hobbyist game developer like me?

Magniffect · August 17, 2016, 4:18am

Yes, absolutely.

Thank you! I have two prototypes with different MRS policies.

I will answer your other questions, but very slowly. Since my English level is very low, it takes a long time to write a answer.

Magniffect · August 17, 2016, 4:46am

But you use NO_BORDER.
And I do not understand you. I think the image may help.

In the following questions, I think we understand each other now.

There is no difference in what order you write it. But there is a difference in what order the engine calculates it.

Did you notice that I am talking about the landscape?
If yes, then Do I understand correctly that the 1280x960 is the correct size of the background image and 1280x960 is the correct RR?

p.s. I has tested win32 project in the last version of the cocos from githab, and found that you do not need + _window_title_height to get the correct frameSize.

catch_up · August 17, 2016, 3:20pm

Yes, I noticed it and explained it according to the scenario you described. You’re correct, 1280X960 is the size of actual background and also 1280x960 is the RR. But your DR is 1280x720.

Might be there is a change in latest cocos2d-x version. But When I CCLog my values they were coming correctly without adding anything in the code. I mean, it was already written by cocos2d-x, so I didn’t modify it.

Magniffect · August 17, 2016, 11:29pm

This _window_title_height applies to my previous post where I said

I was wrong. I’m not sure if this is related to the cocos versions, or this is related to my previous programming experience for the win32.
In any case, I am sorry for that.

Magniffect · August 18, 2016, 12:27am

Ok, I used a standard “Hello World” template and changed the MRS policy. In addition, I have only one folder to simplify.

The AppDelegate.cpp

#include "AppDelegate.h"
#include "HelloWorldScene.h"

USING_NS_CC;

static cocos2d::Size designResolutionSize = cocos2d::Size(1280, 720); // <- DR
//static cocos2d::Size smallResolutionSize = cocos2d::Size(480, 320);
static cocos2d::Size mediumResolutionSize = cocos2d::Size(1280, 960); // <- RR
//static cocos2d::Size largeResolutionSize = cocos2d::Size(2048, 1536);

AppDelegate::AppDelegate()
{
}

AppDelegate::~AppDelegate() 
{
}

// if you want a different context, modify the value of glContextAttrs
// it will affect all platforms
void AppDelegate::initGLContextAttrs()
{
    // set OpenGL context attributes: red,green,blue,alpha,depth,stencil
    GLContextAttrs glContextAttrs = {8, 8, 8, 8, 24, 8};

    GLView::setGLContextAttrs(glContextAttrs);
}

// if you want to use the package manager to install more packages,  
// don't modify or remove this function
static int register_all_packages()
{
    return 0; //flag for packages manager
}

bool AppDelegate::applicationDidFinishLaunching() {
    // initialize director
    auto director = Director::getInstance();
    auto glview = director->getOpenGLView();
    if(!glview) {
#if (CC_TARGET_PLATFORM == CC_PLATFORM_WIN32) || (CC_TARGET_PLATFORM == CC_PLATFORM_MAC) || (CC_TARGET_PLATFORM == CC_PLATFORM_LINUX)
        glview = GLViewImpl::createWithRect("MRS", cocos2d::Rect(0, 0, 1280.0, 720.0));
#else
        glview = GLViewImpl::create("MRS");
#endif
        director->setOpenGLView(glview);
    }

    // turn on display FPS
    director->setDisplayStats(true);

    // set FPS. the default value is 1.0/60 if you don't call this
    director->setAnimationInterval(1.0f / 60);

    // Set the design resolution
    glview->setDesignResolutionSize(designResolutionSize.width, designResolutionSize.height, ResolutionPolicy::FIXED_HEIGHT);
    auto frameSize = glview->getFrameSize();
    // if the frame's height is larger than the height of medium size.
//    if (frameSize.height > mediumResolutionSize.height)
//    {        
//    }
    // if the frame's height is larger than the height of small size.
//    else if (frameSize.height > smallResolutionSize.height)
//    {        
        director->setContentScaleFactor(mediumResolutionSize.height/designResolutionSize.height);
//    }
    // if the frame's height is smaller than the height of medium size.
//    else
//    {        
//    }

    register_all_packages();

    // create a scene. it's an autorelease object
    auto scene = HelloWorld::createScene();

    // run
    director->runWithScene(scene);

    return true;
}

// This function will be called when the app is inactive. Note, when receiving a phone call it is invoked.
void AppDelegate::applicationDidEnterBackground() {
    Director::getInstance()->stopAnimation();

    // if you use SimpleAudioEngine, it must be paused
    // SimpleAudioEngine::getInstance()->pauseBackgroundMusic();
}

// this function will be called when the app is active again
void AppDelegate::applicationWillEnterForeground() {
    Director::getInstance()->startAnimation();

    // if you use SimpleAudioEngine, it must resume here
    // SimpleAudioEngine::getInstance()->resumeBackgroundMusic();
}

The background image 1280x960.

The result when the SR is 1280x720. That is not what I need.

What am I trying to say?
One might think that 1280x720 is the correct size of the background image and 1280x720 is the correct RR.
Let’s see.

The background image 1280x720.

The result when the SR is 1280x720.

The result when the SR is 1280x960. Still ok.

The result when the SR is 1280x720 and there is a navigation bar.

I have a black border.
Because the aspect ratio of the available part of the screen is 1,975308641975309 > 16/9 = 1,777777777777778.
So 16/9 is not an extreme case.

catch_up · August 18, 2016, 2:24am

Why wrong? I think, we can test. Isn’t?

As far as I know, and I think you would agree that neither engine nor you won’t be using 960 of this bcoz it’s FIXED_HEIGHT policy. Just 1280 is needed. Also, you’re not using this mediumResolutionSize anywhere in the code, so fine, no problem.

I like how you made your background image to test

After seeing your images and you results, I just realized that I told your wrong about it in my previous post. I did notice that you asked about landscape but while I telling I had portrait mode in mind.

So, here you go. See this image,

I am assuming for now, that 1.77 is extreme case. BUT since my “game mode” is FIXED_HEIGHT policy, I would start drawing my graphics from 960x720 out to 1280x720 where important things I’ll be keeping inside 960x720. But my final image size would be 1280x720.

So, RR should be 1280x720 and DR should be 960x720(because it’s FIXED_HEIGHT landscape game
and we started drawing graphics inside out.) And our main game is inside 960x720.

I just scrolled and found that you already figured out things a bit.

Yes, for 1.777 resolution, navigation bar further increases boundaries of extreme case which is now no more 16:9 for this scenario. Now, I realize what you were saying for lanscape + navigation bar.
Mostly, you should be hiding navigation bar or how I handle is that I don’t mainly care whether navigation bar is there or not, I just design my game according to (16:9) or (4:3) which is extreme case I could find on Android website and I do this:

I always keep extra spaces(unknownly calculated but I can keep it to 100-250 pixels for safe side, I guess). Since my side 720 height wise is always shown, so I keep expanding outside starting from 960x720.

catch_up · August 18, 2016, 2:39am

Just extra cases, I made.

Even though your game is Landscape, but you’re following FIXED_HEIGHT policy according to your game type.

Game which are LANDSCAPE but have zooming in or zooming out effect is there (like Hill Climb) they can follow FIXED_WIDTH approach, where they design background size as 1280x960 keep RR as 1280x720.

And now they can easily zoom. But some might say that height wise it’s fine but width wise black border would come! No, it won’t because I am assuming that your scenario is like this.
Which means atleast 3 background of Height size 960 are stitched and your

If zooming in/out effect is not much then you can reduce 1280 to say some AWIDTH where,
AWIDTH3 is not much larger than 1280, it can be say 12802 times or say 1280*1.5 times.
Safe side is 2 times(which is 2 backgrounds). 1.5 times, you can keep for games where background shakes on collision and you know the offset won’t be high.

For cases where zooming out effect is too much, then I guess 2.5x is safe side.

NOW CALCULATIONS
By 3 times, I mean, your 3 stitched background should be 1280x3/3 = 1280px each (1280x960)
By 2 times, I mean, your 3 stitched background should be 1280x2/3 = px each
By 1.5 times, I mean, your 3 stitched bg should be 1280x1.5/3 = 640px each (640x960)

Note, that 3 stitched are not compulsory but are safe depending upon your game type! The same effect your can achieve in 2 stitched backgrounds also but then set your offsets of each background correctly. I mean, then your game should be as below, where blue area is the screen area.

Now, you would say that you can’t zoom out in extreme case where Screen res(SR) is 1280x960 as black borders will start appearing on the top and bottom. Obviously, I explained just the concept, in actual implementation be sure, to extend your actual resolution for the extreme case beyond 960, depending upon zoom level.

This above concept is only for the games where the back most background is static.

In cases like left/right scrolling games, like in flappy birds we always keep 2 backgrounds, here we need to keep 2 sets of 3(or 2) stitched background.

But that is not ideal case because you can’t maintain total 6(if 3 stitched) backgrounds, both code wise and memory wise. So, in such cases, total of 3 backgrounds or 4 backgrounds are enough depending upon zoom out level. Just calculate correctly. If you don’t want 4 background then safe side keep “2 times” or 2.5 times as I told in above CALCULATIONS

I hope, this is clear.