Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

enabled content scale mode and support for variable screen aspect ratio on android #538

Closed
wants to merge 2 commits into from

Conversation

ChristianFischer
Copy link

Changes:

  • allowed content scale for android
  • changed CCFileUtils::fullPathFromRelativePath & fullPathFromRelativeFile to load -hd files
  • added a flag to CCEGLView::create to allow to override the selected resolution, to fit the current device's screen size

@minggo
Copy link
Contributor

minggo commented Oct 8, 2011

I don't understand the modification of CCEGLView_android.cpp.
Could you explain it more detail?

@ChristianFischer
Copy link
Author

Sure

Usually you create a view with view->create(320, 480);
On iPhone with a 640x960 screen size you get a "virtual" screen size of 320x480 on the physical 640x960 pixels with a scale value of 2.
On android, for example, you have a display with 480x800 pixels, so the view-class would create a viewport of 480x720 pixels, which uses a scale value of 1.5. Unfortunately, the missing pixels on both borders are just black.
I've added an additional parameter to CCEGLView::create, "auto_adjust". If this parameter is true, it will use the full physical pixels to create the viewport and increase the size of the virtual resolution, So, on this device, you get a virtual display size of 533x320 points (instead of 480x320) on the full 800x480 screen, without any borders.
This also works on honeycomb devices, where you cannot use the whole display because of the additional bar on the screen bottom.

The other changes just enables the ability to use HD images and removed the override of m_fScreenScaleFactor. I'm not sure, what should happen, if you're changing the content scale factor on runtime, but m_fScreenScaleFactor should be changed only, if the "virtual" screen size would change, not when changing the content scale.

@minggo
Copy link
Contributor

minggo commented Oct 9, 2011

I think you can not do it.
Because there is only one scale factor, x and y should have the same scale factor.
If we want to have different scale factor of x and y, we should do more work.

For example, CCDirector::getWinSizeInPixels() should use the scale factor.

@ChristianFischer
Copy link
Author

X and Y have the same scale factor. The only thing, i'm changing is the virtual screen resolution, the part which is measured in points.
On my example above, the (adjusted) virtual screen size of 533x480 points to the physical resolution of 800x480 is a factor of 1.5 on both x and y size.

@ChristianFischer
Copy link
Author

What's the current state with this patch?

Do you need further explanations or changes on the code, or are you just busy?

As explained above, I do not use different scaling values for X and Y (which would result in an ugly, stretched image). I just extend either width or height of the size given to view->create to fill the whole screen, instead of leaving blank bars on the side.

@minggo
Copy link
Contributor

minggo commented Oct 19, 2011

We are releasing a new version, so I am too busy to test these codes. Does touch coordinate correct by your change?

@yangws
Copy link
Contributor

yangws commented Oct 19, 2011

Thanks for ChristianFischer submits codes to us.
On the android platform, the various resolution of the screen made developers having a headache.
There's two problem for adapter different resolution of the screen:

  1. Can we deal the different width/height rate screen as same way?
    If we want keep the w/h rate on different screen, the effect is either keep the edge of screen black or the edge of image out of screen. For the purpose that writing code once, running every device, we choose the first solution for cocos2d-x engine to deal the problem. If we choose the second solution, developers must maintain many ui design for the application. The codes which you submited has the same problem, isn't it?

  2. Can we pack the different resource for different resolution?
    On the ios platform, the retina display as twice as the iphone 3's resolution, the developer maintain two pack of resource is enough. But on the android the resolution is so many, such as 320x480, 800x480, 854x480, etc. Design a pack of resource for every resolution is not acceptable. So we scale one pack of resource for all resolution, the "-hd" mechanism is only works on ios.

    Is there no way to show image full screen on different andorid devices?
    You solution is good one, but isn't the common way. We hope there's a more common and more convenience way to deal the problem, then make develpers coding easier for different resolution on android.

Is it acceptable that scale the origin image to full screen which don't keep w/h rate?

@ChristianFischer
Copy link
Author

