多平台行为不一致

Creator 3.x
#10
  1. 组件生命周期 ， 资源加载跟平台与设备的I/O能力有关， 不同平台底层处理不一様， 但这在游戏项目开发中完全不是问题，这种I/O产生异步不同情况完全可以依赖项目在技术设计方案上去避开（如资源提前加载， 所有人都进场景后上报服务端， 服务端下发正式开始游戏)
  2. 你举列渲染顺序如何影响游戏？
  3. 浮点数问题是计算机基础知识，你可以自己上网查或GPT一下
  4. 至于不同平台有一点不同， 就是cc打包native后部分代码是由c++层托管执行，采用opengl渲染，所以某些在web平台正常运行在native不能运行

给我的感觉就像是，不容平台中，程序中运行时的时序，并不统一，也没有参考性
如果是因为不同平台中浮点数的处理机制的问题

每个平台底层不一様， 但这不重要， 关键是你应用层的表现是否一様， 用户之间同步是否致就可以

以上你要避开， 自己去看书， 做研究， webgl与opengl差别， android平台/ios平台app开发书籍

#11

十分感谢，您的回答 :kissing_closed_eyes::kissing_closed_eyes::kissing_closed_eyes:

#12

rapier.js无法在原生ios使用，会提示[WARN]: JS: WebAssembly is not supported!

#13

养成查询h5 api 支持的版本

WebAssembly, 至少要ios 11 才能支持。 报错写WebAssembly no support ， 就是説你的浏览器不支持， window作用域下没有WebAssembly这东西。

#14

我的是ios 16，但我不是用ios的浏览器打开游戏的，我是打包成ios原生的app和安卓原生的app，安卓原生的app在游戏里用v8引擎是能正常运行 rapier，但ios原生的引用的javascriptcore则不支持WebAssembly。我试过部署到web上在 ios的浏览器safri里打开是能正常运行rapier的。我想问一下你有试过直接把rapier打包成ios的原生app吗？

#15

我负责的都是基于自家app的webview进行游戏， 但就算ios webview 也是使用了javascriptcore， 只要是ios 11以上都是能跑webassembly，因为jscore是在v11开始支持webassembly 1.0, 如果你是使用cocos 提供的打包原生后无法使用webassembly， 那你就要问问官方是否要采用另一种方式去实例webassembly, 如果确认自身的jscore能支持webassembly， 但运行时不行可以考虑像桥接一様在原生层注入Webassembly 方法到 window作用域下

#16

CocosCreator 在iOS App上也是用的V8引擎驱动JS，V8引擎自带的WASM和TurboFan深度绑定关系，而TurboFan直接关联jit

但因为iOS审核限制限制了不能开启jit，所以TurboFan、v8的WASM都不能启用，也就是webassembly is undefined，这个其实有解决办法，静候佳音

iOS上面也是可以运行WASM，但只能在解释器模式下，苹果钦定的JavaScriptCore引擎，最新版本是带了一个WASM解释器
解释器模式运行，性能远低于JIT模式WASM

#17

原来是这样，我想问一下，你说的有解决办法，是指什么办法，能简单说一下吗，我想去尝试一下。我目前想试的一个方法是看看能不能把rapier转成asm.js，就像cocos creator现在打包ios原生app如果box2d选用了wasm但实际打出来的是asm.js。这样起码rapier在能原生 ios用。但好像没找到有这样的案例

#18

你的方法是指自行升级V8到12.X，然后改成非JIT模式？

#19

是的，微软给v8贡献了一个解释器模式的WASM，可在非jit模式下运行，v8版本好像得12.x以上才有

#20

是要加什么参数才能启用解释器模式的WASM？我看了引擎源码，它默认已经加了一个非jit的参数 flags.append(" --jitless");
然后我看原来cocos的开发者也编译了一个v8的12.6.228.49的版本出来
https://github.com/forkrp/test-v8/releases/tag/12.6.228.49-2

#21

详细信息参考，我还没试过

image
image728×163 18.1 KB

[DrumBrake: a Wasm Interpreter for V8 - Google Docs]
(https://docs.google.com/document/d/1OIJ4Sv2XfTlI5NmTS1QI8v8wPL0LUT5s1W2D9OlJmMc/preview?tab=t.0#heading=h.2hff7nffvheq)

该文档中说明了在iOS的非JIT模式下开启WASM的性能对比

#22

不用浪费时间 直接选确定性物理引擎Rapier 弯路我已经走完了相信我
这是跑通的游戏: 竞速类物理引擎帧同步实现方案 - Creator 3.x - Cocos中文社区

#23

通过node --wasm-jitless xxx.js，可以快速测试得出结论WebAssembly.instantiate是可用的，只是没有了jit
那么，其实是否可以考虑将Cocos中的–jitless换成–wasm-jitless呢？

#24

你电脑上应该安装的nodejs版本很高，高版本的node自然也带了v8的最新drumbrake

理论可行，但目前V8构建iOS的静态库，构建配置启用 v8_enable_drumbrake 会报错

image
image722×118 13.1 KB

#25

所以我理解是其实关闭v8_enable_drumbrake的情况下构建，
打开–wasm-jitless也只是能保证有WebAssembly模块可以使用，
对性能没有任何帮助？

#26

开启wasm不会提升解释器环境的js性能，两者独立，增加v8_enable_drumbrake是为了保证iOS环境也能用wasm，做到跟android一致。合理使用，wasm的性能都比js要强

#27

我想wasm环境支持应该是V8_ENABLE_WEBASSEMBLY控制？
但Cocos使用–jitless导致wasm丢失支持（node.js使用–jitless也会导致wasm无法使用）？
所以收敛为–wasm-jitless更小范围以保证ios审核问题同时可执行wasm，不考虑执行性能问题？

#28

image

寄
翻到v8里的一条说明，不用纠结了

#29

这并不绝对

v8不是有wasm吗？

  • v8自带了wasm，其在jit模式下满血性能释放，在非jit模式下，v8其实也有一个非jit模式wasm，用于v8内部测试等研究，其性能很差且维护也很烂（出于维护成本考虑，可能v8在非jit模式就不想开放wasm），你截图的内容应该是指Google v8团队研发的的非jit模式wasm的补充说明。

为什么叫drumbrake？

  • drumbrake是微软技术团队贡献的一个解释器模式wasm，因Edge转向Chromium内核后，微软一直在深度参与Chromium和v8的迭代维护，贡献了非常多的能力，drumbrake是其中代表性的一个产物。微软也把drumbrake提交到了v8仓库，v8团队也做了合并。

drumbrake特点是什么

  • 和v8深度绑定，不支持其他js引擎
  • 解释器模式运行
  • 64位only

v8为什么不将drumbrake变成非jit模式下的正式wasm？

  • 我猜测政治因素多一点（脸面问题），自行体会把