... instead of sharedXXX / purgeXXX.
They are more C++ friendly, and also easier to remember.
common files + Mac files + iOS files + tests/samples files were updated.
The old methods are deprecated now.
1. Pitch/pan/gain support on iOS, Mac, Linux+FMOD, Android+SoundPool;
2. Unified OpenAL code with pitch/pan/gain on Linux, Tizen, Blackberry,
Native Client;
3. Bug fixed: rewindBackgroundMusic() no longer stops music on unified
OpenAL engine.
4. Optional mp3 support for Linux+OpenAL (OPENAL_MP3 make option);
5. Pan/gain (not pitch) support for Android+OpenES.
6. Reorganized CocosDenshion tests in TestCpp.
Known issues:
1. No support for windows, emscrippten, marmalade.
2. No pitch effect on Android+OpenES. It requires backend redesign:
http://code.google.com/p/android/issues/detail?id=24592
we should use onWindowFocusChanged(bool) to detect if the app is currently
visitible to the user or not. because onPause()/onResume() leads to false
positives on some android versions (e.g. Kindle Fire). if you lock those
devices, while the app running, everything is fine (onPause() is handled
properly). but as soon as you wake up the device, and the lock screen gets
visible, the app is resumed and the music is played (onResume() is
called to early).
this is a) not the best behaviour and b) such games will be rejected on the
samsung app store. onWindowFocusChanged(bool) is, like onPause()/onResume(),
available since API level 1 and it should be safe to simply switch.
1: Use the CCFileUtils::fullPathForFilename function to lookup the resolved path for the font in the Android specific function, CCImage::getBitmapFromJava.
2: Remove a warning previously added in pull request 2422 (https://github.com/cocos2d/cocos2d-x/pull/2422) in CCFileUtils::fullPathForFilename in order to support change (1) above. If we pass just a system font name to CCFileUtils::fullPathForFilename such as 'Arial' (instead of a path) then it should just return 'Arial' and not generate a warning. We can't assume that when a path (or handle) given to CCFileUtils::fullPathForFilename isn't found within Cocos2dx that it doesn't exist or isn't valid. Depending on the platform there might be files or folders or handles that could be accessible to the app which might exist outside of the knowledge of Cocos2dx. The correct place to warn about missing resource files would be at the point where the resource loading itself fails; e.g if a texture or sound fails to load for example.
minggo