Sprite Packing C 应用程序中的 Sprite 对齐

Posted 2023-03-25

【中文标题】Sprite Packing C 应用程序中的 Sprite 对齐

【英文标题】：Sprite alignment in a Sprite Packing C application

【发布时间】：2020-03-16 16:53:30

【问题描述】：

我正在创建“完美”的精灵打包程序。这是一个精灵打包器，可确保输出精灵与大多数（如果不是全部）游戏引擎和动画软件兼容。这是一个将图像合并成水平精灵表的程序。

它将（如果需要）源帧转换为内存中的 BMP

它认为整个图像的左上角像素完全透明（可配置）

它单独解析每个帧以找到真正的坐标 rect（实际帧的开始、结束位置、宽度和高度（有时图像可能有很多额外的透明像素）。

李>

它确定框架框，它具有最大宽度/高度的框架的宽度和高度，以便它足够长以包含每个框架。 （为了额外的兼容性，每个框架必须具有相同的尺寸）。

创建宽度为 nFrames * wFrameBox 的输出精灵

问题是 - 锚对齐。目前，它尝试对齐每个框架，使其中心位于框架框中心。

if((wBox / 2) > (frame->realCoordinates.w / 2))

    xpos = xBoxOffset + ((wBox / 2) - (frame->realCoordinates.w / 2));

else

    xpos = xBoxOffset + ((frame->realCoordinates.w / 2) - (wBox / 2));

当动画时，它看起来更好，但仍然存在这种不一致的水平框架位置，因此步行动画看起来像走路和摇晃。 我还尝试了以下方法： 存储最宽帧的实际 x 像素位置并将其用作参考点： xpos = xBoxOffset + (frame->realCoordinates.x - xRef); 它还给出了更好的结果，表明这仍然不是正确的算法。 老实说，我不知道我在做什么。

如果输出精灵表的宽度为帧数乘以最宽帧的宽度，那么对齐精灵帧的正确方法是什么（获取绘制下一帧的适当 x 位置）？

【参考方案1】：

您的问题是您首先计算中心然后计算所需边界框的大小。这就是为什么您的图像会“抖动”的原因，因为在每张图像中，中心与原始中心不同。

您应该使用原始边界框的中心作为原点，然后找出每个精灵的大小，跟踪最左侧、最右侧、最顶部和最底部的非透明像素。这将为您提供避免晃动所需的边界框。

问题是你会发现大多数精灵已经这样做了，所以原来的边界框实际上被定义为最小空间来绘制覆盖这些非透明像素的整个精灵序列。

删除未使用的精灵空间的唯一方法是存储第一个完整的精灵，然后存储其他精灵的原点和尺寸，就像在动画 GIF 和 APNG 中所做的那样 (Animated PNG -> https://en.wikipedia.org/wiki/APNG)

【讨论】：

谢谢。我认为我的程序应该输出 A.精灵 B.每一帧都裁剪了不需要的像素被检测为透明，C.一个具有已经确定的实际宽度和高度的二进制文件和一个 GIF（为了制作 gif，我可能应该将帧转换为 png并用 ImageMagick 或其他东西切割透明像素）。你认为值得分享和开源吗？

在应用程序中，每一帧都与其最左边、最右边（本质上是最左边 (x) + 宽度）、最上面和最下面（最上面 (y) + 高度）以及检测到的透明颜色相关联。边界框wBox / 2 的中心是恒定的，但我发现你是对的，并且问题的计算（减去帧偏移）实际上为每一帧产生不同的结果。这背后的动机是移动位置，以便边界框中心和框架中心匹配，认为这样可以正确对齐它们

你的意思是我不应该为每一帧分配一个固定的（足够的最小）宽度吗？如果我把它们打包好，我认为它不会在任何地方都有效，包括在我的游戏引擎中。

我的意思是我有每一帧的 x,y,w,h 但我不知道该怎么处理它们

我不建议您使用 GIF，因为-正如您所说-它缺乏透明度并且最多支持 256 种颜色。我认为 APNG 更适合您的目的。格式只是一个普通的PNG，第一帧是全尺寸，然后是其他块，帧要改变，每个块都给出帧的位置和尺寸，以及其他东西，比如时间。唯一的限制是每个帧都必须适合初始 PNG 图像。它是一种很好的格式，因为 PNG 阅读器将播放精灵（例如浏览器）并被压缩。