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.
fixed#2030: Fixing a display bug when a scrollView nested in another scrollView. The parent's scissor rect need to be considered, when setting the scissor rect in the subScrollView.
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.
The character array which given to CCSAXParser::parse() may not be NULL
terminated.
Therefore we must also add the size of the data array to the parameter list
of the tinyxml2::XMLDocument::parse() call
face->size->metrics->ascender seems to be unreliable for some fonts,
additionally the freetype documentation says that it may be used
differently for different fonts.
Therefore it may happen that the ascender of a font face is less then
the glyphs bounding box resulting in accessing invalid memory.
The fix is to use the bbox attribute instead of the ascender
First destroy CCDirector instance with cocos2d::CCDirector::sharedDirector()->end()
Then create new CCDirector instance with
cocos2d::CCApplication::sharedApplication()->run();
APP will crash at
CCApplication::setAnimationInterval
[[CCDirectorCaller sharedDirectorCaller] setAnimationInterval: interval ];
These new resolution policies will either ignore the width or height of the
specified design resolution size, but scale the ignored dimension, so it
matches the aspect ratio of the device.
Example:
A device with 854x480 pixels and a design resolution size set to 480x320
and the kResolutionFixedHeight policy, will create an internal canvas of
the size of 570x320px
If the device original size is 800x480 its internal size will be
534x320px
The height for both examples stays the same, the width is adjusted to match
the aspect ratio
Benefits:
- no distortions
- full canvas is usable, the visibility origin is 0/0
- I can use getWinSize() to place objects which is more intuitive
- for objects that should be placed at 0/0 I can use CGPointZero or 0/0 instead
of the VisibilityRect methods, which is more readable
- using this method projects from the 1.x branch are probably much easier to
port
Disadvantages:
- it is the developers responsibility to create the game code so that it
supports multiple aspect ratios
Some CCLog message contained trailing newlines which
made the logs hard to read on many platforms. The solution
here is to stip trailing newlines on those platforms, and also
to remove the newlines from the existing log messages.
James Gregory