If this problem needs to be discussed in a later version, you can move it away. I don’t know how to do it.
I’m not a moderator, but I mean start a new thread and leave a link to it here so everyone helping you can do it there. It’s not of interest to most people, I’m sure.
Because it’s not very important, a game can be without it. ok i get it :咧嘴笑:
@zhangxm I found issue in last commit of v4 branch, which cause to memory leack.
Suppose that I call Text::setString(…) every frame.
These lines were moved to the end of Sprite::setTexture function:
auto isETC1 = texture && texture->getAlphaTextureName();
setProgramState((isETC1) ? backend::ProgramType::ETC1 : backend::ProgramType::POSITION_TEXTURE_COLOR);
In result of that _texture::_texture::_referenceCount is more on 1 than it was before. It happens because updateProgramState(); is called firstly inside setProgramState() and one more time in Sprite::setTexture().
When mentioned lines were at the start of the function Sprite::_texture was equal nullptr and there were not reference count increment inside setProgramState().
I attached two screens: one before fixing setTexture and one after.
(I have stable crash on Android without any popup messages after last commit. (There is little memory)). Please, check it very attentively.
(Before fix)
(After fix)
@solan The memory leak issue was fixed in PR 20258.
I run the auto-test of cpp-tests on android before my memory leak fix and there is not crash case. Could you fetch the memory leak fix to check if the crash was fixed?
@coulsonwang I checked your changes, and there is some review.
You added info.releaseTextures(); to the ProgramState::setTexture , but haw does it help when texture is one the same object? (like when Text::setTexture).
The memory leak will gone because you commented updateProgramState inside Sprite::setTexture. But there is the following code in Sprite::setProgramState:
if(_programState != nullptr &&
_programState->getProgram()->getProgramType() == type)
return;
If program will return in this point - the updateProgramState will no be called inside setProgramState, and it should be called inside Sprite::setTexture (but you commented it - look please screen). It cause to the issue when textures are not updated and not shown on screen.
I doubt that logic inside Sprite::setTexture was wrong and really advise to revert it. One fix born many others, but where is profit from fix? Previously it worked like this -
ProgramState is created if needed at the Sprite::setTexture begining, than texture uniform is updated with real texture in updateProgramState at the function end. It is normal behavior.
Look please on screens:
The stub game menu before upateProgramState commenting inside Sprite::setTexture:
The same - after commenting:
Stacktrace of stub menu creating:
The memory leak issue is nothing to do with updateProgramState, the real matter is there is a need to release texture in ProgramState::setTexture since the texture will be retained in info.retainTextures();.
You are right, I make a mistake by removing the updateProgramState at the end of Sprite::setTexture . Fixed here.
Yes that’s it. Thanks for fixing.
I used the cocos command, it didn’t generate the .xcodeproj file either.
cocos new MyGame -p com.MyCompany.MyGame -l cpp -d ~/MyCompany
this is what I did
cocos new doesn’t generate .xcodeproj file, you should use cmake to generate it.
thank you for the answer. I’ve made it work with cmake
I managed to get the hello-world app compiled and to run on a device with metal support. However, when I run the same on an older device without metal, i get an error saying that the device does not support metal and the app crashes. Shouldn’t OpenGL step in when metal is not available? Are devices without metal dropped in v4?
Hi. Apple deprecate OpenGL ES and maybe not supporting it in the next year. Then all devices without metal support dropped by Apple. I think we don’t need OpenGL ES for Apple devices after Version 3.x.
I understand that Apple side of the story. My question was for the Cocos2d-x side of the story. The documentation here says
… Cocos2d-x v4 adopts Metal for it’s rendering engine on Apple platforms. If metal, is unavailable on your platform, OpenGL will then be used to render.
Like to know if the condition “If metal, is unavailable on your platform” also includes older iOS/macOS platforms. No problem either way. Just like some clarity as we need to make some decisions for a new app. Thank you.
@nedumaran for iOS/macOS platforms, V4 only works on those devices that support Metal. The document of If metal, is unavailable on your platform, OpenGL will then be used to render. is an incorrect representation and will be removed later.
What about mac os? There is still many older mac os devices, unable to run osx 10.14+ with metal. Should we have fallback opnegl mode for such devices?
@hexerror As Metal wiki said, On macOS, Metal supports Intel HD and Iris Graphics from the HD 4000 series or newer, AMD GCN-based GPUs, and Nvidia Kepler-based GPUs or newer.
For older mac os devices, you can use v3 version instead.