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

@Magniffect

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

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 :stuck_out_tongue: .

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. :smile:

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? :stuck_out_tongue:

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.

But you use NO_BORDER.
And I do not understand you. :frowning: 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.

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.

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.

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. :smile:

1 Like

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 :smiley: :smiley:

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.

:slight_smile:

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. :stuck_out_tongue:

I was wrong when I said that you need to take care of _window_title_height.

I use it here

And 960 is the height for the landscape. :smile:

It is good, but in some cases a navigation bar will affect the size of the safe area.

Oops. I meant mediumResolutionSize.width you’re not using anywhere :stuck_out_tongue:

Now, it won’t be used anymore as per the background image resolutions I wrote in last to last post…

Yes, I can use FIXIT_WIDTH. But I have the square area in the center of my layout and I would like to use as much space as I can for it.

But it is still the height! :slight_smile:

Now the topic is more like a chat … haha

Agree. But it works only when the background images may be stitched.
… Although if you have a designer you can always adjust the art under the requirements of the project.

p.s
How do you think maybe it will be better to rename the topic? There are 24 posts here, but no one else joined the conversation. :cry:

Yeah correct. It depends upon game type :stuck_out_tongue:

Haha no problem :smiley: What shall I name :smiley:
Some cool like “[Chat]MSR Demystified” :smiley: :smiley:

1 Like

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! :smiley:
I didn’t got any mistake.

Thanks for the kind words!

Now you can add the tag “off topic” :smile: :smile:

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 :stuck_out_tongue:

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