Port iphone game to android in C++

cocos2d-x C++
#21

Hey It solved my problem and the results were great.
I was able to load a sprite sheet of 8000 frames in like under 2-3 seconds.

Thanks alot :slight_smile:

#22

Hi, Zonhaib Zaidi, so your conclusion is tinyxml is more efficient chan libxml2 when uses to loading frames ?

#23

Hey Walzer,
Yeah that is it. There was no way that my 8000 frames plist would load on an android or iOS device using either the android ndk or airplay/marmalade sdk.
It would load on the simulator in like 1.5 minutes.
When tinyxml was integrated it loaded in around 2 seconds and worked perfectly fine on the device as well.

So yeah tinyxml it is.

#24

Great! Amazing efficiency!
And nice to hear you finally resolved this problem, congratulations!

#25

Yeah finally relievedā€¦
All thanks to you guysā€¦ Great people Walzer, Isaac, Max and all othersā€¦ Thanks :slight_smile:

#26

Oh, may be the engine should use tinyxml.
#616 is created for it.

#27

Hi All
I came across this post when I found the that CCSAXParser take a lot of time to load .plist files. Glad to know a solution exists! Thanks everyone for it (Iā€™m yet to integrate it).

However, I have a suggestion to make. Iā€™ve read that TinyXML is sometimes quite buggy and has memory leaks in it as pointed out here: http://stackoverflow.com/questions/170686/best-open-xml-parser-for-c

Also, they state that PugiXML/RapidXML are much faster than TinyXML.
So why not port the new CCSAXParser using some other parser, maybe PugiXML or RapidXML?

Please note that Iā€™ve not used TinyXML on my own but had just come across the post and hence felt like making the suggestion.

Regards,
Mots

#28

I ran the bog-standard windows CRT leak detector over my app after finishing it, in the win32 port, and there were no leaks detected in tinyxml (or elsewhere, Iā€™m pleased to report). The main reason i chose tinyxml was that I had familiarity with it, and it compiled and worked on the android without needing adjusting at all. But of course, there may well be better solutions :slight_smile:

#29

RapidXML is no good since Android C++ doesnā€™t allow hpp file and try/catch blocks, both of which are RapidXML. But yes, it is very fast.

Edit: We fixed the android issue, just call ParseDeep instead of Parse, and use the CCFileData type to grab a buffer to the fileā€™s contents instead from the file. Then, you donā€™t have to deal with compression, send the buffer into Parse Deep, and pass in 0 as the next parameter

#30

Ignore thisā€¦ hit post instead of edit earlier