游戏汉化教学贴
更新至[第五篇 GIM图像的破解 第二篇 进阶篇]-bluekiller
文本的导入导出基础篇
文本的导入和导出基础篇
作为游戏文本导出的最基本的工具,我们可以使用网上享有盛名的WQSG v1.0.2007.03110版和 CrystalScript文本导入和导出工具。(以后简称WQ和CS)
当然这2个工具未必能覆盖所有的PSP游戏的文本导入和导出,本章介绍的是一个汉化的流程或者说是基本的方法,大家在熟悉方法后,可以自己写一些程序提高导入导出的效率。汉化是一件需要耐心、毅 力、时间、技术、合作的工作,当你想汉化一个游戏的时候,你要做好充分的准备。
案例:圣女贞德(日版)
解包圣女贞德日版的ISO。剧情文本在 PSP_GAME\USRDIR\DATA\EVENT
文本的导出
步骤1 启动WQ。
步骤2 在rom按钮处加载需要导出文本的文件,我们以圣女的剧情文本ST1020AB.BIN文件为例子。码表就是游戏的文本编码,当然在这里我可以告诉你圣女贞德的码表是SJIS。每个游戏的文本编码不一定是 SJIS,也可能是unicode编码,也有可能是unicode编码的扩展UTF-8编码,扯远了,基于后两种编码的导出,这里不作介绍,留给进阶者自己思考把。
步骤3 好,码表选择后的下一步就是选择控制符码表,控制符的目的就是游戏文本导出后的每行文本显示的上下句连接是否采用回车等,方便以后翻译汉化的语句调整,加了控制符,一般的翻译都能胜任,没有控制符,文本也能导出,但是会出现上下句文本语序的倒置,因为大家都知道日文和中文的语序不一样的。至于控制符,也属于进阶范围,需要有一定的程序基础,每个游戏的控制符不一,需要灵活应用,这里也就不再介绍。
步骤 4 在开始的16进制地址填写0。
步骤 5 在结束的16进制地址用取段最大按钮,获得ST1020AB.BIN的字节数,也就是说ST1020AB.BIN的容量。
步骤 6 字节过滤填入2,一般日文SJIS都是双字节,所以一个日文字符是占用2个字节,我们设置为小于等于2,小于2的文字不导出。
步骤 7 开始导出,替导出的文本取名ST1020AB.BIN.txt,这样,剧情文本ST1020AB.BIN的文本就导出了,是不是很简单?
这里放上导出的文本后翻译后的文本对照。
文本翻译后的检查
基于文本的越界,日文字符显示等wq做的比较完善,但是用起来还是比较麻烦,建议自己开发些工具进行修正。
1、文本日文字符检查
启动 jpcheck 1.1 ,按下检查按钮,加载翻译好的ST1020AB.BIN.txt,如果ST1020AB.BIN文本中有没有汉化的字符,程序会显示该句文本。根据offset可以查到ST1020AB.BIN文本中未翻译的日文。
问题:如果不检查,汉化后游戏中出现未汉化的文本。 2、文本格式检查
现在我们看到的导出文本格式,都是基于汉化前辈施大侠当时提出的文本格式:偏址+字节+文本,即
xxxxxxxx,xxx,文本
在文本分发翻译后,翻译在翻译过程中难免发生破坏格式的情况,如:xxxxxxxxxxx,文本以及
xxxxxxxx,xxx文本
启动文本格式检查器formatcheck 1.1,分别按下第9列和剩余列按钮加载翻译好的文本,检查文本格式是否有破坏的情况。
问题:如果不检查,本句文本不会被导入或者破坏被导入的文件。
3、文本字符越界检查
翻译过程中,由于为了表达清楚日文文本的含义,可能出现文本字符越界。为此需要进行检查。
启动offsetcheck1.2,由于圣女编码是sjis,属于双字节,为此我们按下双字节按钮,加载翻译好的文本进行检查,如果是utf-8编码则采用三字节按钮进行检查。
如果文本加入了控制符,我们还可以通过下面的控制符占用字节数进行设定。保证文本不越界。
问题:本句以下的文本不能被导入或者越界的部分不被导入。
文本导入
在上述文本检查合格后,我们可以导入文本了。启动wq。按上图的步骤完成文本的导入。至于不足部分可以用单字节20或者单字节20+双字节8140进行填充。
汉化的文本字符未必都是码表中的字符,导入过程中当码表中没有的字符会提示,这时还需进行修正。直至导入过程中没有提示信息,即认为大功告成。
(备注:码表中不能显示的字符工具还没写:))
问题:码表中没有的字符,本句以下的文本不能被导入,或者该字符在游戏中不能被显示。
WQ2007-03-11版本.rar
文本导入导出器
JP2GBK.rar SJIS码表
WinhexV131.2SR-11.rar 16进制编辑器
0JPCheck.rar
日文片、平假名字符检查器
0FTCheck.rar文本格式检查器
简转繁.rar
文本的扩容
案例:圣女贞德日版ISO:PSP_GAME\SYSDIR\boot.bin 文件日文文本:
0010D140,10,ターン終了
0010D14B,6,部隊表
0010D152,4,戦況
0010D157,4,中断
0010D15C,6,ロード
0010D163,10,オプション
0010D16E,10,(クリア)
汉化文本: 0010D140,10, 回合結束
0010D14B,6,部隊表
0010D152,4,戦況
0010D157,4,中断
0010D15C,6,讀 取
0010D163,10, 選 項
0010D16E,10,(CLEAR)
PSP上测试效果
问题:如何将战况和中断这2个文本上下对齐?日文文本:
0010D152,4,戦況
0010D157,4,中断
显然战况和中断各占4个字节。如果采用下面的方法: 0010D152,4,戦 況
0010D157,4,中 断
显然文本越界了,各超2个字节。
我们用winhex来看看日文的boot.bin
我们用winhex来看看汉化的boot.bin
变化之处在于用20填充了不足,和文本的居中调整。战况和中断各4个字节被分隔符0A分隔,没有任何余地。如何进行扩容呢?由于汉化后长度缩短,我们用20填充,为此我们有机会利用这些20的空间来实现扩容。
答案:移动0A分隔符。
我们用winhex来看看汉化的且移动了0A的boot.bin
呵呵,我们在战况和中断间插入了双字节空格8140,来达到对齐的目的,来看看psp上的演示效果。
原先的文本offset也有了变化:汉化扩容后文本: 0010D140,10, 回合結束
0010D14B,6,部隊表
0010D152,6,戦 況
0010D159,6,中 断
0010D160,6,讀 取
0010D167,6,選 項
0010D16E,10,(CLEAR)
日文文本: 0010D140,10,ターン終了
0010D14B,6,部隊表
0010D152,4,戦況
0010D157,4,中断
0010D15C,6,ロード
0010D163,10,オプション
0010D16E,10,(クリア)
我们可以看到 0010D152,6,戦 況
0010D159,6,中 断
都增加了2个字节,也就是插入对齐用的双字节空格8140。达到了扩容的目的。注意的是:对照日文文本的offset和移动0A后的offset起始位置地址也相应地改变了。
后记:
这种情况适用于文件没有索引表的文件,如果有索引表,还得修改索引表地址,否则将不能被显示,怪物猎人2创建新人物的那个文件就采用了索引表,所以扩容更麻烦。
控制符的基本应用
WQ提供了强大的控制符应用方法,来解决诸如日文语序和中文语序颠倒的问题,还有其他诸如颜色控制等等,都可以借用控制符来导出进行修整。如何鉴别控制符的用途,还需要自己深入研究。这里我们讲解一下最简单的换行控制符的应用,可以解决日文语序和中文语序颠倒的问题。我们还是以圣女的 ST1020AB.BIN.txt为例子。
控制符(换行符)应用
我们先来看看圣女的剧情文本ST1020AB.BIN.txt在使用控制符(换行符)后2个文本的区别。
采用控制符(换行符)以后,优势非常明显,没有采用换行符的情况下,翻译是逐句翻译,上下文可能会出现语序颠倒的情况,当采用换行符以后,有经验的翻译可以移动换行符在本句中的位置,达到符合中国人习惯的语序。
控制符的识别
控制符的识别,老程序员靠经验就能识别,新手需要通过摸索来获得控制符的含义。就拿圣女的剧情文本ST1020AB.BIN.txt,我们用winhex来看看ST1020AB.BIN
OK!知道了换行符的16进制代码是0A,我们就可以利用wq提供的控制符脚本代码进行编写控制符转换了。
Wq控制符码表:
导出:
打开记事簿,左边填写0A,右边填写BR,(br其实是网页的硬回车,写过网页的人都知道,当然也可以
换成你喜欢的文字),导出后的结果就是: 0000198E,29,知ってるよ{BR}失敗したみたいだね导入:
左右颠倒一下。
呵呵,是不是很简单?新手可能有些困惑,但是汉化谁不是从新手一点点开始积累经验,成为老鸟?多练多实践吧。
GIM 图形格式破解
GIM图形格式是sony公司开发的PSP图形格式,GIM格式的版本很多,目前最新的GIM格式已经是1.40版,前段时间的游戏王使用的是1.10版本,圣女贞德采用1.10、1.20、1.30版本,鉴于目前GIM格式图像还没有图形浏览器和编辑器支持,汉化只能将GIM图形数据转换为bmp格式的图像,然后用photoshop或者 fireworks进行编辑后,重新导入GIM,达到汉化的目的。我们将以圣女贞德的GIM图形AF041_00.GIM 作为样本进行介绍,该图形在PSP_GAME\USRDIR\DATA\AS4075目录中,没有的,请下载本贴中的演示程
序。
首先我们要了解的是bmp图形格式的结构。
BMP图像格式结构表
偏移量 位数 英文解释 中文解释
0000h-0001h | 2 | bytes | BMP文件标识 | |
0002h-0005h | 1 | dword | file size | 整个文件容量 |
0006h-0009h | 1 | dword | reserved | 保留 |
000Ah-000Dh | 1 | dword | bmp data offset | 图像数据块开始位置(start offset) |
000Eh-0011h | 1 | dword | bmp head size | 位图信息头 |
0012h-0015h | 1 | dword | width | 位图的宽度 |
0016h-0019h | 1 | dword | height | 位图的高度 |
001Ah-001Bh | 1 | word | planes | 位图的位面数 |
001Ch-001Dh | 1 | word | bits per pixel | 位图的信息头 |
001Eh-0021h | 1 | dword | compression | 位图的压缩 |
0022h-0025h | 1 | dword | bitmap data size | 位图数据块容量 |
0026h-0029h | 1 | dword | Hresolution | 水平分辨率 |
002Ah-002Dh | 1 | dword | Vresolution | 垂直分辨率 |
002Eh-0031h | 1 | dword | colors | 位图的颜色数 |
0032h-0035h | 1 | dword | Important colors | 重要颜色数 |
0036h | N*4 bytes | palette | 调色板 |
N*4+1 | xx bytes | bitmap data | 图像数据区 |
GIM 图形文件结构表
使用winhex或ue打开AF041_00.GIM文件,结构如下。
AF041_00.GIM | 文件结构 | |
0000h-002Fh | 48字节 | Header |
0030h-007Fh | 80字节 | Image header |
0080h-407Fh | 16384字节 | ImageData |
4080h-40CFh | 80字节 | Palette header |
40D0h-44CFh | 1024字节 | Palette |
44D0h-451Bh | 76字节 | FileData |
ok!数据分析清楚后开始撰写bmp文件头:
42 4D
bmp标识
42 4D 36 44 00 00
bmp标识+bmp文件长度
注:文件长度获得:看上表,bmp头文件54字节+调色板(256色)1024字节+图像数据16384字节=17462字节(10进制)=4436字节 (16进制)
42 4D 36 44 00 00 00 00 00 00
bmp标识+bmp文件长度+保留
42 4D 36 44 00 00 00 00 00 00 36 04 00 00
bmp标识+bmp文件长度+保留+图像数据开始位置
注:图像数据开始位置=bmp文件头54字节+256色调色板1024字节=1078字节(10进制)=436字节(16进制)
42 4D 36 44 00 00 00 00 00 00 36 04 00 00 28 00 00 00
bmp标识+bmp文件长度+保留+图像数据开始位置+windows操作系统标识
42 4D 36 44 00 00 00 00 00 00 36 04 00 00 28 00 00 00 80 00 00 00
bmp标识+bmp文件长度+保留+图像数据开始位置+windows操作系统标识+图像宽度注:图形宽度在AF041_00.GIM 的0048h,即10进制128像素。
42 4D 36 44 00 00 00 00 00 00 36 04 00 00 28 00 00 00 80 00 00 00 80 00 00 00
bmp标识+bmp文件长度+保留+图像数据开始位置+windows操作系统标识+图像宽度+图像高度注:图形高度在AF041_00.GIM 的004Ah,即10进制128像素。
42 4D 36 44 00 00 00 00 00 00 36 04 00 00 28 00 00 00 80 00 00 00 80 00 00 00 01 00
bmp标识+bmp文件长度+保留+图像数据开始位置+windows操作系统标识+图像宽度+图像高度+位面数注:位面数 01 00 照抄可以了。
42 4D 36 44 00 00 00 00 00 00 36 04 00 00 28 00 00 00 80 00 00 00 80 00 00 00 01 00 08 00
bmp标识+bmp文件长度+保留+图像数据开始位置+windows操作系统标识+图像宽度+图像高度+位面数+图像信息头
注:图像信息头:16色-4 ,256色-8,16兆色-16,24兆色-18,32兆色-32。
42 4D 36 44 00 00 00 00 00 00 36 04 00 00 28 00 00 00 80 00 00 00 80 00 00 00 01 00 08 00
00 00 00 00
bmp标识+bmp文件长度+保留+图像数据开始位置+windows操作系统标识+图像宽度+图像高度+位面数+图像信息头+压缩
注:压缩:无压缩,全填00。
42 4D 36 44 00 00 00 00 00 00 36 04 00 00 28 00 00 00 80 00 00 00 80 00 00 00 01 00 08 00
00 00 00 00 00 40 00 00
bmp标识+bmp文件长度+保留+图像数据开始位置+windows操作系统标识+图像宽度+图像高度+位面数+图像信息头+压缩+图像数据长度
注:图像数据长度:上表中16384字节=4000字节(16进制)。
42 4D 36 44 00 00 00 00 00 00 36 04 00 00 28 00 00 00 80 00 00 00 80 00 00 00 01 00 08 00
00 00 00 00 00 40 00 00 00 00 00 00 00 00 00 00
bmp标识+bmp文件长度+保留+图像数据开始位置+windows操作系统标识+图像宽度+图像高度+位面数+图像信息头+压缩+图像数据长度+水平分辨率+垂直分辨率
42 4D 36 44 00 00 00 00 00 00 36 04 00 00 28 00 00 00 80 00 00 00 80 00 00 00 01 00 08 00
00 00 00 00 00 40 00 00 00 00 00 00 00 00 00 00 00 01 00 00
bmp标识+bmp文件长度+保留+图像数据开始位置+windows操作系统标识+图像宽度+图像高度+位面数+图像信息头+压缩+图像数据长度+水平分辨率+垂直分辨率+颜色数
注:颜色数:256色=100H
42 4D 36 44 00 00 00 00 00 00 36 04 00 00 28 00 00 00 80 00 00 00 80 00 00 00 01 00 08 00
00 00 00 00 00 40 00 00 00 00 00 00 00 00 00 00 00 01 00 00 00 00 00 00
bmp标识+bmp文件长度+保留+图像数据开始位置+windows操作系统标识+图像宽度+图像高度+位面数+图像信息头+压缩+图像数据长度+水平分辨率+垂直分辨率+颜色数+重要颜色数
注:无
OK!bmp文件头写好了:
42 4D 36 44 00 00 00 00 00 00 36 04 00 00 28 00 00 00 80 00 00 00 80 00 00 00 01 00 08 00
00 00 00 00 00 40 00 00 00 00 00 00 00 00 00 00 00 01 00 00 00 00 00 00
用winhex或ue新建一个16进制文件,写入上面的文件头,把gim的调色板1024字节复制过来,紧接bmp文件头,下面就是图像数据16384字节了,完成后另存为bmp即可现在可以用图像浏览器观看了。
晕,图像是对了,但是出现颠倒和颜色不对。
原来bmp和gim的描绘方式不同,我们需要纠正一下,询问了aeolusc大大,提供了经典的解决方案,高度置于负数 80 FF FF FF,我们再来看一下。
罗杰的衣服颜色怎么蓝了?原来GIM的颜色通道是BGRA,我们需要将调色板的256组BGRA的“B"和”
R“对换一下成为RGBA,这个用手工的话要死人的,还是写个程序转换吧,然后再来看看
总算写完了,累死了。
最后,修改好的bmp导入,可采用上诉逆序的方法导入。下面的GIMtoBMP演示程序,可以帮助你了解破解的过程!
gim格式版本很多,本方法不能通用,具体情况还需具体分析,破解前还是要用winhex和ue看一下结构再下手。
gimtools演示程序.rar
GIM 图像格式破解 第二篇
上一讲中我们提到的是最基本的GIM图形格式,其图形数据区在转为bmp图像格式时,可以直接提取GIM的imagedata,也就是说,此种格式的GIM图像数据区的描绘方式和bmp的描绘方式相同,即在宽度范围内从左至右一直描绘到图像宽度结束。而本讲提出的问题是当GIM采用16x8或16x16的描绘方式时,如果采用上面的直接提取imagedata方式导入bmp,则会出现贴图错误。下面我们来分析一下16x8描绘的原 理。我们以游戏王的t_window0026.gim为例子。它的几何尺寸为64x32像数。标准的16x8存储描绘方
式。本次演示程序可在下面下在,1.1版本为对16x8进行处理,1.2版针对t_window0026.gim的16x8存储描绘方式进行了处理。大家可以打开看一下,加深理解。
我们来看看实际情况图。
下面这张使用1.1版本打开conv目录下的t_window0026.gim,这是图像数据未经16x8处理的
下面这张使用1.2版本打开conv目录下的t_window0026.gim,这是图像数据经16x8处理的
我们将未经16x8处理的t_window0026.gim放大10倍来看,很明显图像分成了4列,对照上面的描绘方式图,大家就不能难理解了。
我们通过提取t_window0026.gim的图像数据区共2048个字节,完成描绘16x8存储小块需要2048/(16x8)
=16块,再来看看t_window0026.gim的图形尺寸,64x32像素,即而完成
宽度一次描绘需要64个字节。而完成一次高度描绘需要8个字节,那么总计完成一次以宽度为单位描绘则需要64x8=512字节。那么图形数据2048需要描绘几次才能完成呢?答案2048/512=4次。我们再来看看下面的数据区重新组合演示。
上图就是从gim文件中提取2048字节的图形数据区块的1/4数据快(512字节)转bmp数据块512字节的演示图,其他3块(512字节)的方法相同,大家也看到,这种重新排列的方法靠手动调整是不可能实现的,现在仅仅只有2kb的数据,而目前已知的最大gim数据区有128kb。为此还是需要编程来完成数据的重整。
ps:如果gim图像尺寸是128x32呢?呵呵,这种算法只要在上面的算法上改进一下即可,1.3版演示程序可以看conv目录128x32的gim。
gimtools 1.2演示程序.rar
gimtools1.3演示程序.rar