mirror of
https://github.com/smallmain/cocos-enhance-kit.git
synced 2024-12-28 12:37:47 +00:00
77 lines
3.9 KiB
Markdown
77 lines
3.9 KiB
Markdown
|
---
|
||
|
sidebar_position: 4
|
||
|
description: "一般情况下都不需要了解。"
|
||
|
---
|
||
|
|
||
|
# 破坏性变更
|
||
|
|
||
|
在添加新特性的过程中,就像引擎升级一样,有些变化在所难免,在这里你可以对变更进行评估是否会对项目造成巨大的影响。
|
||
|
|
||
|
---
|
||
|
### 默认禁用原生 TTF 渲染器
|
||
|
|
||
|
引擎的 Label 在使用 Char 缓存模式并且使用 TTF 字体时,会使用一个原生 TTF 渲染器。
|
||
|
|
||
|
这个渲染器理论上能提升原生平台的 Label 性能,但仅在 Char 缓存模式并且还要使用 TTF 字体时才生效,这也导致了在原生平台上字体样式可能与其它平台不一致的问题。
|
||
|
|
||
|
在重构 CHAR 缓存模式时考虑到这些因素和人力有限的原因,我们暂时不打算适配这个原生 TTF 渲染器,所以直接默认禁用了原生 TTF 渲染器,这个禁用是官方提供的接口,不会造成其它问题。
|
||
|
|
||
|
**大部分项目可以不用关心**。
|
||
|
|
||
|
```js
|
||
|
cc.macro.ENABLE_NATIVE_TTF_RENDERER = false;
|
||
|
```
|
||
|
|
||
|
---
|
||
|
### 动态图集的一些变化
|
||
|
|
||
|
对动态图集的重构虽然保留了所有原有的公开接口,但实现细节与以前不同了。
|
||
|
|
||
|
如果你的项目有在细致地管理动态图集,请注意以下几点:
|
||
|
|
||
|
- **如果你有手动修改 `cc.dynamicAtlasManager.maxAtlasCount` 属性,请考虑删除**
|
||
|
|
||
|
增强包会根据设备最大纹理数和 Char 缓存模式字符图集的相关设置自动调整动态合图的最大图集数量。
|
||
|
|
||
|
这不意味着你不能手动调整了,而是建议你阅读新动态图集和新 Char 缓存模式相关的文档后再考虑是否有必要进行调整。
|
||
|
|
||
|
关于这个你可以从 [新 UI 渲染批次合并指南](./batcher-guide.md) 进行了解。
|
||
|
|
||
|
- **动态图集重复纹理的判断从 `texture._id` 改为使用 `texture._uuid`**
|
||
|
|
||
|
具体的设计原因和原理可查看动态合图的原理文档。
|
||
|
|
||
|
- **`cc.dynamicAtlasManager.insertSpriteFrame(spriteFrame)` 不再检查纹理的 `packable` 属性**
|
||
|
|
||
|
并不是说 `packable` 属性无效了,而是 `insertSpriteFrame` 现在作为将纹理强制加入动态图集的接口使用。
|
||
|
|
||
|
- **如果你的项目依赖动态图集的内部实现细节,请重新检查相关代码**
|
||
|
|
||
|
比如你的项目依赖一些动态图集未公开的类或者接口(引擎在 `creator.d.ts` 声明了的则是已经公开的),则可能需要重新编写。
|
||
|
|
||
|
---
|
||
|
### Char 缓存模式的一些变化
|
||
|
|
||
|
对 Char 缓存模式也进行了重构,内部变化比较大。
|
||
|
|
||
|
- **暂不支持自定义材质**
|
||
|
|
||
|
如果项目中有组件在使用 Char 缓存模式并且设置了自定义材质则可能会失效,具体原因可前往 [新的 Char 缓存模式](../user-guide/text-render/text-char-mode.md) 文档进行了解。
|
||
|
|
||
|
- **如果你的项目依赖 Char 缓存模式的内部实现细节,请重新检查相关代码**
|
||
|
|
||
|
比如你的项目依赖一些 Char 缓存模式未公开的类或者接口(引擎在 `creator.d.ts` 声明了的则是已经公开的),则可能需要重新编写。
|
||
|
|
||
|
---
|
||
|
### 材质 Hash 计算的变化
|
||
|
|
||
|
在解决材质本身 Hash 变化不会更新材质变体的 Hash 的问题时,为了兼顾原生平台与 Web 平台,我们采取了使材质本身的 Hash 值不变并且修改变体 Hash 计算方式的方法来解决这个问题。
|
||
|
|
||
|
解决这个问题后,在两个材质变体一样的情况下,无论怎么修改材质,都不会影响该材质的变体进行合批(在这之前,修改材质后生成的变体无法和之前的变体合批,因为 Hash 值问题)。
|
||
|
|
||
|
但这引入了新的问题,这会导致完全相同的两个材质不能合批,比如你复制了一个 `multi-2d-sprite` 材质,分别使用这两个材质的组件不再会进行合批。
|
||
|
|
||
|
我们考虑了性能、影响程度等多方面因素之后采取了这个实现,因为后者比较少见,并且可以手动解决:
|
||
|
|
||
|
你只需要手动设置该材质的 Hash 值为 `multi-2d-sprite` 材质的 Hash 值即可使两个材质合批。
|