Cocos4 源码

COCOS 4
#1

看了下 Cocos4 仓库，有 90 多个提交了。
其中一个提交：
https://github.com/cocos/cocos4/commit/e913d77704ac1ce670cafae0981c0e304a34f0f3

image
image3508×1792 450 KB

这个改动一开始有点奇怪。分量越长的，容错越大，至少保证一个单位的容错系数。为什么这么改呢，看来是有新的应用场景触发了这样的改动。

问了下 AI，可能的触发场景。

这种改动通常是由于在实际开发中遇到了因绝对误差过严而导致的 Bug。在 Cocos 引擎中， equals3f 方法很可能被用于比较三维向量（如位置、缩放、旋转等），以下是一些典型的触发场景：

  1. 大世界坐标
    当游戏场景很大，物体的世界坐标达到数千甚至更大时，例如一个开放世界游戏，角色位置 (5000.0, 0.0, 5000.0) 。由于浮点数精度，两次计算得到的坐标可能相差 1e-5 ，如果原 epsilon 是 1e-7 ，就会判定不相等，可能导致角色移动判定出错或动画状态异常。
  2. 连续变换累积
    物体经过多次旋转、缩放、平移后，其变换矩阵反复计算，累积的浮点误差可能变大。比较两个本应相同的变换结果时，原来的绝对误差容易失效，而相对误差能更好地容忍这种累积误差。
  3. 物理引擎交互
    物理模拟中经常需要比较位置、速度等向量。当物体高速运动或处于大范围空间时，相对误差比较能保证模拟的稳定性，避免因微小绝对误差导致的“抖动”或错误碰撞响应。
  4. 网络同步验证
    在多玩家游戏中，服务端和客户端的坐标可能因网络延迟和浮点运算差异而略有不同。使用相对误差比较可以更宽容地认为两者一致，减少不必要的状态修正。

这次修改让 equals3f 方法 从“固定精度”升级为“自适应精度” ，大幅提升了引擎在处理大数值和复杂运算时的鲁棒性，属于一次防患于未然或修复已出现问题的优化。

再看下下一个比较有意思的提交：

image
image3520×1206 311 KB

我以为小游戏写入文件用异步 api 是基本操作。。。3.8 写入竟然是用的同步。。。

#2

equals3f的修改其实主要是由于 Vec3的equals3f 与 Vec2的equals2f和Vec4的equals4f 都是同类型的api但是实现却不一致
引擎组评估后将equals3f方法的实现修正

#3

原来是这样啊，懂了

#4

用同步写？草台班子

#5

cache 要好好优化一下，现在问题非常多，资源多一点的小游戏，基本上不改cache就不能用。像我们这种资源比较多，几分钟就要填满200M cache限制的，不改很快玩几次要么就卡的不行，要么就直接启动不了了。
主要是满了以后的各种问题，例如下载zip bundle 解压不了，还有写json的卡顿等。
每次我升级引擎，都要把密密麻麻的cache 优化修改同步进去，也是麻烦。

吐槽完了说说这个cache里面的异步问题，我觉得cachelist的异步保存还是会导致问题，例如在异步过程中，玩家关闭小游戏，你的cachelist有可能就会被破坏掉，与本身cache不一致。到时候你一启动，发现json连parse都出问题，进都进不去了。这个write很频繁的，在异步过程中关闭几率还是很大。

以前在删除cache文件的时候也是弄个定时器慢慢删，结果基本上你要关闭小游戏的时候，删不了多少，删的速度比不上下载的速度，结果下次进去还是满的，然后还有可能造成cachelist 和 实际cache 文件不同步。

我现在的cache修改，就是直接限制文件最多数量，和总体大小，然后尽量同步的去删除和修改，卡就卡点至少不会出现问题。

在微信小游戏上，我也发现write 这个json 很卡，但是我采取的方式并不是直接异步，而是限制内容量，例如: 我最多在cache里面存个1000条，测了在2000条之上在微信小游戏上每次write都很卡了。

针对抖音小游戏，我直接禁用了cache，因为抖音快满了以后，还会在运行时把cache里面的文件偷偷后台删除，cachelist不更新结果就导致找不到文件报错。

#6

有大资源量的项目来驱动，做引擎才能够覆盖到较多的应用场景。