I have a game source code which previously has been submitted to app store. for now i am going to resubmit it with better performance but have been faced weird issue. there are already .csb files for each scene in the source code. i have googled and understood how i have to use cocos studio 2.0. for testing purpose i opened old cocos studio project file (.css) and republished it with no changes. and then copy from res folder and paste it into resource folder. but when the xcode tried to load .csb file it crashed.
mainLayer = (Layer*)CSLoader::createNode("GameScene.csb");
the source code works fine with old .csb file. but not worked with new one.
xcode gave me no correct reason. I can see only some setting values in debugger view like this.
when i tried with new .csb which i've republished
libpng warning: iCCP: known incorrect sRGB profile
libpng warning: iCCP: known incorrect sRGB profile
suffix = csb
textureSize = 7
no more
when i tried with old .csb from old source code
libpng warning: iCCP: known incorrect sRGB profile
libpng warning: iCCP: known incorrect sRGB profile
suffix = csb
textureSize = 0
many more...
as you can see, with new one, the app crashed after printed textureSize.
i am using cocos2dx v3.3 and cocos studio v2.2.1
could you please explain about how should i avoid this issue?
many thanks.
Libpng-1.6 is stricter than older versions about bad ICC sRGB profiles.
There is a new C function that you can call to skip the sRGB profile checking:
png_set_option(png_ptr, PNG_SKIP_sRGB_CHECK_PROFILE, PNG_OPTION_ON);
If you're not using C you'll need to find out the equivalent way of doing that.
They are just warnings. A more permanent, and better, solution if you own the image files is to fix the PNG files by removing the bad ICC profiles, which are contained in the PNG iCCP chunk, using your favorite PNG editor.
Having an sRGB profile in an iCCP chunk is just bloat anyway, because applications will assume the image is in the sRGB colorspace if there's no ICC profile present.
It has nothing to do with libpng warning.
This problem may be because some versions of cocos2d-x and cocostudio are not compatible to each other
Update both cocostudio and cocos2d-x to latest version.
try to put the in AppDelegate.cpp the addSearchPath, for example
if you have the .csb files in Resource/cocosstudio add this on applicationDidFinishLaunching() function :
FileUtils::getInstance()->addSearchPath("cocosstudio");
In my proyect i call it like this:
auto node = CSLoader::createNode("MainScene.csb");
Related
Whilst building an old Windows Phone 8 app with Visual Studio 2015 I've come across and unusual error when I upload the built .XAP to the store. It throws the error:
Package acceptance validation error: Package cannot contain multiple files with identical filenames. Please correct the following files: Assets\ApplicationIcon.png, Assets\Background.png
I can view the contents of the .xap file by renaming the file to a .zip and looking inside. Sure enough there are two files with the same name (something I didn't think was even possible!):
This app built fine in other versions of Visual Studio - any idea what is going on and how to fix this?
After some investigation it seems the root cause of the problem can be found in WMAppManifest.xml file in Properties.
<IconPath IsRelative="true" IsResource="false">Assets/ApplicationIcon.png</IconPath>
<SmallImageURI IsResource="false" IsRelative="true">Assets/Background.png</SmallImageURI>
<BackgroundImageURI IsResource="false" IsRelative="true">Assets/Background.png</BackgroundImageURI>
Simply changing all the forward slashes to backward slashes fixes the problem.
<IconPath IsRelative="true" IsResource="false">Assets\ApplicationIcon.png</IconPath>
<SmallImageURI IsResource="false" IsRelative="true">Assets\Background.png</SmallImageURI>
<BackgroundImageURI IsResource="false" IsRelative="true">Assets\Background.png</BackgroundImageURI>
And here is the inside of the .xap - no more duplicate files!
No more duplicate files!
This is an intensely annoying issue, I hope if anyone out there is still using Windows Phone 8 and comes across this it helps!
Whenever I try to use Gdx.files.internal to get a FileHandle, I am getting a FileNotFoundException like follows:
<PATH TO MY GAME>\desktop\xml\screen.xml (The system cannot find the path specified)
I set my project up using the libgdx project setup tool, and it seems that my asset folder within my desktop project is the same as my android project (they're linked). However, when I go to my desktop project there is a bin folder with my assets. If I change the path to "/bin/..." then I can run the project without any exceptions. However, I feel this may be a problem if I export as a JAR.
Code:
final FileHandle screenXML = Gdx.files.internal("xml/screen.xml");
My problem stemmed from the following (credit goes to the awesome and patient IRC community members for Libgdx):
// final Document screenDoc = docBuilder.parse(screenXML.file());
// Note: MUST use .read() here, not .file(), as we link from the android assets!
final Document screenDoc = docBuilder.parse(screenXML.read());
Anyone has the same trouble?It happpens when i want to load the ccbi file into the cocos2d-x project.I have debuged it .The resources path is correct.Maybe it's the version problem of cocosbuilde...Any help appreciated.
i just code as below ,here is the code link:
http://www.plungeinteractive.com/blog/2012/12/26/cocosbuilder-and-cocos2d-x-helloworld-example/
May be it's because of version incompatibility between CocosBuilder and CCBReader as you said. If it is check your log for confirmation.
In XCode if we do folder references for new files sometimes it doesn't includes it properly on next Build. Clear and Rebuilding solves this.
One more time properly check Resource is correct path or not.
I'm encoding and decoding a binary string. It's an Adobe Air app I'm writing.
I've imported mx.utils.Base64Decoder; and mx.utils.Base64Encoder; I've included tons of libraries and I've even gone to this link http://opensource.adobe.com/svn/opensource/flex/sdk/trunk/frameworks/projects/framework/src/mx/utils/ and downloaded the Base64Decoder.as and included it as a library. I'm including the framework.swc as a library too, and I'm able to use Base64Encoder just fine. But as soon as I uncomment the line
var dec:Base64Decoder = new Base64Decoder();
I cannot build the project. It will tell me that the project has errors and cannot build.
does anyone have any clue what could be happening here? I'm so frustrated with this.
I want to embed a ZIP-file into my AS3/Air-application (with Flash Builder) and open it via FZip. For embedding, I use this code:
[Embed(source='../bin/art/resources.zip', mimeType="application/octet-stream")]
public static const rsClass:Class;
When I try to save the project the program chrashes and throws an error:
"Workspace is being build" has encountered a problem. During "Workspace is being build" an internal error has occured. (this is just a bad translation, not original) Java heap space
I click OK, the internal error appears:
The error "Disc space too low" has appeared. Look into the Readme-File at "Run Eclipse" you will find information [...] It is recommended to end the workbench. Do you want to end the workbench? yes/no
In an earlier version of this post I said, that the program doesnt start. That is not true. Only saving causes this error. Because of the saving errors, an earlier version of the program is started, but without errors. When I try to make a bytearray out of the zip, it causes an error (initial content not found), but I suppose the zip doesnt load, so this is not unusual.
you should NOT embed this ZIP but load it instead, you can add to the AIR package any files/folders.
To do it:
in Flash IDE go to "AIR for Android Settings" or "AIR for iOS Settings" and at the bottom of the dialogue box you have "Included files:" field then add folder or file you need,
for FlashDevelop what ever will be in bin folder will be packaged in air as described here
In Flex it will be the src folder and in the export wizzard you can select which files to include like described here.
Edit also you should consider for very large files following idea:
don't include big files (or just basic elements) and download big files and save on user device e.g. on sdcard, and then load it from there.
best regards