Migrating from Cocos2dx

[IcemarkUK]

Is there any easy step process to migrate existing Cocos2dx 4.0 projects to adxe?

I'm the developer of The Lords of Midnight and Doomdark's Revenge remakes on iOS, OSX, Android, Windows.

I originally developed on Marmalade SDK to give me my cross platform requirements - but that got discontinued. I moved over to Cocos2dx and have taken a while rewriting the UI - all the game engine remained the same. However I am having issues with the Metal implementation leaking memory can causing crashes. Problem is that Cocos2dx seems as good as dead (no updates in two years) and I don't know enough about the low level Metal stuff to resolve the issue and fix a fork myself.

So I am thinking of moving on again... and this for seems like a possible good starting point with a potential quick migration path.

[halx99]

@rh101 may have experience on about this question

[DelinWorks]

Honestly imo if this stuff feels hard for you I'd pick unity3d, You can write once and never worry about something getting dead or having a problem Also it can deploy to many platforms, but hey its your choice

[IcemarkUK]

Insulting much? It's not that it feels hard, I just have little or no experience in OpenGL/Metal which is why I chose a pre-rolled SDK. If I have to delve deep in to Cocos2dx then so be it. But with an engine that hasn't been updated in two years I questioned whether I should stick it with it, and ADXE was suggested as a reasonable alternative, being a fork.

[DelinWorks]

If you see using unity is an insult then you need help, all these engines I use (Unity3d godot unreal adxe and others) do the job very well for each task that they're better at accomplishing. in the end I just suggested an option that I thought suits your use case

[IcemarkUK]

Sorry, it wasn't the unity part - it was "Honestly imo if this stuff feels hard for you". I don't know if that was a turn of phrase or not, but it felt dismissive.

[DelinWorks]

Nah its okay youll notice that I just put "If" meaning If this is hard for you and for newcommers to learn

[rh101]

Is there any easy step process to migrate existing Cocos2dx 4.0 projects to adxe?

It shouldn't be too tough to migrate across.

Off the top of my head, here are the things I had to change:

1 - The game project root CMakeLists.txt file. The best thing you can do is generate a new project using the adxe CLI, and then compare the CMakeLists.txt that is generated with the one that is in your Cocos2d-x v4 project. It should be obvious what needs to change. You could also just move your own source files across to the newly generated adxe project, which is probably the cleaner method.

2 - The cmake build option flags to enable or disable certain modules have been renamed (for instance, SPINE functionality, BUILD_EXTENSION_SPINE). You can easily find those out by checking the relevant build files, such as extensions\CMakeLists.txt and thirdparty\CMakeLists.txt.

3 - Similar to item 2, pre-processor defines may have been renamed to enable and disable functionality.

4 - The backend::PixelFormat types have been renamed. You should be able to just search and replace these entries in your own code, or make a mapping for them in a header, for example:

#define RGBA8888 RGBA8  // in cocos2d-x, RGBA8888, but in adxe, it's RGBA8
#define RGB888 RGB8
...etc

Check the cocos/renderer/backend/Types.h file.

There may be other defines that need to be changed, but I can't quite remember what they are at the moment.

That is all I can think of right now. If you run into any specific issue, just ask about it, and I'm sure someone working with ADXE will be able to point you in the right direction.

[IcemarkUK]

Thanks, I guess I'll just jump in and see how it goes.

[halx99]

Recently, the cmake options have been unified:
#578

Such BUILD_EXTENSION_SPINE was renamed to AX_ENABLE_EXT_SPINE

[aismann]

@IcemarkUK, have you tried to port it?
Maybe I can help you too?

[IcemarkUK]

I never got around to it, but would like to at some stage.