Has everything from cocos2d been ported already? Is this part of cocos2d or a totally separate project?
I can’t say that 100 is ported, but at least 98 is OK.
The hallmark event is that, all test cases are run through on uphone & win32. And we are porting iphone-cpp & android-ndk version now.
It’s separate project beyond cocos2d-iphone, but we are keeping contact with Ricardo Quesada.
We keep the same API & same logic, make game developer convenient to port their cocos2d-iphone games from objc to C++
I paste a code segament for example.
// objc with cocos2d-iphone
-(id) init
{
if( (self=[super init] ))
{
CGSize winSize = [[CCDirector sharedDirector] winSize];
CCSprite *player = [CCSprite spriteWithFile:@"Player.png" rect:CGRectMake(0, 0, 27, 40) ];
player.position = ccp(player.contentSize.width/2, winSize.height/2);
[self addChild:player];
}
return self;
}
// cpp with cocos2d-x
bool HelloWorld::init()
{
if ( CCLayer::init() )
{
CGSize winSize = CCDirector::sharedDirector()->getWinSize();
CCSprite *player = CCSprite::spriteWithFile("Player.png", CGRectMake(0, 0, 27, 40) );
player->setPosition( ccp(player->getContentSize().width/2, winSize.height/2) );
this->addChild(player);
}
return true;
}
Is that easy? 
You can download the source code and run win32 versioin
you think that can be done a “code converter” from objective-c to c++? if there isn’t difference on API and logic, there is a possibility, no? It should be just a synthax difference
By now, we do “code convert” manually, about 800~1000 lines-per-day a software engineer can do. As I know, most of cocos2d games are in under 5000 lines. I think one man-week’s worklord is worth for a cross-platform porting.
In the farther future, an auto-converter from objc to c++ is better. Other developers on cocos2d-x ask me the same question, but I have no idea about it. (personally, I always fell fear to deal with strings during my programer career, haha). If this tool isn’t works PERFECTLY and considerring all situations, then we will get codes with handreds of error & warning, that will be quite TERRIBLE! No one would like to fix more than five handred compile errors.
Do you have some design or blue plan on this auto-converter?
no, i have no plan for it.
I know that doing a similar parser\converter is not so easy, and can be tricky.
What i think is that if you really have succeed to compile for iphone and for android will be awesome, i really hope that. If so riq should consider to work just in your c++ project
After we run through all test cases on both cocos2d-iphone-cpp & cocos2d-android-ndk, then I will consider the implement of this converter.
But cocos2d-iphone-cpp is just a supplement of riq’s cocos2d-iphone, for the lazy programers who want to “write-once-compile-to-everywhere” or who are to lazy to learn objc.
Riq’s cocos2d-iphone in objc is still the best engine to write 2D games on iphone.
Hi!
I am very interested in that project. Indeed it make me jump from my chair, so nice to know there is a C*+ version of cocos2D.
My aim is to write once compile and depoly everywhere. My target OSs are Windows. Mac OS X and iOS. Is it possible to do this with cocos2D-x? For example, write the game in Windows with Visual C*+ and take this code to Mac OS X, create an Xcode project, compile it and to deploy to iPhone?
Thank you very much, I’ll put an eye on this project
The project is hosted on github.com/cocos2d/cocos2d-x/ now. It’s well tested on win32 with VS2008, and iPhone 4.1 simulator on XCode.
You can to download and run it.
For a airplay sdk port, you can fork it and make any improvement, then send a “pull request” to us.
If you would like to manage the task list and wiki on this website, please register an account here, then send my an email.
It’s my pleasure to new a subproject cocos2d-airplay for you, on cocos2d-x.org
I have a question about the API, actually. Above you wrote:
@
bool HelloWorld::init()
{
if ( CCLayer::init() )
{
CGSize winSize = CCDirector::sharedDirector()>getWinSize;>setPosition( ccp(player~~>getContentSize.width/2, winSize.height/2) );
CCSprite *player = CCSprite::spriteWithFile );
player
this~~>addChild(player);
}
return true;
}
@
This matches the pattern in ObjC, but to what use? Why aren’t c++ style constructors used instead of this init function? Init never returns false in your example, so what’s it’s use? If HelloWorld inherits from CCLayer, then having a static init function to act as a constructor seems odd. I would expect this to look like so:
@
HelloWorld()
{
CGSize winSize = TheSharedDirector~~>getWinSize; // use extern for direct pointer access rather than static function
CCSprite *player = new CCSprite); // use a constructor instead of static function
player~~>setPosition( ccp(player->getContentSize().width/2, winSize.height/2) );
addChild(player);
}
@
Though this might be more obvious when I get some time with the code, I’m also not sure who’s responsible for cleaning up the memory in your example. Did you add a ref counting system to mirror the one in ObjC? I’d personally like to manage the memory myself, and avoid ref counting systems.
We have substantial discussion before make the decision to use “two phase construction”. Please take a look on this wiki page [[cocos2d-x:Rules of translating objc to cpp#4-two-phase-construction]]
If we use neither try-catch nor two-phase construction, there’s no way to know a failure in the class contructor. I didn’t return false in the sample code, but it isn’t means all init functions have no failure. I think that’s why objc split constructor into alloc & init, and sumsang do it in their c++ bada sdk too. It’s a good pattern.
We implement a NSAutoreleasePool in cocos2dx\cocoa. Classes with CC prefix use this pool to imitate the logic in objc. If you add a child of CCNode into NSAutoreleasePool, it will be autoreleased in the next message loop if its ref count == 0. That’s the way we make developers feel easy to port their cocos2d-iphone games to cocos2d-x.
That makes sense from a porting perspective. However, when writing new cocos2dx apps, I’d love to get away from the whole retain/release/autorelease stuff. I really hate ref counting systems, instead I prefer to use a pointer that becomes null if the object it points to is deleted. This prevents you from crashing in the message loop due to double releases, etc, which are annoying to track down in ObjC. Multiplatform is one advantage to cocos2dx, not using ObjC and inheriting it’s flaws/speed could be another.
I think it would be nice if Cocos2dx did not force a specific memory system, property system, or usage pattern on the user, especially one which is not native or regularly used in C/C++ code. There are significant speed advantages to not using these systems, for instance, and in some cases a user might already have one they prefer.
That said, I have no objection to these things being optional.
The advantage of cocos2d-iphone is noob friendly, easy to use. We try to inhert this.
For C++ experts as you, here’s a way to manage the memory. Have a look in cocos2dx/include/NSObject.h & cocos2dx/cocoa/NSObject.cpp. All classes in cocos2d-x inhert from this class NSObject. So you can easily modify this class to achieve your aim:
# disconnet the invoking to NSPoolManager, from destructor, autorelease function
# remove the ref count
# remove “delete this” from release function
then the memory system of cocos2d-x will go away! haha
I haven’t tried this. In this way, game source can manage their layer, sprite, scene, label objects, but I doubt there will be some memory leak in engine internal.
Another way is in your game source, don’t call static method such as CCXxxx::initWithXXXX(…), new the object by yourself, then call object->init(…), to avoid the autorelease invoking in static methods.