Cocos2d-x v3.17.1 released!

Announcements
#1

Cocos2d-x v3.17.1 released!

The 3.17.1 release focuses on bug fixing.

Cocos2d-x 3.17.1 Release Notes

  • Fix Lua loading performance drop bug introduced in 3.17
  • Renderer limit glClear invoke times, reduce power consuming
  • optimize CMake script，fix some linking issues
  • Android use CMake as default PROP_BUILD_TYPE value
  • Android upgrade Gradle to 4.6, SDK 28, android gradle plugin 3.1.0
  • upgrade LuaJIT to 2.1.0-beta3, fix random crash in 3.17 Lua release mode
  • upgrade libwebsockets to 2.4.2
  • FileUtils provide thread-safe implementation and add missing cross-platform interfaces
  • limit Labels text length to fix render error
  • add Downloader binding to Lua

This release contains more than 45 bugs fixed and 34 misc improvements, please refer to ChangeLog

Downloads

10 Likes
#2
#3

seems great!

#4

Please check this

#5

How CMake prebuilt feature will work on this version?

#6

https://docs.cocos2d-x.org/cocos2d-x/en/installation/CMake-Guide.html?h=cmake

#7

I noticed that PROP_BUILD_TOOLS_VERSION is no longer set, I can’t compile on android now. Is that intentional?

#8

@drelaptop can tell us about any changes.

#9

Remove usage of this variable.
Please check:
https://developer.android.com/studio/releases/gradle-plugin
Build Tools 27.0.3 or higher. Keep in mind, you no longer need to specify a version for the build tools using the android.buildToolsVersion property—the plugin uses the minimum required version by default

1 Like
#10

I actually have a later version of built tools (28.0.3), I tried changing to

com.android.tools.build:gradle:3.2.1

Getting

process_begin: CreateProcess(NULL, “”, …) failed.
C:/Temp/cocosnew/XXX/cocos2d/cocos/Android.mk:341: *** Android NDK: Aborting. . Stop.
process_begin: CreateProcess(NULL, “”, …) failed.
C:/Temp/cocosnew/XXX/cocos2d/cocos/Android.mk:341: *** Android NDK: Aborting. . Stop.

New test project.

#11

Android NDK: C:/Temp/cocosnew/xxx/cocos2d/external/flatbuffers/Android.mk: Cannot find module with tag ‘uv/prebuilt/android’ in import path

#12

Did you download the cocos2d-x 3.17.1 from the official website or GitHub, if GitHub, you must update submodule, and re-download the external deps libs.

Another point, please confirm you have executed setup.py again to update cocos command line Env path, if the path is wrong you will copy wrong files when cocos new.

also you should check your <cocos2d-x>/external/uv/prebuilt/android path, do it existed?

#13

I noticed that 3.17 is no longer available anywhere to download. Please add it to https://cocos2d-x.org/download/version like all other previous releases are added to.

#14

You can always goto our GitHub repo and download releases based upon their tag.

Also: https://digitalocean.cocos2d-x.org/

1 Like
#15

I am newly using cocos2d-x 3.17.1. This version always build with cmake, can’t build with ndk-build by changing PROP_BUILD_TYPE=ndk-build.
This line don’t any effect on cocos compile or run command. Please pay attention about that.
N.B I am using cmake 3.12.3, ndk r19b(also test with r16b but result is same), android studio 3.1.
Thanks in advance

#16

That’s really weird, because here is the if/else in the build.gradle file. Are you sure you setup everything correct?

OT: Why do you want to use ndk instead of cmake?

#17

me too :frowning: i hope someone who will fix it on feature

#18

Hey @mars3142

Thanks for your reply.
Actually I can’t figure out the problem till now. But I think the value of PROP_BUILD_TYPE which is defined from gradle.properties changes from cocos2d library settings that is default cmake. The logic behind my assumption is when I change the variable name to any other except PROP_BUILD_TYPE like PROP_BUILD_TYPE_2 then everything is look good.

Finally I need to use ndk-build cause our existing projects using ndk-build where we maintain Android.mk file. That’s why we don’t want to change the build technology.

1 Like
#19

so, we dont need to modif the android.mk when we create new c++ class? just edit the CMakelist?

1 Like
#20

If you are using CMake, yes