I think we should not be afraid to do something different from what google recommends, or at least not be afraid to come up with a hybrid solution - I would say we should go with CMake for all because the end game is to reach as many platforms as possible with as little work as possible and monetize that market. If we are able to get Cmake working for all the major platforms - it will (generally) be a one-time work which we can then leverage “forever” so to speak.
I think what makes the most sense it to go with an approach that is most comfortable for each target platform.
Xcode - iOS
Android Studio - Android
Visual Studio - Windows Phone
CMake is great, but working properly for each target platform will make everyone’s life much easier in the end. I love QtCreator and would love to be able to do everything with CMake, but I’m not even sure how to debug an iOS simulator app with QtCreator, a lot more issues/work would arise if we’re not using the right tools for the job.
1 Like
hmm, I see your point. However, consider that I am about to publish a game, and I was able to do 99% dev and debug work in visual studio. In fact towards the end I was editing code in VS and then I hit the build button in eclipse to publish to my phone for testing. I wonder if it is possible to make it such that developers only need limited knowledge of platform specific tools, so that you only need to be good with one main IDE (and you can choose which one). I think that is a different discussion from discussing how the actual “publish” build should take place. I think native builds (Xcode->iOS, AndStudio->android, etc) gives confidence that your app is “certified” for the respective app stores - the trick is Cmake script will be intelligent enough to do it for you on each platform. Otherwise we lose the benefit of cross-platform dev and with different platforms regularly changing in different ways and with new platforms coming out every so often, developers will soon “give up” if they have to be really good in 3+ different toolchains.
The only tool we should have to use should be Cocos Studio, and everything should be in there. From app simulation to you name it. Unity does it like that(mostly), Cocos can do even better, specially because its not tied to .net crap.
Using Cocos Studio should be a ‘certification’ in its self, if the tool is well built.
2 Likes
Cocos2d-x is a cross-platform SDK, so we can’t lose the cross-platform-ness just based on the tools. I personally do 100% of my game dev in Xcode, then I just fire up my eclipse project, fight, sweat and swear for an hour to get that piece of shit to do what it’s supposed to, then build my APK. To be honest, I haven’t done too much work with cmake, I just remember it being a bit of a pain locating libs and stuff, but thats just ignorance on my part I think. Also, if you’re a developer targeting multiple platforms with your app/game, I’d 100% expect you to understand and use the tools required to target those platforms.
@Kiori - It is a huge undertaking to build a proper C++ IDE to compete with the big boys on the market (VS, Xcode, etc), and since most cocos2d-x devs use the C++ SDK, I’d hate cocos2d-x to impost an IDE. In my opinion, the cocos2d-x team should spend their time doing what we all love them for, and thats improving the core cocos2d-x framework, rather than trying to reinvent the wheel.
1 Like
My post assumes that you would use whatever tool you would want for c++ and that Cocos Studio would simply work with that. That has nothing to do with what i said.
I meantioned Unity as a reference, you should check their implementation to see what i mean.
For code editing they use mono develop, which is alright, but VS is fully integrated.
I believe apple for instance requires that the final build is made with Xcode, so…
Again check Unity, since they are currently the standard on cross-platform engines.
Unity for instance offers what Cocos calls “live coding” for a lot of features, it would be great if they could implement that for c++, maybe with the help of .net libraries.
Then later on you would properly compile/build the working finished product with your favorite/required IDE.
I don’t know though, these are just ideas over the top of my head. I’m still hoping for a dev environment that will have the best of what the other engines offer, but still be cocos at the core.
On a side note I wouldn’t mind them forcing us to use certain tools, if that meant having excellent features to go with them.
Like i mentioned, mono develop for Unity, it “can’t compete” with VS, but it gets the job done, and ‘just works’ with the editor.
Unity works on a very different principle and uses Mono (soon to be official non-MS .NET implementation) to provide on the fly compilation and run-time environment. Its a completely different architecture. Your original post stated to use Cocoa Studio for everything, which is all I’m speaking to.
Cocos2dx is, I concede as an Android fan, cross platform. Android is cross device and I find it a great benefit to be able to divide my builds into x86 and ARM at the touch of a button with AS. It is no less C++ capable than Eclipse which was rather a basic IDE relying on NDK for error reporting unless you have the cocos2dx build_native.py working (I tried C++ without cocos and there are benefits to just running the NDK-build without the python script). I just need to build experience with it and I would do so by getting rid of my multiple Android Java environments with conflicting SDK paths. Then just start using the cocos console commands where NDK-build was working to build C++. Hope the errors are as readable (not very 
) as ndk-build and figure out (copy) how to get the .so's their own little library in my AS project which just isn’t going to happen trying to import my old Eclipse projects. I’ll need to start from a fresh Java project.
That’s the plan.
But if Google stop developing the ADT tools then I’ll have a pretty stable final version of that to play with for ever more 
Can’t empahisize enough how pants Eclipse is for Java based Android dev in comparison. Can’t empahisize enough how pants Android Studio is for C++ Android dev and reusing other libraries, something I’ve only just become comfortable with in Eclipse…
According to this link SO Android Studio supports NDK. But i didnt try it yet.
Plus, i was looking where to download Eclipse ADT bundle, but i cant find it anymore. It seems that Google erased it from internet with releasing of Android Studio.
Edit, now i found some Eclipse, so may be i will manage it.
Anyway, i am curious about the future of Cocos vs AS. Cant say how much depends on concrete IDE or not.
Found this tutorial on how to “convert your Cocos2D-X Android Eclipse ADT game project into Android Studio project” Convert Android Eclipse ADT game project into Android Studio project
I plan to step through it soon. I’ll try to update this post if any significant issues arise…
1 Like
Looking forward to the progress made by you!
In terms of this link Convert Android Eclipse ADT game project into Android Studio project, I found it useful for importing the initial project into Android Studio and setting up the ndk.dir setting correctly.
In terms of actually building the project, I actually ended up having to edit the build files and ended up using a script called jnibuild.sh to build from the command line. It’s much simpler and easier to maintain, to simply edit the Android makefiles than to try to configure gradle to pass makefile related flags to the ndk layer.
In terms of edits to the build files, these are the changes that I made:
diff --git a/proj.studio/testgame/src/main/jni/Android.mk b/proj.studio/testgame/src/main/jni/Android.mk
index 75e64b0..da85a68 100644
--- a/proj.studio/testgame/src/main/jni/Android.mk
+++ b/proj.studio/testgame/src/main/jni/Android.mk
@@ -2,19 +2,38 @@ LOCAL_PATH := $(call my-dir)
include $(CLEAR_VARS)
-$(call import-add-path,$(LOCAL_PATH)/../../cocos2d)
-$(call import-add-path,$(LOCAL_PATH)/../../cocos2d/external)
-$(call import-add-path,$(LOCAL_PATH)/../../cocos2d/cocos)
+$(call import-add-path,/Users/gino/cocos2d-x-3.4)
+$(call import-add-path,/Users/gino/cocos2d-x-3.4/external)
+$(call import-add-path,/Users/gino/cocos2d-x-3.4/cocos)
LOCAL_MODULE := cocos2dcpp_shared
LOCAL_MODULE_FILENAME := libcocos2dcpp
-LOCAL_SRC_FILES := hellocpp/main.cpp \
- ../../Classes/AppDelegate.cpp \
- ../../Classes/HelloWorldScene.cpp
+FILE_LIST := $(wildcard $(LOCAL_PATH)/../../../../../Classes/*.cpp) \
+ $(wildcard $(LOCAL_PATH)/../../../../../Classes/*.c) \
+ $(wildcard $(LOCAL_PATH)/../../../../../Classes/swig/*.cpp) \
+
+
+
+LOCAL_SRC_FILES := hellocpp/main.cpp
+
+LOCAL_SRC_FILES += $(FILE_LIST:$(LOCAL_PATH)/%=%)
+
+LOCAL_C_INCLUDES := $(LOCAL_PATH)/../../../../../Classes \
+ $(LOCAL_PATH)/../../../../../Classes/swig
+
+
+# following flag will cause assert() to abort program execution:
+LOCAL_CFLAGS += -UNDEBUG
+
+# need to disable SSE instruction generation if we're compiling for x86:
+ifeq ($(TARGET_ARCH_ABI),x86)
+LOCAL_CFLAGS += -U__SSE__
+LOCAL_CPPFLAGS += -U__SSE__
+endif
+
-LOCAL_C_INCLUDES := $(LOCAL_PATH)/../../Classes
diff --git a/proj.studio/testgame/src/main/jni/Application.mk b/proj.studio/testgame/src/main/jni/Application.mk
index 02b8eab..2783509 100644
--- a/proj.studio/testgame/src/main/jni/Application.mk
+++ b/proj.studio/testgame/src/main/jni/Application.mk
@@ -1,4 +1,5 @@
APP_STL := gnustl_static
+APP_PLATFORM := android-10
APP_CPPFLAGS := -frtti -DCC_ENABLE_CHIPMUNK_INTEGRATION=1 -std=c++11 \
-fsigned-char \
@@ -8,6 +9,10 @@ APP_LDFLAGS := -latomic
#APP_ABI := armeabi armeabi-v7a x86
APP_ABI := x86
+#APP_ABI := armeabi
+
+NDK_TOOLCHAIN_VERSION := 4.9
+
(BTW, you can safely skip/ignore the references to the Classes/swig related directory. I use some swig generated code, which I kept under Classes/swig, which needed to be compiled in.)
Also, I needed to add:
sourceSets.main.jni.srcDirs = [] //disable automatic ndk-build call
to the file build.gradle, so that Android Studio would not try to build the jni source code at all.
Looks like Android Studio really doesn’t support ndk builds, aside from being instructed to ignore them, which makes it possible to just invoke ndk-build from the command line and not worry about Android Studio trying to recompile it on its own.
2 Likes
Continuing the discussion from Plans for Android Studio:
[quote=“ginobean, post:21, topic:18713”]
In terms of this link [Convert Android Eclipse ADT game project into Android Studio project][1], I found it useful for importing the initial project into Android Studio and setting up the ndk.dir setting correctly.[/quote]
Thanks @ginobean for your accurate answer.
It happened that I follow the exact tutorial, with the final versions of all the lib and programs and, after modifying some versioning problems among other things, I could continue with the whole process. However, just at the end, I am getting an error that doesn’t let me compile. I spoke with Naeem (the owner of the tut) and I haven’t resolved it.
I am copying here the problem I expose in his blog:
[quote]
…At the moment of compiling, I got an error at synchronizing the build.gradle file. When I try to build it, I get an error:
Error:(17, 0) Could not find property ‘sourceSets’ on root project ‘proj.androidstudio’.
It takes me to that file and points me the error in (appears with a different background color):
dependencies {
classpath ‘com.android.tools.build:gradle:1.1.0’
}
I discovered that the problem is also in the build.gradle file in this place (which also has a different background color):
dependencies {
compile project(’:libcocos2dx’)
}
Which when I try to sync, it throws the same error. If I mouse over it, it reads:
‘dependencies’ cannot be applied to ‘(groovy.lang.Closure)’
I went to Many places on the net and spent time looking for answers before coming here. I modify many properties of the files you also modified, but mainly I found out that I had some missing properties inside the build.gradle file. I grabbed many modified build.gradle files I found and at the end I modified it like this:
compileSdkVersion 24
buildToolsVersion “24.1.2”
minSdkVersion 10
targetSdkVersion 24
versionCode 1
versionName “1.0”
runProguard false
proguardFiles getDefaultProguardFile(‘proguard-android.txt’), ‘proguard-rules.pro’
targetSdkVersion gives me an error if I put it in 14, reads “Not targeting the last version of Android” That’s why I changed it to 24, the same as the other ones.
Even after all this changes, I still can’t compile the program. [/quote]
I feel that it has to be a minor problem, maybe related to the libcocos2dx dependency, I guess.
I tried to follow your guide but honestly I got lost. I have learned so much during this week about all this, but I accept I am new and still learning.
Do you have an idea why I am still getting that error? Maybe you encounter this same problem. If so, can you give me a more digerible guide on how you successfuly accomplish it?
I am thinking to download the latest version of the Eclipse + ADT bundle but I refuse to use it, I believe that I should start with the right foot from the beginning.
Thanks a ton @ginobean for your support. Please, keep having a wonderful day!
Sounds like you probably have the sourceSets in the wrong area.
Here’s what my build.gradle file looks like:
testgame/build.gradle:
apply plugin: 'com.android.application'
android {
compileSdkVersion 22 // generally, this should be the same as targetSdkVersion
buildToolsVersion "21.1.2"
defaultConfig {
applicationId "com.mydomain.testgame"
minSdkVersion 10
targetSdkVersion 22 // always target the latest api version
ndk {
moduleName "cocos2dcpp_shared"
}
}
buildTypes {
release {
minifyEnabled false
proguardFiles getDefaultProguardFile('proguard-android.txt'), 'my-proguard-rules.txt'
}
}
sourceSets.main.jni.srcDirs = [] //disable automatic ndk-build call
}
configurations {
antcp {
description = 'ant classpath'
transitive = true
exclude module: 'ant'
}
}
dependencies {
compile project(':libcocos2dx')
antcp "ant-contrib:ant-contrib:1.0b3"
}
task jnibuild << {
ant.taskdef resource: "net/sf/antcontrib/antcontrib.properties",
classpath: configurations.antcp.asPath
ant.ant antfile: "custom_rules.xml", target: "jnibuild", dir: "."
}
task jnibuild_clean << {
ant.taskdef resource: "net/sf/antcontrib/antcontrib.properties",
classpath: configurations.antcp.asPath
ant.ant antfile: "custom_rules.xml", target: "jnibuild_clean", dir: "."
}
task syncAssetsFromResources ( type : Sync) {
from '../../Resources'
into 'src/main/assets'
}
// WARNING: this will copy the contents of ../../Resources into src/main/assets !
// any existing assets under src/main/assets will be *overwritten*, so only enable this dependency
// if you understand exactly what this syncAssetsFromResources is intended to do !
//
// preBuild.dependsOn syncAssetsFromResources
custom_rules.xml
<?xml version="1.0" encoding="UTF-8"?>
<project name="my_custom_rules" >
<target name="jnibuild" >
<exec executable="/usr/local/bin/jnibuild.sh">
</exec>
</target>
<target name="jnibuild_clean" >
<exec executable="/usr/local/bin/jnibuild.sh">
<arg value="clean" />
</exec>
</target>
</project>
jnibuild.sh (my version)
(note that this jnibuild.sh script assumes that you’re using git to version control your project. It actually
looks for the .git directory to locate the top level of your project…)
#!/usr/bin/bash
#
# The purpose of this script is to aide building native libs in
# Android Studio using recent versions of Gradle 0.8.+. As of this
# version of the Gradle plugin building jni doesn't work just yet.
# So as a workaround you need to disable Gradle from building
# jni sources by adding the following to your project's build.gradle:
#
# android {
# sourceSets.main {
# jni.srcDirs = []
# }
# }
#
# For now you need to build native code manually with ndk-build.
# I highly recommend creating a jni/Application.mk file because
# you can specify everything you need built:
#
# APP_ABI := all
# APP_PLATFORM := android-19
# APP_PROJECT_PATH := /path/to/project/src/main
#
# This script invokes ndk-build, setting the obj output folder
# to the build/jni-obj folder, to align more with Android Studio,
# and the lib output folder to jniLibs.
#
# Finally, Gradle will pick up these libs in the jniLibs folder
# automatically now. No need to tell Gradle where to look for
# 'prebuilts'.
#
# The project path is hardcoded. I put this script in my path
# in order to invoke a jni build from anywhere. You can
# modify it as needed, or put yours in your project somewhere
# and get Gradle to run it for you.
#
# You can also do 'jnibuild.sh clean' if needed.
# To see verbose command line info, use the V=1 flag:
# jnibuild.sh V=1
#
convertSeconds() {
((h=${1}/3600))
((m=(${1}%3600)/60))
((s=${1}%60))
printf "%02d:%02d:%02d" $h $m $s
}
START_TIME=$(date +%s)
original_dir="$PWD"
wd="$PWD"
MY_MODULE_ROOT=
while [[ "$wd" != "/" ]]
do
if [[ -d .git ]]
then
MY_MODULE_ROOT="$PWD"
break # we're at the top level..
fi
builtin cd ..
wd="$PWD"
done
if [[ "$MY_MODULE_ROOT" == "" ]]
then
echo "Was unable to locate your module's root directory."
exit -1
fi
jnidir=$(find . -name 'jni' | egrep -v intermediates | grep main | head -1)
if [[ "${jnidir}" == "" ]]
then
echo "Was unable to locate your project's jni directory."
exit -1
fi
builtin cd "${jnidir}/.."
# set this to the directory where your jni folder resides...
PROJECTDIR="${PWD}"
if [[ ! -d "${PROJECTDIR}" ]]
then
echo "unexpectedly, ${PROJECTDIR} is not a directory !"
echo "(cannot safely continue..)"
exit -1
fi
echo "PROJECTDIR -> ${PROJECTDIR} "
pushd "${PROJECTDIR}"
( # subshell context for exported variables
export NDK_OUT="$PROJECTDIR/../../build/jni-obj";
export NDK_LIBS_OUT="$PROJECTDIR/jniLibs";
ndk-build -C "${PROJECTDIR}" $*
)
popd
END_TIME=$(date +%s)
DIFF_TIME=$(( $END_TIME - $START_TIME ))
fmtStr=$(convertSeconds $DIFF_TIME)
# say 'jay n eye build has finished'
echo "jnibuild.sh duration: $fmtStr "
@ginobean nice tip! i was able to get my game running but i still have some problems, any idea how i debug native cpp, in android studio?
I usually just insert log statements to help debug native cpp on Android. I am not aware of any current Android Studio features that would support debugging native cpp.
Hi @ginobean can you just send a hello world program for cocos2dx-js ? that would be great 
thanks in advance
I’m not familar with cocos2dx-js.
NDK support in Android studio is now available for test (update android studio from canary)