Cool!
“[Solved?] MRS. Three simple words and a big big discussion. Warning! Lots of text, lots of images! Magniffect’s bad English.”
More seriously, I would mention at least the “Multi-resolution”.
Not really! 
I didn’t got any mistake.
Thanks for the kind words!
Now you can add the tag “off topic” 
I think it’s related to this cocos2d-x topic as the code is given and is directly related to the cocos2d-x C++ even though C++ is not tagged as mostly concepts are discussed. What I feel is that, it’s good for it to be here unless moderator feels it to be changed… Pretty sure this discussion will help others.
It is just a joke. Because we were not serious when discussing how to name the topic and English. (Despite the fact that I really believe that my level of English is not good enough.)
But I think it is good to be not serious sometimes.
Oh… haha… I couldn’t figure it out 
hi folks, you have nice discussion, personally myself i used @Maxxx solution from there for my game Bang Russian Roulette
this solution works well for iOS and Android
Hi @camkadev
Glad to know that.
Just checked his solution. Will look into detail a bit later. Also, I downloaded your game, will try today night. How did you implement multiplayer(lobby)
Also, one thing. Maxxx solution has 5 kind of resolution folders. I want to avoid that bcoz. the overall size of app will increase unnecessarily and I don’t wish to do that.
In such scenarios it’s always best to publish app according to screen sizes…
@catch_up the multiplayer is made with native low level Sockets and it is crossplatform solution, here is example, it is made as i did in my project.
currently my server is down for a long time…
Thank you for the git repo. I’ll learn some concepts. I have very very less idea about how servers for game apps work
You can use my solution with fewer resources if you want to - you just need to decide which sizes you want to look perfect and which you’re happy to compromise on.
I just wrote the solution to provide what I think is as close to a ‘perfect’ solution as possible!
@Maxxx That’s a very nice reference document which you’ve come up with for multi resolution support.But for some of the devices,especially in android,the game UI will get cropped because of the design resolution set.
For all those who are struggling with Multi resolution support,
I’d just like to add on to the discussion here with my inputs on whatever I have learned in working with multi resolution support in cocos2d-x.
The design resolution is the most important in multi resolution support and should be set to the correct value for the game UI to look best.The resolution policy which is set while setting the design resolution is another important factor which determines how your game UI is rendered.
Depending on your game design,you could choose between EXACT_FIT,NO_BORDER,SHOW_ALL,FIXED_WIDTH and FIXED_HEIGHT policies.According to me,if you want to avoid any sort of cropping in your game UI you should use the NO_BORDER resolution policy.
To make your game UI compatible on all devices across multiple platforms(android/iOS/Windows),it’s very important to keep in mind the aspect ratio of the device you are targeting.You can have an asset for each of the aspect ratios which the platform supports and load the same.
The asset can be of a smaller dimension which can be scaled up based on the device resolution.I’ll give an example to demonstrate the above point.
Say I’m building a game targeting android and iOS platforms.On iOS there are fewer resolutions so it’s easy to manage loading of resources somehow.But in android,the number of resolutions are so many,that it’s difficult to choose the optimum design resolution.In this case,the resources can be loaded based on the device aspect ratio.Some of the aspect ratios found in android are-16:9,5:3,4:3,etc.
So in AppDelegate,the reference design resolution can be taken as-
Size referenceDesignResolution_16:9 = Size(640,360); // for 16:9
Size referenceDesignResolution_5:3 = Size(640,384); //for 5:3
and so on.
The aspect ratio is calculated as screenSize.width/screenSize.height.
The assets can be designed based on the above reference design resolution for each aspect ratio.Then set the design resolution of the glView as-
auto screenSize = glView->getFrameSize();
glView->setDesignResolution(screenSize.width,screenSize.height,ResolutionPolicy:NO_BORDER);
With the above approach if I have android device of resolution (2560x1440) and (1280,768) for instance,referenceDesignResolution_5:3 will be used for (1280x768) device and referenceDesignResolution_16:9 will be used for (2560,1440).The resource can then be scaled to fit the specific device by using a scaling factor calculated by -
auto scaleFactor = screenSize.width/designResolutionSize.width;
resource->setScale(scaleFactor);
The above approach can be used for iOS also.
Hello @Alwyn !
Nice post.
But I do not agree with the way you use setDesignResolutionSize().
The basic idea of Multi resolution support is to have one Design Resolution (DR).
The basic idea of ResolutionPolicy is how DR will be scalled to SR.
In your case, ResolutionPolicy has lost its meaning.
How about case aspect ratio of the screen is 16/9 + navigation bar?
Do you use Multi resolution support only for UI?
edited - added formatting
Hi @Magniffect the way you use Multi Resolution Support goes by how you have designed your game.There is no single approach to it.In my case the above approach which I described worked on both iOS and android.For iOS,the method which you said of having One Design Resolution worked,but not for android,there was lot of cropping.
For the case aspect ratio(16/9) + navigation bar which you have mentioned,the reference design resolution size will be Size(640,360-height of navigation bar).If,for example,I consider height of navigation bar is 44 pixels,the reference size will be Size(640,316).Similarly if I have aspect ratio(16/9) with tab bar at the bottom,the reference design resolution size will be Size(640,360 + height of tab bar)
I have described the approach for those who may have their game UI designed to utilise this approach.
Yeah, I agree that it depends on the app and on your preferences.
I just noticed that you mentioned NO_BORDER, and then use
But in this case you can use any ResolutionPolicy, nothing has changed.
This is equivalent to you do not specify the Design Resolution (DR).
It works on android.
There is one more important concept - the Safety Zone. It is a part of the DR that will be visible on any device.
How many referenceDesignResolutionS should be in AppDelegate?
How many resource folders you have for this?
Did you mean reference designResolutionSize? In your case, the width of each your referenceDesignResolution equal to each other.
Did you mean actual designResolutionSize? Then scaleFactor will be always equal to 1.
Sorry,that was a typo.It should have been-
auto scaleFactor = screenSize.width/referenceDesignResolutionSize_16:9.width;
OR
auto scaleFactor = screenSize.width/referenceDesignResolutionSize_5:3.width;
and so on.
The number of referenceDesignResolutions in AppDelegate will be equal to the number of aspect ratios which you want to support.Number of resource folders for background images will be equal to number of referenceDesignResolutions in AppDelegate since background image is loaded based on aspect ratio of the device.For other resources like icons,etc. you could load resources based on SD,MD,HD or UHD.
Yes,I agree.In this case there is no need to use setDesignResolutionSize at all.
I do not know about the Safety Zone concept mentioned above.What is that?In my case,I needed the entire DR to be visible on all android devices and not part of the DR.
But the width is 640 in both cases.
So many images, so much space.
This can be accurately calculated based on the chosen MRS policy.
Do you really need different UIs for different screen ratios?
See this
In this case the Safety Zone is 960x720.
In the next post, @catch_up explains it (for me?).
I am too lazy to explain it by myself. 
I will not write about the Multi resolution anymore. I will not write about the Multi resolution anymore…
If I say it enough, maybe I will believe it myself…
@Magniffect Multi Resolution concept is not quite easy to understand so says the experience of many cocos2d-x developers out there. There are also few developers who have very good and advanced knowledge about everything and who are very good at out-smarting what the beginner developers have shared and who try to show that their advanced knowledge is greater than amateur stuff shared by beginners.Well that’s how it always is.With experimenting and researching one can learn things quite well.
If I learn something else about Multi Resolution Support tomorrow I will definitely share it and I will write about it…it will definitely help someone.
I believe that this is a forum to give help and take help on any topic.Not to show who is smarter and who is not.
And finally thanks for all your wonderful explanations,justifications and comments on the topic.Great job.
I did not explain it by myself because he explained it already.
I believe that this topic has enough information to understand what is the safe zone. I do not want to repeat.
Then I tried to joke about the lazy. Unsuccessfully. Ok.
It was a joke too. Or not quite…
I know that this is a difficult concept. And I am glad to help. But it ends with a long discussion almost always.
I think that or I should write a big guide to stop incorrect understanding of this concept. Or ignore any topics about this.
I think that there is an easier way to show their “advanced” knowledge, instead of writing on this forum.
If my attempts to help are interpreted in this way, then it would be better for me to keep quiet.