Hi,

touch coordinates are working fine with the changes. I've tested the changes also on a honeycomb device with it's additional softkey-bar and it looks good, too. (maybe I should get a few more honeycombs to be sure it works on all of them).

@yangws:
Sure, with my patch, you're changing the aspect ratio from 1.5 to the device's original aspect ratio. You have to handle it in the same way, as you would handle it in a native android application. Depending on your UI, this would be more or less difficult. If your UI is just a life-bar in the upper left corner, and a score in the bottom right corner and you're using screen with and height as reference point instead of hardcoded offsets, you don't have to change anything.

If your UI contains borders, fullscreen background images, or something like this, you have to care about the screen size. We're using tiled background images for some UI backgrounds (streched images may also work in some situations, but may be ugly in other situations)

Scaling the image to fullscreen on all devices should be a no-go. Try to scale a screenshot of your game to 854x480 (xpera-play display size). The result won't make you happy

My patch also enables the HD-mode on android. So you can use your -hd images on android in the same way as on IOS.

@minggo
Copy link
Contributor

minggo commented Oct 20, 2011

Ok, I will test it and merge it in next version if it work ok. Then I hope you can write a document to describe it in the wiki.
Giving examples is better.

@Lucretia
Copy link

I applied your patches to my code manually, I just get a black screen and a hang.

This does this on a Galaxy S and also the HVGA emulator.

@minggo
Copy link
Contributor

minggo commented Oct 22, 2011

Thank you for your testing.

@ChristianFischer
Copy link
Author

Hi, please add a "view->create(480, 320, true);" to your android main.cpp (or uncomment the existing one, if it's still there).

If you still have problems, plase check if the HelloWorld example in your cocos2dx version is working.
Which cocos2dx version did you applied the patch? It works with the latest release version. The previous release version is a bit different, so the patch wouldn't work.

@minggo
Copy link
Contributor

minggo commented Nov 2, 2011

If you want to a full screen, you don't need to invoke CCEGLView::create(). This function is used for scale the screen.

@moadib
Copy link
Contributor

moadib commented Dec 5, 2011

I'm use same approach, call view->create(480, 320), and for physical resolutions other than 480x320 enable retina (so content_scale = 2.0, and cocos2d with additions for FileUtils loads hd-resources).

In your FileUtils additions code not totally correct, condition

if (std::string::npos != dotPos && dotPos > pos)

Check it, for "texture.png" returns "texture.png-hd".

@ChristianFischer
Copy link
Author

should be fixed now (the bug just happened on files in "assets", not on files in any subdirectories)

@gwennguihal
Copy link

Works fine for me. Thanks !

@minggo minggo closed this Aug 3, 2012
angeltown pushed a commit to angeltown/cocos2d-x that referenced this pull request Apr 28, 2014
angeltown pushed a commit to angeltown/cocos2d-x that referenced this pull request Apr 28, 2014
angeltown pushed a commit to angeltown/cocos2d-x that referenced this pull request Apr 28, 2014
[iOS] fixed cocos2d#538: add template of lua for xcode3
angeltown pushed a commit to angeltown/cocos2d-x that referenced this pull request Apr 28, 2014
angeltown pushed a commit to angeltown/cocos2d-x that referenced this pull request Apr 29, 2014
angeltown pushed a commit to angeltown/cocos2d-x that referenced this pull request Apr 29, 2014
angeltown pushed a commit to angeltown/cocos2d-x that referenced this pull request Apr 29, 2014
[iOS] fixed cocos2d#538: add template of lua for xcode3
angeltown pushed a commit to angeltown/cocos2d-x that referenced this pull request Apr 29, 2014
walzer pushed a commit that referenced this pull request May 4, 2014
minggo added a commit that referenced this pull request May 4, 2014
minggo added a commit that referenced this pull request May 4, 2014
[iOS] fixed #538: add template of lua for xcode3
walzer pushed a commit that referenced this pull request May 4, 2014
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

6 participants