V4 support openharmony #20793
V4 support openharmony #20793
Conversation
| ${ZLIB_LIBRARY} | ||
| ${ICONV_LIBRARY} | ||
| "/usr/lib/libz.dylib" | ||
| "/usr/lib/libiconv.dylib" |
There was a problem hiding this comment.
Why do we need to modify the ios platform?
cmake/Modules/CocosBuildSet.cmake
Outdated
| @@ -29,7 +29,7 @@ message(STATUS "PYTHON_PATH:" ${PYTHON_COMMAND}) | |||
| message(STATUS "COCOS_COMMAND_PATH:" ${COCOS_COMMAND}) | |||
| message(STATUS "HOST_SYSTEM:" ${CMAKE_HOST_SYSTEM_NAME}) | |||
| # the default behavior of build module | |||
| option(BUILD_LUA_LIBS "Build lua libraries" OFF) | |||
| option(BUILD_LUA_LIBS "Build lua libraries" ON) | |||
There was a problem hiding this comment.
Why does it need to be on by default?
|
|
||
| #include "base/CCController.h" | ||
|
|
||
| #if (CC_TARGET_PLATFORM == CC_PLATFORM_OHOS) |
There was a problem hiding this comment.
This is a file only owned by the openharmony platform and does not need to be added?
There was a problem hiding this comment.
just keep code style, android and ios also had this
| @@ -36,7 +36,13 @@ | |||
| #include "base/CCDirector.h" | |||
| #include "base/CCEventCustom.h" | |||
|
|
|||
| #pragma comment(lib,"lua51.lib") | |||
| #if (CC_TARGET_PLATFORM == CC_PLATFORM_OHOS) | |||
| #if _MSC_VER | |||
There was a problem hiding this comment.
I'm not sure, but if not modify this, it will compile error, so to avoid influence other platform, we add marco
tests/lua-tests/src/controller.lua
Outdated
| @@ -10,8 +10,10 @@ require "cocos.init" | |||
|
|
|||
| local director = cc.Director:getInstance() | |||
| local glView = director:getOpenGLView() | |||
| local widthx = 1024 | |||
| local heighty = 2112 | |||
There was a problem hiding this comment.
Why do we need to change this width and height for other platforms (like windows, android)?
| @@ -105,6 +105,78 @@ elseif(ANDROID) | |||
| audio/android/tinysndfile.cpp | |||
| ) | |||
|
|
|||
| elseif(OHOS) | |||
There was a problem hiding this comment.
Does OHOS mean harmonyOS or openharmony? It's really confused to me.
Look at this in Cocos Creator: https://github.com/cocos/cocos-engine/blob/v3.8.2/native/CMakeLists.txt#L114
In Cocos Creator, OHOS macro is for HarmonyOS while OPENHARMONY macro is for openharmony OS.
| void MessageBox(const char * pszMsg, const char * pszTitle) { | ||
| std::string msg(pszMsg); | ||
| std::string title(pszTitle); | ||
| JSFunction::getFunction("DiaLog.showDialog").invoke<void>(msg, title); |
There was a problem hiding this comment.
Should DiaLog.showDialog be Dialog.show ? Dialog is a word and doesn't need to make the L uppercase.
And show has already been in the scope of Dialog, the name of showDialog is a little redundant.
There was a problem hiding this comment.
the DiaLog.showDialog is defined at NapiHelper.ts in template project, just a string used to point to the function. We have declared many functions with similar styles in NapiHelper.ts. So I think there is no need to change this.
| */ | ||
| virtual ~FileUtilsOhos(); | ||
|
|
||
| static void setassetmanager(NativeResourceManager* a); |
There was a problem hiding this comment.
Need to keep the same naming rules.
Here should be setAssetManager like the following getter getAssetManager function.
There was a problem hiding this comment.
unnecessary assetmanager， deleted
| #include <EGL/egl.h> | ||
| PFNGLGENVERTEXARRAYSOESPROC glGenVertexArraysOESEXT = 0; | ||
| PFNGLBINDVERTEXARRAYOESPROC glBindVertexArrayOESEXT = 0; | ||
| PFNGLDELETEVERTEXARRAYSOESPROC glDeleteVertexArraysOESEXT = 0; |
There was a problem hiding this comment.
It's better to use nullptr to initialize a pointer variable.
|
|
||
| auto fileUtils = FileUtils::getInstance(); | ||
| std::vector<std::string> searchPaths; | ||
|
|
||
| if (screenSize.height > 320) | ||
| { | ||
| auto resourceSize = Size(960, 640); | ||
| auto resourceSize = Size(1024, 2112); |
There was a problem hiding this comment.
Why change the default value of design resolution size and resource size?
The design resolution and content scale factor should not be changed since they were confirmed when write the test case.
| blockSize, TextHAlignment::LEFT, verticalAlignment[vAlignIdx]); | ||
| auto center = Label::createWithTTF("alignment center", fontFile, fontSize, | ||
| blockSize, TextHAlignment::CENTER, verticalAlignment[vAlignIdx]); | ||
| auto right = Label::createWithTTF("alignment right", fontFile, fontSize, |
There was a problem hiding this comment.
So Label::createWithSystemFont was not implemented for openharmony platform?
fine Co-authored-by: qiuguohua <qiuguohua111@126.com>
V4 support openharmony