@zhangxm
On which iOS devices all this will be tested, confirmed and optimized?
I believe you have all of them to profile and done all thing right. Right?
Obviously, if compare for example: iPhone 6 and iPhone 6s - the iPhone 6S has a faster hardware, so all this needs to test on iPhone 6 only(as minimum), but ideally need to test and confirm stable work on all other devices, which is even faster but share same model type.
And this list is:
iPhone 5S and ideally to confirm on iPhone SE iPhone 6 and to confirm on iPhone 6S and/or iPhone 7 and/or iPhone 8 iPhone 6 Plus and to confirm on iPhone 6S Plus and/or iPhone 7 Plus and/or iPhone 8 Plus
iPhone X and to confirm on iPhone XS iPhone XS Max iPhone XR
iPad Air and to confirm on iPad Air 2 and/or on iPad (2017) and/or on iPad (2018) iPad mini 2 and to confirm iPad mini 3 and on iPad mini 4
iPad Pro 9.7-inch iPad Pro 10.5-inch iPad Pro 12.9-inch
@zhangxm Would you please clarify what you mean by “remove 3d related codes”. Would that mean we can’t use 3D at all with that specific release? How soon would it be before 3D related code is added again?
The reason I’m asking is that we have just decided to use 3D for certain aspects of our product (it’s a 2D product, but with a few 3D animations), but if it won’t be supported by the time it is released (mid-2019), then we need to re-evaluate our decision. Best case, we don’t use 3D and just do the animations in Spine, worst case, we switch to another engine (which I really would prefer not to do).
@cc_x Yep, i think i have to test on these devices after adapting to cocos2d-x. Sorry, i don’t have all the devices, but i think the community can help to test too.
@R101 we haven’t made the final decision to remove 3d, we may discuss it in another thread. I will create a new thread. And even we don’t make sure if it should be renamed v4 or a new 3.x. It will break some API, but it doesn’t bring more new features.
Thats very bad, for quality profiling and optimizing you need a real device to do so in Xcode and quickly test/fix/improve anything. Am I talking about standard and obvious things?
the first metal test case can run, it is because i don’t set window width and height, then the view port size is 0. Currently, i just write metal shader by hand, not translate it to metal shader in runtime. It can polish the API more quickly.
GLSL shader works on metal backend. We are using glsl-optimizer to translate GLSL shader to metal shader. glsl-optimizer doesn’t translate GLSL builtin functions, we are fixing it.
Update: texture is supported in metal backend, texture array currently is not supported. And i created an issue to trace the progress of GLSL builtin functions supporting.
I think this is a standalone project which should not depend on cocos2d-x.
It’s cocos2d-x uses this module instead.
So autorelease stuff may not be in this project.
@dumganhar it is part of cocos2d-x. For convenient, i use a separate repo when developing. I learned from mac and fixed it:
createXXX return an autoreleased object
newXXX return a not autoreleased object
Yep, multiple thread concept is not included now. I don’t know if it is needed, the first purpose is to support metal, and we can optimize it if it is needed.
minus a couple of devices.