魔力宝贝/石器时代 图档格式压缩算法

下文分析了CrossGate(魔力宝贝)的文件格式，因为StoneAge(石器时代)和它差不多(最初均为同一小组作品)，所以一并介绍。
原文作者为梦见草，由野风信子整理和完善。

一．图片数据图片地址文件CrossGateGraphicInfo*_*.binStoneAgeAdrn_*.bin这个文件存放了图片的地址索引，由若干个大小一样的块组成，每个块长度为40字节(StoneAge为80字节)，格式如下：

其中偏移量XY是用于图片定位的，比如X=-18，Y=-19，如果将图片显示在(100,100)，那么实际位置应该是(82,81)，这样才可以和其它图片协调，在做人物动作gif的时候必须用这个参数来调整每一帧的位置，否则动作是抖动的，做地图也需要，否则会错位。图片数据文件CrossGateGraphic*_*.binStoneAgeReal_*.bin这个文件包含了所有图片的原始数据，每个数据块由数据头+数据组成，每个数据头长度16字节，格式为：

后三项和地址文件中的一样，图像数据紧跟在数据头后面。
例如，要解开第100个图片，首先在GraphicInfo_*.bin里定位到第100条记录，即偏移(40*100)字节的位置，根据读出的地址在Graphic_*.bin中找到对应的数据块，就可以读出图片数据了。
绝大部分图片数据都是压缩过的.
二．动画信息动画地址文件CrossGateAnimeInfo*_*.binStoneAgeSpradrn_*.bin存放每个动画在动画序列文件中的地址索引，每个数据块大小12字节

动画信息文件CrossGateAnime*_*.binStoneAgeSpr_*.bin该文件存放了全部动作的图片序列，每个动作由数据头+若干序列号组成，数据头长度12字节。

某些动作号不是所有角色都有，比如跑步前的准备动作。 

有多少帧，后面就跟有多少个序列号，每个序列号长10字节。

图片号就是该帧所用的图片序号，用图片数据里说的方法就可解出每一帧的图片数据。。 

例如要解出340号角色的1方向的第5个动作，先在AnimeInfo_*.bin中定位到第340号数据块，即偏移(12*340)字节的位置，读出地址和动作数，然后根据地址在Anime_*.bin中定位到对应的位置，然后从该位置开始查找方向1动作5的序列，根据帧数读出每一帧的图片号，通过图片号解出对应的图片就行了。 

其中未知的字段表示我还不知道用处的。 

注意：CrossGate的动画序列地址文件AnimeInfo_*.bin，可能由于开发时的某些原因，造成存放了3遍序列，并且按前两遍解出的动画是错误的，要以第3遍为准，第2375号角色才是第0号，其他的版本没有这问题。 
三．地图格式

地图文件就是map目录下的那些，CrossGate的地图档在最前面有12个字节的文件头，内容为"MAP"(后9字节为0)，StoneAge则没有文件头，其它完全一样。地图档格式字段类型说明

字节

DWORD地图长度-东(W)                                                    4

DWORD地图长度-南(H)                                                    4

BYTE[W*H*2]地面的数据，每一个单位2字节，为0表示无地面                N

BYTE[W*H*2]地上的物件等，每一个物体2字节，为0表示该处无物件          N

BYTE[W*H*2]地图标志，每一个单位2字节，具体不清楚，只知道对会引起地图切换的地方有标识                                                                 N

地图是45度视角的四边形，数据的存放顺序是从东到西，由南至北，起点为左边角(东0，南0)。
假设读入的3X3地图数据顺序为123456789，对应的地图显示：

这样读出来的数据是地图编号，在图片数据中说过，图片地址文件的每一条记录的最后一个字段就是地图编号，现在就是根据这个编号反查出对应的图片序号，将它显示出来，由于游戏本身没有地图索引文件(那是在运行游戏的时候生成的)，所以要自制一份方便查找，这里要注意的是地图编号并不是连贯的，比如StoneAge最大的编号为41000，实际上用到的只有1万多点，中间有很多编号是未使用的。 
前面说过，每个图片都有偏移量用于对齐，画地图的时候也需要的，不过这里有点问题，若只是将偏移量加上坐标，地面没有问题，而建筑物纵坐标则会错位，我并不知道正确的做法，我是这样处理的：
假设纵坐标偏移量为y，图片高度h，要画的坐标为y0，那么实际的坐标y1就是
y1=y0+h-47+y
47是一个单位地面的高度(所以地面不必这样处理，因为h-47=0)，这样做可以基本对齐，希望有朋友提供更标准的方法。 

另外，关于缩略图，就是将每个单位(占地面积1X1)缩成如下的四个点：
　  □
□□□
如果一个物件面积为2X1，那么就是
　　　    □
　  □□□□
□□□
缩略图中每个图片都只用一种颜色表示，而这个颜色好像也是游戏自动生成的，所以要做缩略图的话，自己要制作一份颜色表。



四．压缩算法
这是JSS自定的一种Run-Length算法，用于StoneAge和CrossGate，下面是说明：

比如，C9表示填充9个背景色，D1 10表示填充0x110个背景色，12 50表示后面跟着一个长度为0x250的字符串，91 02 30则表示将0x02重复0x130遍。 
RLE压缩方式，具体的压缩编码如下：
0a xx xx xx
a 个单独的颜色点
1a bb xx xx xx
abb 个单独的颜色点
2a bb cc xx xx xx 
abbcc个单独的点

