后文中所提到的工具，除了CT和UISO外，皆为本人自己用C++编译，特此说明。

恸哭，文本替换器：
把翻译好的文本，按偏移直接回填就行。
唯一需要注意的，就是格式，每行最多18个全角字，最多三行。
主要是牵涉到主角说好的文本有点搞，主角名称默认三个字符位置，而且主角名称是用代码表示的，不是游戏中实际看到的“一也”什么的。
比如主角说话或者别人称呼主角，那么剩余的位置，一行只能有15个字，如果不注意，就会超出屏幕，笑～～

恸哭的字库，四色2bpp，比较普通的字库，四色分别为高亮，普通，偏暗，透明。
不普通的地方在于它的保存方式，它是逐个保存每个字的上半部分，每隔一定位置，再保存这些字的下半部分，
所以如果不知道规律，很难让字库正确显示出来，也许是一种加密手段吧，又笑～～呵呵
上图其实已经暗示出这个规律是多少了，不知道有没细心的可以看出来。

恸哭里比较让人无奈的，呃……就属图片部分了。
已知的绘制方式就有不下十种，带调色盘的，不带调色盘的，调色盘不等长的，调色盘不等宽的，各种偏移位置不同的……

恸哭，各房间门牌绘制，16色调色盘，加背景叠加绘制，所绘制出的图，在游戏实际显示中，长度除二。
比如绘制出的图是64*32，游戏内显示的其实是32*32，如上面这幅图的预览，才是游戏内真实显示的效果。

恸哭，道具铭牌绘制，16色调色盘，变长位图，高固定，背景根据铭牌长度另外绘制，宽度也是游戏内实际显示的两倍。

另外，恸哭还有一种类似RGB的绘制方式，不过是用两个字节解密出三种颜色，之前我发过详细的算法及绘制方式，不过被吞了，无语……
一个比较BT的绘制方式

每个完整色块有四个8x8小色块组成，总大小为16x16，按照数字表示的顺序依次绘制，很无语吧……
更有的图片，先绘制左边32块，32x16=512，共计绘制十四行，即（32x16）（14x16）=512x224，
然后再绘制右边的八块，8x16=128。
完整的图片尺寸为（512+128）x224=640*224，然后实际显示在游戏中为320x224。

恸哭汉化版目前发布的内容，共涉及120个相关文件（调色板图片 + 文本），
以下是相关的文件列表（这里并没给出具体的文件名）：

守护英雄文本替换器：
这游戏嘛……三套字库，
一套ascii小码字库，用来显示8x8的英语字母和日语假名。
一套1000多汉字+字母+假名+符号的大字库，用于游戏内显示用。
一套2000多汉字+字母+假名+符号的大字库，用于游戏外显示用。
对的，你没看错，游戏外用的字库，字符更多，因为游戏结束要显示STAFF，还有必杀技名称，各种说明文字等等。
也就是说，这个游戏必须同时具备两个码表，而且两个码表编码还不同，
比如游戏内“我”字的编码是0x0100，游戏外就是0x0101（这里是举个栗子），
是的，还要+1，为什么？因为游戏内和游戏外的换行符不同……额外占用了一个编码。

守护英雄之关于字库绘制：

4bpp 16x16的点阵字库，这个不是重点……
重点是，这个游戏的字库是压缩的，
用一个字节的高位代表指令，低位代表操作数。
下面给出这个游戏的字库解压算法：

下图是解压出的”受“字，能看出来没？

难就难在解压出来字库以后，编辑好还要再压缩回去，这个压缩算法嘛，只好自己逆着写啦……
还有算法的压缩比很重要，如果压缩比过小，生成的文件比原来大，那么只能呵呵了……
1、调试逆出解压算法，
2、修改字库
3、根据解压算法，写出游戏程序的压缩算法
4、把明文字库压缩回填
5、测试（好吧，我们并没有测试人员。笑～～～～）

守护英雄：游戏内一些界面图片素材
这个比恸哭就简单多了，很多素材都是一套调色板，图像尺寸略有不同，
一笔带过。
颜色表：4bpp
128x16 续关画面的选项

224x16 每一关的标题

守护英雄之无限续关：
在文件 GAME.BIN 中，具体的地址忘记了，不过要找应该很容易，
我采用的方法是直接改sh2汇编，
把
dec n，1（减1）
改成
mov n，0x63（赋值99）
16进制是把0xE1改成0x63，改了一个字节。
（这层有点水…………）

精灵王纪传
字库每什么好说的，以前单独在一个帖子里聊过，16x14的单色字体。
不过这个游戏，自带JIS全码表文字，还多了很多空格，我连那些空格都没用完，
几乎没有去动源码表，这点还是比较友善的。

精灵王纪传：关于剧本
文本替换器