omg, it works, it really works, your method works for me. Thanks so much.
Iām glad @r101 had advice for you
@R101 so you feel we should be doing something different so developers can use Spine easier?
The Spine developers have, on multiple occasions, recommended against including Spine runtime code as part of any game engine releases, not just Cocos2d-x.
With Cocos2d-x, itās even more of an issue because the only way that users seem to update the Spine runtime is to modify files in the Cocos2d-x engine folder. The result of this is that users canāt simply drop a new Cocos2d-x release into their app, or use different versions of Spine, without having to modify it each time to suit their needs.
This isnāt just an issue with Spine, but also other modules, like Box2d. Some of them are so tightly integrated that itās hard to change or update the, or even disable them, without causing build issues. In many cases itās a build script (CMakeList.txt etc) issue, or source code for modules placed in a different folder structure than the official source code distributions.
I understand why Cocos2d-x include libraries like Spine and Box2d as part of the release, mainly because there are references in the engine code to them, but that is not the only way to go about doing this. With the use of CMake, you can add dependencies and links to directories very easily, even from outside the engine CMake scripts.
In my case, if thereās a way for me to disable the building of the built-in modules through build options, then I use that method, and so far Iāve been successful. Donāt get me wrong though, a lot of issues did come up, and it took me a while to figure out a solution or work-around for each.
For the Spine run-times and the way I have it set-up (like in the demo I posted above), itās now very easy to add any version of the run-time to any game. It just involves downloading the code from the repository, copy the relevant runtime code folders (as they are) to the game project folder, and then adding a few lines in the root CMakeLists.txt of the game project to link it all up. If the cocos2d engine library requires a reference to the 3rd party module header files or library, then itās as simple as using target_include_directories and target_link_libraries respectively to accomplish this.
For example:
target_include_directories(cocos2d PRIVATE ${RuntimeModule_INCLUDE_DIRS})
and
target_link_libraries(cocos2d PRIVATE runtime-module)
It may help to document how to override the built-in libraries, along with examples, and at least then it would point developers in the right direction for anything else they may want to integrate with Cocos2d-x.
1 Like
yeah i think so.But i did read some pages that spine is not supported for cocos2d anymore,right? To have spine, have to purchase.
You guys always have us to feedback . So you guys can improve your product better and better.
Where did you read that? Also, you canāt create Spine animations without a license to use the Spine editor. That has always been the case, so perhaps youāre confusing the Spine run-times with the Spine editor here?
1 Like
This topic was automatically closed 24 hours after the last reply. New replies are no longer allowed.
I think the best way of keeping the spine runtime current would be to use git submodules. You already need to do git submodule update --init --recursive when you clone the git repo, so adding the spine runtime as a submodule would be invisible.
In fact I think more and more of the binary deps should be handled this way in an effort to keep them fresh. At the moment the deps tend to be quite stale and forgotten, but using more git submodules would make it much easier to update and manage them. Isnāt the only reason Cocos2d-x only supports 32-bit Win32 because some of the deps have not been built for 64-bit?