contentScaleFactor not working correctly

contentScaleFactor not working correctly
0.0 0

#36

@Priority10 thanks, i believe you, of course :slight_smile:


#37

Yes this was wrong usage.

I used the above mentioned code with my Utils.cpp. And it worked.


#38

Which block of code? You mean the whole setContentScaleFactor block of original AppDelegate.cpp or my last 2 lines which I commented out?


#39

No need to test my Test Cases now. It was wrong usage. I think we both were on same step i.e did not get the proper idea of multi res with designResiolution. Now it’s clear for me. :slight_smile:


#40

No actually.

This is not true. I was testing with this, but it did not help me since this code treated my screen size as 1280 * 720 on both devices.

But in Utils.cpp, I am just using it for my scaling purpose. It is not setting my screen size to 1280 * 720 since I used

Read this, (Small calculation related reply with only one snap after Test Case 4)

This actually helped me a lot to understand.


#41

I meant your whole code block.
And in fact the original code too (my opinion about the original code I wrote here).

If setDesignResolutionSize() has never been called, then the default design resolution is equal to the frame size. And since the design resolution is equal to the frame size, ResolutionPolicy has no effect.

It will always be equal to 1. Because

And contentScaleFactor is equal to 1 by default.


#42

Yes, I put it incorrectly. While
director->setContentScaleFactor(MAX(glview->getFrameSize().width/1280.0f, glview->getFrameSize().height/720.0f));
is the equivalent of your code,

glview->setDesignResolutionSize(1280.0f, 720.0f, ResolutionPolicy::NO_BORDER);
will give you a similar result, but not the full equivalent.

What is the difference?
In the first case, your design resolution is equal to the frame size, ie your coordinate system is equal to the frame size.
On the bright side, you do not need to worry that part of the design resolution will not be visible.

In the second case, the engine will keep your coordinate system equal to the design resolution, and will scale your layout according to ResolutionPolicy.
On the bright side, you do not need to worry about different coordinate systems.
But you need to worry that part of the design resolution will not be visible, and you will need to use getVisibleSize() and getVisibleOrigin(). Because NO_BORDER.

About your case 4, then I believe that the problem is because you use setDesignResolutionSize() and setContentScaleFactor() together.


#43

ResolutionPolicy has effect here in my case. As you can see for 480 * 800 data below,

dpi = 240
Content Scale Factor: 1.000000
FrameSize HW: 480.000000 800.000000
CustUtils: screenHeight, screenWidth: 480.000000, 800.000000
CustUtils: designScreenHeight, designScreenWidth: 720.000000, 1280.000000 (This is I am setting in CustUtils.cpp, Not glview->setDesignResolutionSize(frameSize.width, frameSize.height, ResolutionPolicy::NO_BORDER):wink:
CustUtils: scaleX, scaleY: 1.000000, 0.666667
Bounding HW= 480.000000 853.333374
Image HW= 720.000000 1280.000000

Here by default image size is , 1280 * 720 but getting scaled. After scaling image size is 853 * 480. Since 853 > 800, image is getting cropped width wise.

Though contentScaleFactor is by default 1, but since my previous designResolution was 1280 * 720, it was not working correctly. Do not get confused by glview->setDesignResolutionSize(frameSize.width, frameSize.height, ResolutionPolicy::NO_BORDER); with mu CustUtils.cpp designResolution HW.

Whatever is happening right now is the thing I wanted to achieve. :slight_smile:


#44

Yes. That is being used in SplashScreen.cpp.

The more I start developing, I will find out more. Will keep you updated.


#45

I meant that if you never called setDesignResolutionSize(), then your design resolution is equal to the frame size and ResolutionPolicy = NO_POLICY.
And if you use glview->setDesignResolutionSize(frameSize.width, frameSize.height, ResolutionPolicy::NO_BORDER), then even though you specified a policy, it is like you did not specify anything in the end. The result is the same.

In the end, you can delete that block of code, nothing will change. :slight_smile:


#46

No Border - “The entire application fills the specified area, without distortion but possibly with some cropping, while maintaining the original aspect ratio of the application.”

As you can see in my case -

  • Application is filling the specified area.
  • Cropping is happening.
  • Original AR is being maintained.

#47

Where did you get this quote?

We’re talking about Case 4, right?

By the way, I really like how you write your posts - in detail and with screenshots.


#48

Go to - http://www.cocos2d-x.org/wiki/Multi_resolution_support#No-border

No no. All my Test Cases are invalid because of wrong use. I have not posted the successful ones except one. Check

Big Thanks. :smiley:


#49

The quote is not true.

NO_BORDER - The design resolution will be scaled to fit into the screen size (the frame size), and there will be no distortions, and there will be no black borders, but perhaps a part of the design resolution will not be visible (if the aspect ratio of the design resolution is not equal to the aspect ratio of the frame).


#50

This is what I said

It’s also saying the same thing from http://www.cocos2d-x.org/wiki/Detailed_explanation_of_Cocos2d-x_Multi-resolution_adaptation-

According to the width and height of screen and design resolution to determine the scale factor, choose the larger one as the scale factor. This can make sure that one axis can always fully display on screen, but another may scale out of the screen.

Same same I think. And that is happening for my case. Look at this - Multi-resolution code in the default template


#51

The application and design resolution are different things. If you use NO_BORDER and use setContentScaleFactor() incorrectly, then you can get both black borders and the wrong scale.
ResolutionPolicy only works with a design resolution.

Yes, I read your post in other topic in parallel.
But now my mind is too tired and wants to sleep. I will read it carefully tomorrow, okay?


#52

We will add to our docs a lot of info from this thread. How would you all feel about proof-reading a draft once complete? I’ll be working on this over the next few days.


#53

No probs. :slight_smile:


#54

That would be great. Must add snaps for better understanding with some real time data. :slight_smile:


#55

of course, graphics are very helpful to understanding.