[收藏]图像打包程序说明

天云上人

在二维游戏（尤其是RPG）中，一般都有生动的角色（精灵）。正是他们丰富的动作刻划出了他们的性格和习性，使得游戏看起来更人性化，更具可玩性。二维游戏中的精灵动作一般是通过快速依次播放一组图片造成连续动作的错觉。而这组图片可能就会占用过多的系统资源了。做个粗略计算：假设一个精灵大小为48*96，颜色为24位色R8G8B8。那么一帧的大小就大约是48*96*3(byte)=13,824约1.3KB。一个动作假设用8帧，一共8个方向，那么一个精灵的一个动作所需内存共8 * 8 * 13,824 = 884,736约864KB。假设一个精灵有非常丰富的动作（如行走，拳击，投掷，挥剑，挨打，倒地，鞠躬，坐下，躺下，站起，吃饭，睡觉，施行魔法......），那么光是一个精灵，其耗费的存储空间就相当惊人了。即使精灵比较简单，假设共10个动作，那么需要的空间大约是 864KB * 10 = 8.6MB。假如是这样，那么要作出形形色色的很多精灵就非常的困难了。因为仅仅只有10个动作的简单精灵也需要这么多的存储空间。
6 X& U3 i6 }  K' E/ p: K
2 G% t6 L% @% n, V6 d+ ^" L   这种情况下就需要将图像压缩存储了。但是存储空间和加载速度向来就是一对矛盾，二者不可兼得。而在二维游戏中，运行的流畅还是很重要的。因此，仅仅使用简单的压缩（简单到我觉得甚至不能算作压缩了，似乎称其为“紧凑排列”比较合适）来存储。但是这种简单的压缩在速度快，方法非常简单的同时却可以达到几乎50％的空间节省。因此个人认为这是一个非常不错的精灵存储方法。

譬如一幅160×160的精灵图像。
6 B; p3 S3 h6 S- p* H; B% X
图中的紫红色部分作为透明色。如果是15bpp的bmp，那么bmp文件大小为49kb，而存储为紧凑格式后只有14k了（无损压缩）。原因就在于本图有很多透明的地方，这些象素的信息在文件中其实是无用的。因此可以设计一种“紧凑”格式来存放这种文件。假设约定如下的格式：
# N7 B. i, u* k9 k5 T
BLANK_START                0X8000 紧接连续空格的个数
END_OF_LINE                0X8001 表示一行的结束
6 l0 ?9 i6 F0 e+ {  ZEND_OF_IMG                0XFFFF 表示一帧画面的结束
那么文件的前几行可以表示成(十六进制，每个象素颜色值用两个字节表示，为了直观，去除了倒置排列)：
8 i2 \) G+ y) k, N5 t8000 00A0 8001 - 连续160(0xA0)个透明色，行结束
& W# Y/ j2 X* Q  q8000 00A0 8001 - 连续160(0xA0)个透明色，行结束
$ R& i: i3 l9 |( D2 D  c$ K0 `...
3 I3 m5 ?1 M8 c# M9 F而这些信息本来是需要很多字节表示的。每一行需要160×2=320个字节，而现在只需要6个字节。
$ ^: e  f0 d7 a/ ]: H至于遇到图中的最上面的尖角时，存储的内容如下：
8000 005E 2D8F 8000 0041 8001 - 先是94个连续透明色，然后是一个象素的颜色信息，然后接着是连续65个透明色。
至于大约中间位置的时候，存储的内容大致如下：
8000 0010 ....(非透明色颜色信息)... 8000 001F 8001
如果一行全部不是透明色，那么还会损失一些空间，但是这种情况一般是不存在的。