(Updated: v3.13.1 update released) Cocos2d-x v3.13 released!

I’ve get, why may drawed things remain the same, but all sprites reduced about twice:
glview->setDesignResolutionSize() and director->setContentScaleFactor() in “AppDelegate.cpp” should be all commented - in my case of project.

Also as I get, v.3.13.1 is less safety than 3.10 (for me):

  1. You can’t do anymore things like:
    SomeClass * p = 0; SomeClass * p2 = 0; p->someFunction( p2 ); // - looks like it was ok in v.3.10
  2. Even empty project has ~20% chance to crash at start - it’s unacceptable, please fix that.

Why can’t you?

Can you back this up more? I am not seeing this.

@oponsinet

I am sorry, I can not help you since I use a visual studio only for win32 projects.

Why do not you want to use eclipse or android studio?

Also be careful with android-23 version.

@serpri

What android version are you using for compile? What android version of your device?

Thank you for your message Magniffect.

I want to use VS 2015 because it’s the IDE I use most (and so I’m efficient with it… I hope :joy:)… And I think it’s very confortable to be able to debug Win32, Win10 and android from the same IDE.

And you must know that yesterday I find a solution : finally I tried to build with android-19 API (since it’s the minimum actual target for a game) : and with android-19 API, the errors with the VS 2015 project was that these functions – getpwuid_r, signal, tcsetattr, tcgetattr – seems to be not implemented in android API-19 ! And these functions are used by the new libcurl and libcrypto prebuilt for android in the cocos2d-x 3.13 release, so the linker failed when it search for these function and it caused some undefined references errors.

And the only solution I found is to temporary (or not if nobody find a better solution), use the whole cocos2d-x 3.13 version, but with these 2 libraries android prebuilt files of the cocos2d-x 3.12 version (on 3.12 the VS android solution worked, and so it means these 2 libraries did not use the unreferenced functions).

And this solution worked, I’m now able to compile and debug the android version of my game on my phone with VS 2015… YES :grin::fireworks:

If somebody wants to have some details on my adventures you can take a look here : https://blogs.msdn.microsoft.com/vcblog/2016/07/12/cocos2d-x-visual-studio-android-project/

Thanks a lot for all comments and help :sunglasses:

2 Likes

I am glad that you have found the solution, and thanks for sharing. :sunny:

How can I check that fo sure?
Trying to create and use “prebuilt”, I’ve change “project.properties”:
# Project target. target=android-19 # it was target=android-10

Upd: So, to compile I use
C:\Develop\some_game>cocos compile -p android --ap android-19

Device android version is 4.4.2

@slackmoehrle I will check that once more, but my app begun to crash and stopped (to crash), after I added (normal for old-school C) checks like:
if (p_Node && p_Sprite) p_Node->addChold( p_Sprite );

