and other best pracitces like:
capacity and "index" are ints and not unsigned int (google's recomendation).
It is easier to detect underflow bugs like this
plus other minor improvements
... 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: 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.
fixed#2127: Adding CCLOG before original path is returned in CCFileUtils::fullPathForFileName to aid in debugging.
The PR has fix two issues:
1) Added additional CCLOG to CCFileUtils::fullPathForFilename:
There's currently no way to be sure, from a calling function, that
fullPathForFilename has returned an invalid file path, which makes it
difficult to quickly track down missing, or incorrect file paths. Added
a CCLOG before the original string is returned to make debugging
missing or incorrect file paths easier.
2) Optmization to ccArrayGetIndexOfObject …
Optimized loop of ccArrayGetIndexOfObject to remove the overhead of 3
pointer dereferences per iteration, and pre-increment the int for
speed. If this function is called a lot, and with a large list, this
will result in a good performance win.
This can probably be done with just pointers, but I haven't taken the
time to validate all function calls to make sure it would be
appropriate. Though I can guarantee that if this worked fine before, it
will work fine with this change.
There's currently no way to be sure, from a calling function, that
fullPathForFilename has returned an invalid file path, which makes it
difficult to quickly track down missing, or incorrect file paths. Added
a CCLOG before the original string is returned to make debugging
missing or incorrect file paths easier.
When calling 'CCFileUtils::createCCDictionaryWithContentsOfFile' and 'CCFileUtils::createCCArrayWithContentsOfFile' on iOS/OSX these functions call upon 'CCFileUtils::fullPathForFilename' to resolve the path given into a full path which can be used with system file IO functions. This matches the convention found throughout the cocos2dx library and is expected behaviour. However, on Android and other platforms it appears calling 'CCFileUtils::createCCDictionaryWithContentsOfFile' or 'CCFileUtils:: createCCArrayWithContentsOfFile' does not do the same resolution using 'CCFileUtils::fullPathForFilename' - resulting in file paths which are correctly specified (and which worked on iOS/OSX) to fail to load on these platforms.
Fix this issue by performing a lookup/resolve of the file path using 'CCFileUtils::fullPathForFilename' before doing the low level loading work itself. This brings the behaviour of other platforms in line with iOS and OSX.
with four spaces. Also,
1. Used macro NS_CC_BEGIN instead of namespace cocos2d {, NS_CC_END instead
of }.
2. Removed some unused files.
3. Renamed the name of some folders, for example,
"test.android"-->"proj.android" .
Ricardo Quesada