排查plist中offset字段导致的抖动问题

最近遇到一个bug,plist制作的动画,在creator中会抖动,排查定位了很久,最终确定是plist里面offset导致的,花了点时间详细了解了下。

offset的含义

offset的含义: trim透明像素前后,中心点的偏移。

在这篇文章中,有详细介绍offset的计算方式


o f f s e t X = ( t r i m W i d t h / 2 + l e f t ) − o r i g i n W i d t h / 2 offsetX = ( trimWidth/2 + left ) - originWidth/2 offsetX=(trimWidth/2+left)−originWidth/2

化简后:
o f f s e t X = ( t r i m W i d t h − o r i g i n W i d t h ) / 2 + l e f t offsetX = (trimWidth- originWidth)/2 +left offsetX=(trimWidth−originWidth)/2+left

所以问题的关键就在于trimWidth-originWidth的结果是否能被2整除

大胆假设

在c++里面,假设计算offset的代码如下

c++ 复制代码
int value = (50-1)/2;

因为类型为int,所以不能整除就会被丢弃掉小数,这也是导致出现0.5bug的原因。

制作测试例

基于以上假想设计测试例:图片宽100,从25-78有像素,也就是有53个实际像素 代入公式计算,是肯定会出现小数点的

js 复制代码
(53-100)/2 + 25
  -47   /2 + 25
    -23.5  + 25 = -1.5

TexturePacker的结果

xml 复制代码
<key>frame</key>
<string>{{2,2},{54,100}}</string> // 54
<key>offset</key>
<string>{1,0}</string>
<key>rotated</key>
<false/>
<key>sourceColorRect</key>
<string>{{24,0},{54,100}}</string>// 可以看到是从24开始的读取像素的
<key>sourceSize</key>
<string>{100,100}</string>

CocosStudio的结果

xml 复制代码
<key>frame</key>
<string>{{2,2},{53,100}}</string> // 53
<key>offset</key>
<string>{1,0}</string>
<key>rotated</key>
<false />
<key>sourceSize</key>
<string>{100,100}</string>

结论

我们发现2个不同的软件打包plist,宽度出现了1像素的偏差,这就是导致这个问题的原因,根本原因还是TrimDiff无法被2整除导致的

尽量使用TexturePacker来打包plist,少踩坑!

至于为什么texturePacker将53变为54,可能是为了照顾到offset如果为小数,在解析上会出现性能问题。

大胆猜测:texturePacker当发现trimDiff无法被2整除时,会自动调整尺寸。

cocos creator 会出现这个问题么

我尝试做了一个测试例,并配置了自动图集,构建好后找到合图的信息数据,如下:

json 复制代码
[[{ "name": "img_08", "rect": [111, 222, 87, 87], "offset": [0, 0], "originalSize": [231, 231], "capInsets": [0, 0, 0, 0] }], [0], 0, [0], [0], [0]],
[[{ "name": "img_04", "rect": [3, 403, 48, 47], "offset": [-0.5, 0], "originalSize": [231, 231], "capInsets": [0, 0, 0, 0] }], [0], 0, [0], [0], [0]],
[[{ "name": "img_17", "rect": [188, 76, 64, 64], "offset": [-0.5, 0.5], "originalSize": [231, 231], "capInsets": [0, 0, 0, 0] }], [0], 0, [0], [0], [0]],
[[{ "name": "img_11", "rect": [3, 222, 102, 102], "offset": [-0.5, 0.5], "originalSize": [231, 231], "capInsets": [0, 0, 0, 0] }], [0], 0, [0], [0], [0]],
[[{ "name": "img_14", "rect": [75, 388, 66, 66], "offset": [-0.5, -0.5], "originalSize": [231, 231], "capInsets": [0, 0, 0, 0] }], [0], 0, [0], [0], [0]],
[[{ "name": "img_12", "rect": [113, 3, 67, 67], "offset": [0, 0], "originalSize": [231, 231], "capInsets": [0, 0, 0, 0] }], [0], 0, [0], [0], [0]],
[[{ "name": "img_09", "rect": [3, 3, 104, 104], "offset": [-0.5, 0.5], "originalSize": [231, 231], "capInsets": [0, 0, 0, 0] }], [0], 0, [0], [0], [0]],
[[{ "name": "img_06", "rect": [183, 315, 66, 67], "offset": [-0.5, 0], "originalSize": [231, 231], "capInsets": [0, 0, 0, 0] }], [0], 0, [0], [0], [0]]

发现offset0.5的情况,验证后和rect.width - originalSize.width不能被2整除的结论是正确的,很显然creator是能够正常处理好这种问题的。

相关推荐
禅思院1 小时前
前端部署“三层漏斗”完全指南:从CI/CD到自动回滚的工程化实战【开题】
前端·架构·前端框架
快乐肚皮2 小时前
深入理解Loop Engineering
前端·后端
风骏时光牛马2 小时前
VHDL十大经典基础功能设计实例代码合集
前端
hunterandroid3 小时前
Notification 通知:从基础到渠道适配
前端
孟陬3 小时前
Claude Code 巧思 `Ctrl+S` 暂存键
前端·后端
PedroQue993 小时前
V1.6.1性能优化:高频路径提速与代码精简
前端·uni-app
猩猩程序员3 小时前
将 LiteLLM 迁移到 Rust —— 构建最快、最轻量的 AI Gateway
前端
lichenyang4533 小时前
JSBridge 分发升级:为什么要从 if-else 变成 Registry > 这是「ASCF 架构升级」系列的第 3 篇
前端
码上天下3 小时前
流式响应断了,前端怎么自动重连续传
前端
anyup3 小时前
来简单聊聊鸿蒙开发,万元奖金的事~
前端·华为·harmonyos