FLIC Delta帧用RLE混合块拷贝与像素填充压缩：高2位标识操作类型（跳过/复制/填充/块拷贝），低6位为计数；解码需维护光标位置，块拷贝须从上一帧缓冲区按符号扩展偏移读取，真彩色以像素为单位处理BGR三元组。
FLIC文件的Delta帧压缩原理是什么
FLIC（FLI/FLC）格式中，Delta帧（类型 0x0004 或 0x0005）不存储完整图像，而是记录与前一帧的像素差异：只保存“变化区域”的坐标、宽度、高度和新像素数据。关键点在于——它用**游程编码（RLE）混合块拷贝与像素填充**，且 RLE 的编码字节高 2 位决定操作类型（0x00：跳过；0x40：复制；0x80：填充；0xC0：特殊控制），低 6 位为计数（或带符号偏移）。这不是标准 RLE，也不等同于 PNG 的差分模式，解析时必须按字节流逐位解包，不能直接 memcpy。
常见错误是把 Delta 数据当普通像素流读取，结果画面错乱、偏移、颜色溢出——因为没处理“跳过行”和“块拷贝源偏移”这两个关键语义。
如何正确读取并解码 Delta 帧的 RLE 数据块
Delta 帧数据以 0x0004（256 色）或 0x0005（真彩色）chunk 开头，其后紧跟一个 16 字节头（含 width/height/x/y offset），再之后才是 RLE 压缩体。解码必须维护当前光标位置（cur_x, cur_y），并严格按以下顺序执行：
- 从当前
cur_y 行开始处理；每条指令可能跨行，需手动更新 cur_x 和 cur_y
- 读取一个字节
b；若 (b & 0xC0) == 0x00：跳过 b & 0x3F 个像素（cur_x += b & 0x3F；若超宽则换行）
- 若
(b & 0xC0) == 0x40：接下来 b & 0x3F 字节是待复制的像素值（256 色下为字节；真彩色下为 3 字节 RGB）
- 若
(b & 0xC0) == 0x80：用下一个字节（或 3 字节）填充 b & 0x3F 次
- 若
(b & 0xC0) == 0xC0：这是“块拷贝”指令——接下来 2 字节是源坐标的相对偏移（小端），需从上一帧缓冲区对应位置拷贝 b & 0x3F 个像素（注意：不是从当前帧！）
cur_y 行开始处理；每条指令可能跨行，需手动更新 cur_x 和 cur_y
b；若 (b & 0xC0) == 0x00：跳过 b & 0x3F 个像素（cur_x += b & 0x3F；若超宽则换行）(b & 0xC0) == 0x40：接下来 b & 0x3F 字节是待复制的像素值（256 色下为字节；真彩色下为 3 字节 RGB）(b & 0xC0) == 0x80：用下一个字节（或 3 字节）填充 b & 0x3F 次(b & 0xC0) == 0xC0：这是“块拷贝”指令——接下来 2 字节是源坐标的相对偏移（小端），需从上一帧缓冲区对应位置拷贝 b & 0x3F 个像素（注意：不是从当前帧！）特别注意：0xC0 类型指令的偏移是 **signed 16-bit**，要转换成实际地址时必须做符号扩展；而且拷贝源地址可能落在上一帧缓冲区任意位置（包括已修改过的区域），所以必须用独立的上一帧副本，不能边解码边覆盖。
为什么用 std::vector 存真彩色 Delta 帧会出错
真彩色 FLIC（0x0005）中，每个像素占 3 字节（BGR 顺序，非 RGB），但 RLE 指令中的“计数”单位始终是**像素数**，不是字节数。例如 (b & 0xC0) == 0x40 且 b == 0x43，表示复制 3 个像素 → 实际读取 9 字节，而非 3 字节。
如果用 std::vector<uint8_t></uint8_t> 直接 push_back 每个字节，会导致像素边界错位；更糟的是，0xC0 块拷贝时若按字节索引计算源地址，会把 BGR 三元组拆开。正确做法是用 std::vector<:array>></:array> 或自定义 stride-aware buffer，所有 RLE 操作以“像素”为单位推进，内部再展开为字节。
另外，FLIC 规范允许帧宽不是 4 的倍数，但部分老编码器会在行末补 0 到 DWORD 对齐——这些填充字节必须在解析 RLE 前跳过，否则会被误认为有效像素。
立即学习“C++免费学习笔记（深入）”；
libfli 等现有库为何不适合深度定制解析
libfli 默认将 Delta 帧解码为完整位图并丢弃原始 RLE 流；它不暴露中间状态（如当前光标位置、上一帧缓冲区指针），也无法干预 0xC0 拷贝的源地址校验逻辑。如果你需要做帧间差异分析、实时 patch 注入、或兼容非标 FLIC（如某些 DOS 游戏打过补丁的私有 chunk），就必须绕过高层 API，直接操作 flic_header 和 raw chunk data。
实操建议：用 fseek/fread 定位到首个 0x0004 或 0x0005 chunk，跳过 16 字节帧头，然后手写 RLE 解析循环；维护两个 std::vector：一个存上一帧解码结果（只读），一个存当前帧目标缓冲（可写）；所有坐标运算用整型，避免浮点误差累积。
最易被忽略的一点：FLIC 文件头里的 speed 字段是毫秒/帧，但某些变种（如 Autodesk Animator Pro 输出）会把该字段设为 0 并依赖 chunk 内部的 0x0007（FLX）扩展——不检查这个，就无法正确同步动画节奏。
0x0005）中，每个像素占 3 字节（BGR 顺序，非 RGB），但 RLE 指令中的“计数”单位始终是**像素数**，不是字节数。例如 (b & 0xC0) == 0x40 且 b == 0x43，表示复制 3 个像素 → 实际读取 9 字节，而非 3 字节。
如果用 std::vector<uint8_t></uint8_t> 直接 push_back 每个字节，会导致像素边界错位；更糟的是，0xC0 块拷贝时若按字节索引计算源地址，会把 BGR 三元组拆开。正确做法是用 std::vector<:array>></:array> 或自定义 stride-aware buffer，所有 RLE 操作以“像素”为单位推进，内部再展开为字节。
另外，FLIC 规范允许帧宽不是 4 的倍数，但部分老编码器会在行末补 0 到 DWORD 对齐——这些填充字节必须在解析 RLE 前跳过，否则会被误认为有效像素。
立即学习“C++免费学习笔记（深入）”；
libfli 等现有库为何不适合深度定制解析
libfli 默认将 Delta 帧解码为完整位图并丢弃原始 RLE 流；它不暴露中间状态（如当前光标位置、上一帧缓冲区指针），也无法干预 0xC0 拷贝的源地址校验逻辑。如果你需要做帧间差异分析、实时 patch 注入、或兼容非标 FLIC（如某些 DOS 游戏打过补丁的私有 chunk），就必须绕过高层 API，直接操作 flic_header 和 raw chunk data。
实操建议：用 fseek/fread 定位到首个 0x0004 或 0x0005 chunk，跳过 16 字节帧头，然后手写 RLE 解析循环；维护两个 std::vector：一个存上一帧解码结果（只读），一个存当前帧目标缓冲（可写）；所有坐标运算用整型，避免浮点误差累积。
最易被忽略的一点：FLIC 文件头里的 speed 字段是毫秒/帧，但某些变种（如 Autodesk Animator Pro 输出）会把该字段设为 0 并依赖 chunk 内部的 0x0007（FLX）扩展——不检查这个，就无法正确同步动画节奏。
