For example RGBA4444 is 2 bytes per pixel. A texture with width of 1 passes the previous power of 2 test, but the alignment value needs to be 2, not 4.
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.
Updated the TextureAtlasEncryptionTest to show how to use the ccSetPvrEncryptionKey(…) function.
Updated the notes and header docs for improved clarity.
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.
carlo morgantini