Ca 
a 个透明色
Da bb 
abb 个透明色
Ea bb cc
abbcc个透明色
8a xx
a 个颜色是XX的点
9a xx bb
abb 个颜色为xx的点
Aa xx bb cc
abbcc 个颜色为xx的点
以graphics_10.bin(图像压缩数据文件)为例,一幅图像的结构如下：
typedef struct
{
    WORD fmtflag;       //全部为"RD"
    WORD unknow;        //不知道什么用
    DWORD width;
    DWORD height;
    DWORD size;         // 整个结构大小，就是头+压缩数据
    unsigned char * pdata; // 大小为(size - 16)
}st_RDHeader;
另外还有一个GraphicInfo_10.bin(图片信息索引数据),具体结构如下：
typedef struct
{
    int idx;            //索引号，基本上是按照顺序排列的
    DWORD fileptr;      //在数据文件中的偏移量
    DWORD size;         //大小，整个图像结构的大小，同上一个结构的SIZE
    int ofs_x;          //x偏移量
    int ofs_y;          //y偏移量，就是对齐点离坐上角的y 轴距离
    DWORD width;
    DWORD height; 
    DWORD colorkey;     //随便猜得，不一定正确
    DWORD unuse1;
    DWORD unuse2;
}st_GrpInfo;            // 40 bytes
其他情况，没有压缩
所有的a ,b ,c 都是表示单个十六进制数字。基本上超过3个点一样就用8a xx 了。
关于3.0的魔力宝贝添加的图片其实还是8位色的图片。按照8位色的图片解出来就行了，她不过是用了16位色的显示模式（其实是任何显示模式都可以）。另外，调色板前面的16个位置丢掉了，就是说实际上调色板是存储了后236个颜色的数值。
五．调色板
StoneAge的调色板文件是位于data/pal目录下的palet_*.sap，CrossGate的则为bin/pal目录下的palet_*.cgp，每个文件长度均为708字节，每种颜色3字节，所以每个文件都包含了236种颜色，要注意的是它不是从0号颜色开始排列的，而是从16号，即16-252，但实际上是16-240，前16种颜色和后16种颜色都是指定，文件中的240-252号颜色并没有使用，下面是指定的32种颜色： 
0-15号色 颜色号 0 1 2 3 4 5 6 7 
RGB值 (00,00,00) (00,00,80) (00,80,00) (00,80,80) (80,00,00) (80,00,80) (80,80,00) (C0,C0,C0) 
颜色号 8 9 A B C D E F 
RGB值 (C0,DC,C0) (F0,CA,A6) (00,00,DE) (00,5F,FF) (A0,FF,FF) (D2,5F,00) (FF,D2,50) (28,E1,28) 
240-255号色 颜色号 F0 F1 F2 F3 F4 F5 F6 F7 
RGB值 (96,C3,F5) (5F,A0,1E) (46,7D,C3) (1E,55,9B) (37,41,46) (1E,23,28) (F0,FB,FF) (A5,6E,3A) 
颜色号 F8 F9 FA FB FC FD FE FF 
RGB值 (80,80,80) (00,00,FF) (00,FF,00) (00,FF,FF) (FF,00,00) (FF,80,FF) (FF,FF,00) (FF,FF,FF) 
常用的几个调色板：

六．各版本对应的文件
CrossGate每个大版本都有相对独立的文件，比如最初的版本图片数据文件是Graphic_*.bin等，而龙沙的则是GraphicEx_*.bin，附加上了"Ex"，下面是各个版本所使用的附加名。

七．后续版本的改动
这里说的是CrossGatePuk2(乐园之卵)的数据格式变动。
乐园之卵中的图片不再使用全局调色板，静态图片都自带调色板，动画则是用隐藏调色板。

首先是自带调色板，图片数据中的文件头被扩充至20字节，且版本字段大于等于2(之前的为0和1)。

还原后的数据最后那部分则是自带的调色板数据，大小和调色板长度字段的内容相同。

隐藏调色板本身其实是一些4X1的自带调色板的图片，它们的地图编号字段被重新解释了，表示使用这个调色板的动画序号，比如地图编号为0x1B680，那么在还原第0x1B680号动画的时候，就要使用该图片所带的调色板。
隐藏调色板存在于GraphicInfoV3_*.bin中，即使是AnimeInfo_PUK2_*.bin中的动画也是使用这里的调色板，从3840幅图片开始是隐藏调色板，不过并不是全部连续存在的，所以需要判断，除了宽4高1外，普通图片的地图编号高位为0或者3(乐园版本的地图)，调色板的则不是，可以依此辨别。 

乐园之卵的动画也有很大改变，同一类型的各种宠物，以前是各自有独立的图片，现在是通过改变调色板来区别的(我认为如果能将玩家角色这样简化就好了，宠物反而不应这样)，方向也简化了，右边的三个方向是左边对称过去的，这是一种偷工减料，不过也减少了文件的体积……同时也导致了数据格式的改变。动画信息文件中的数据头结构变化：

要提取乐园之卵后的图片和动画，就必须用以上新的格式。地图的格式本身没有变化，不过增加了附属的文件，主要是和图片分割有关……

可能由于开发时的某些原因，造成存放了3遍序列，并且按前两遍解出的动画是错误的，要以第3遍为准，第2375号角色才是第0号  经过解析文件，发现其实覆盖了4遍