Also I admit empty project app begun to freeze on my device when built with 3.13 or 3.13.1 - the same begun to happen in 3.10 only after I tried to force app to go to full_screen. I will check that once more.
That happen on android 4.4.2 device. On android 2.3.6 device - all ok, no freeze, so I decided it’s problem in new SDK switch; for 3.10 I used something like that:
if(android.os.Build.VERSION.SDK_INT >= 19) glSurfaceView.setSystemUiVisibility( 0 | Cocos2dxGLSurfaceView.SYSTEM_UI_FLAG_FULLSCREEN//ok | Cocos2dxGLSurfaceView.SYSTEM_UI_FLAG_HIDE_NAVIGATION // this may freeze the device | Cocos2dxGLSurfaceView.SYSTEM_UI_FLAG_LOW_PROFILE | Cocos2dxGLSurfaceView.SYSTEM_UI_FLAG_IMMERSIVE_STICKY//ok | Cocos2dxGLSurfaceView.SYSTEM_UI_FLAG_IMMERSIVE | Cocos2dxGLSurfaceView.SYSTEM_UI_FLAG_LAYOUT_FULLSCREEN//ok | Cocos2dxGLSurfaceView.SYSTEM_UI_FLAG_LAYOUT_HIDE_NAVIGATION//ok?????????? | Cocos2dxGLSurfaceView.SYSTEM_UI_FLAG_LAYOUT_STABLE //ok );

Another new problem - using “cocos run …” may freeze my device, so I avoid that freeze by using “cocos compile”. After compile I install apk on device manually, and it may run ok or prompt nicely something like “error in Application” - depending on bugs in my code.

Upd: I apologize, at now I can not reproduce device freeze with empty new project; but my app make device freeze sometimes.
Upd-2: I modified new empty project, and few times I get device freeze… Trying to find out what affects it.
Upd-3: Label * label0 = 0; this->addChild(label0, 40); // in HelloWorld::init() freezes the device; going to find other reasons.

so you are saying if I make a stock cocos new ... and add a Label just how you did, it will freeze my device?

The same “a1-debug.apk” has to output 3 Labels and 4-th Label is null, I add it (like others) to Scene:

  • on GT-I9003 Android 2.3.6 device - no output, no crash, app closes itself after ~45-15 seconds; or pressing Home - OS is working properly after that.
  • on Android 4.4.2 device - black screen, device freeze, restarting after ~45 seconds.
  • on GT-I9301I Android 4.4.2 device - no output, no crash, app closes itself after ~5 seconds with prompt “Unfortunately, a1 has stopped”; OS is working properly after that.

Update: I used command cocos compile -p android --ap android-19 (with v.3.13.1)
Next going to do same with v.3.12

Can you post your class where you do this so I can just drop it into a coocs new ..?

Classes.zip (4.9 KB) - Here they are - default but modified a bit: removed setContentScaleFactor and GLViewImpl::create() used instead of GLViewImpl::createWithRect().

Update: with same command cocos compile -p android --ap android-19 (with v.3.12):

  • on GT-I9003 Android 2.3.6 device - no output, no crash, app closes itself after ~15 seconds;
  • on Android 4.4.2 device - no output, no crash, app closes itself after ~5 seconds with prompt;
  • on GT-I9301I Android 4.4.2 device - no output, no crash, app closes itself after ~5 seconds with prompt;

Upd: http://discuss.cocos2d-x.org:/uploads/default/original/2X/4/4ada1834c1f7da8be401b4723909ee4f2ee81e74.mov - here is “cocos v.3.12” compiled with “–ap android-19” apk (renamed as ‘mov’) - it starts ok and closes nicely on all my devices.
http://discuss.cocos2d-x.org:/uploads/default/original/2X/c/cfba03c0d1bf2aa406d593760a9a5b7f3f2b2c8f.mov - here is “a1-debug.apk” - “cocos v.3.13.1” compiled with “–ap android-19” apk - it freezes my ARIES_101v2 device.
—update: I really wander, is there any other device which freeze from this apk?

appreciate it.

14 posts were split to a new topic: V3.13.1 and Design Resolution issues

Hello. Once more about my troubles:

I tested the following “bad” code. When built with 3.13.1 with commands
cocos compile -p android or cocos compile -p android --ap android-19

  • it freeze my device ARIES_101v2 on Android 4.4.2. Device is not rooted; “developer option” is turned on.

“null->” and “->null” code examples nicely close the app on most devices, but at ARIES_101v2 - they freezes the device.

At very first start (after install or device restart) “while-1” and “for-50M” code examples works fine, but at the second start - they freezes the device at once.

Code examples:
I create the new empty project, and add the “bad” code just after
bool HelloWorld::init() { if ( !Layer::init() ) { return false; }

the “bad code” lines (I tried them by one - not all together):

Label * label0 = 0; this->addChild(label0, 40); // closes the app on others devices, but on this - freeze the whole device == Android OS at first start;

Label * label0 = 0; label0->setVisible(1); // closes the app on others devices, but on this - freeze the whole device == Android OS at first start;

for (int t = 1; t < 50; t++) for (int r = 1; r < 1000000; r++) int eee=5; // 50 millions cycle - starts nicely, but at second start it freezes the whole device == Android OS at second start;

while (1); // always loop - freeze the app (it's ok); but at second start it freezes the whole device == Android OS;


On same ARIES_101v2 I’ve tested “null->null” code examples, compiled with 3.10 - they nicely stops the app and do not freeze the device.
Going to test them with cocos SDK 3.11.

I don’t think it is reasonable to expect either Cocos2dx or Android to continue working fine after passing in null values.

This is not a bug or a problem. In my opinion it is expected behavior to get unexpected behavior when we pass invalid parameters.

Neither cocos2dx, or the graphics drivers, or Android can check for null everywhere or cases like invalid typecasts or invalid texture ids etc… In theory it might be possible, but practically is not possible to verify everything and even if it was, there is no benefit of doing it.

On most devices “null->” and “->null” code examples nicely close the app. I agree it is expected behavior.
But on ARIES_101v2, the same code:

  • built with 3.10 - nicely close the app;
  • built with 3.13.1 - freezes the device. I think it almost impossible situation for Android OS, and not allowed situation for Cocos SDK.

I have tested all 4 versions of “bad code” with cocos 3.11.1 version: it runs not in full-screen, navigation bar is visible, so the app runs/stops/prompts about the error in app nicely, without freezing whole Android OS on my ARIES_101v2 device.

App created with Cocos v. 3.12+ runs in full screen (hiding navigation bar), so in “bad code” version the Cocos app freezes one of my device.

Cocos Developers, please fix that, please make Cocos to run the application in full screen properly (on any device). Thank you. Any questions are welcomed.

Also when I use cocos run -p android - it works fine with v.3.10-11, and looks like it freeze that device every second run, if built with v.3.12+ …if runned application is not active.

Aha… Looks like I’ve found back-door solution.
My code problem was: I had a cycle in bool HelloWorld::init():
for( 13 times) a_block_to_create_a_button; Due to some reasons it freezes the Aries device when app started the second time; even after it was changed to:
for( 50 millions times) int temp_var=0;

My solution: to move that code from bool HelloWorld::init() to a separate function, and call it later, after exit from init():

m_bl_init_done = 0; // class variable;
this->schedule(schedule_selector(HelloWorld::f_animation), 0); // function for animation drawing; called so often as possible;
return true; // and we should exit ASAP from HelloWorld::init();

then:

void HelloWorld::f_animation(float dt)
{
    if (0 == m_bl_init_done)
    {
        m_bl_init_done = 1;
        f_init(); // at this point it is safety to call long time taking initialization functions;
    }
}

At laaast! My app release mode start-up time:
Built with 3.10: ~3 sec.
Built with 3.13.1: ~4 sec; but in full-screen mode.
Had anyone made the same comparisons?

Hello,
First of all, thank you for the update !
However, I still find the new AudioEngine to be extremely slow.
Just using it drops my frame rate from 40 fps to about 15 fps…
What are the exact requirements to have no performance hits hen usign the new audio engine ?
I am using cocos v3.13, my device is running android v4.1.2 and I call AudioENgine::preload() for each sound I use at the start of the app.

Thank you !

What about to use SimpleAudioEngine::preloadEffect() ?