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.
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() ?
The SimpleAudioEngine can only play one effect at a time, while in my game there can be several at the same time, thats why I switched to the new audio engine
Hm… in c++ I play few mp3 at the same time; mainly with different start time; but they sound the same time. Cocos SDK versions 3.10 - 3.13.1.
Dear all,
I have a problem with SimpleAudioEngine in V3.13.1, but I don’t know if it is specific to this new version of cocos2d-x : my problem is very simple : the stopEffect method don’t work on android with one of my audio files : I thought it was due to the file type (mp3), but I tried with an ogg version of the same file and I got the same result : stopEffect has no effect on android !
Does somebody saw this problem ?
Or simply knows what I’m doing wrong ?
For information, my file stream has these characteristics : 320 kbps, 2 channels, 48000 Hz, Stereo.
Thanks,
Olivier.
Hey @oponsinet ,
Sorry about the work that you were going through getting VS and the new version of Cocos2d-x to work. I wanted to hit it earlier, but stuff has been a bit busy here at MS with a big Preview release and cppcon. Here is a version of the VS proj.VisualStudio project that should work with 3.13.1. I tested it out launching and debugging in ARM | Debug and ARM | Release configurations on my device. With this you should not have to tweak API levels at all or copy around old curl versions.
https://aka.ms/vscocosandroidsample3_13_1
I’ll update the VS android thread here as well with this link and more info. And I’ve already updated the main blogs.msdn.com blog post to have both the 3.13.1 and 3.12 versions available.
BTW. I’m asking around here as well about the VS LogCat window issue that you mentioned.
1 Like
Many thanks IanHu, I will compare with my android projects to see if there are some differences 
Dear all,
Finally I can explain my sound problem ! And there is no real problem on android, there is only a behaviour difference between Win32 and Android plateform with audio play / stop management : in fact, in my code, the sound effect I thought it can not be stopped were launched 2 times in 2 places in my code 
… And on Win32 plateform, I think that if a sound effect is already playing, it is not launched a second time, but not on android ! So on Win32 all was working as if I did not launched this sound 2 times, but not on android : that’s why I thought there was an android problem !!
Many excuses if somebody tried to analyze my problem 
!
But now I (and so we if somebody read my message 
) learned that there is this behaviuor difference with sound effects between Win32 and android plateform !!
See yaa !
Olivier.
1 Like