估计在我之前也有不少的前辈们尝试过这样的处理，甚至也有专门的工具了，因此本文权当记录自己的Gal修改历程+为（可能存在的）后来人铺路吧。

废话少说，先介绍一下画质提升工作的环境与原理：

首先笔者测试的游戏为「るいは智を呼ぶ」（中文名：智以类聚；萌娘和维基百科我都进行了编写，有兴趣的同学可以去康康。Ps.维基百科翻译得更全一些）。本游戏为一个2008年发售的老游戏，使用的引擎是KRKR2。（下面这个PV做得挺不错的可以康康，歌也蛮好听的

一切的缘起是笔者在解包FD时发现FD的背景及CG包都默认附带了“Large”版本（1600*1200），而原版游戏的分辨率为800*600，因此笔者突发奇想，是否可以利用PS，以及现在流行的AI放大技术对原版游戏的美术素材进行放大处理，借此来提升老游戏的画质，而这也是后文进行所谓的“画质提升”处理的主要原理（AI放大对这种animation素材的处理也是相对最好的）。

废话少说，先让我们看一下这样处理后的效果，效果不佳的话也没有继续阅读下去的必要了23333（不过不知道B站会不会过分压图）

这一步就卡壳的同学可以在网上搜索krkr解包教程，网上有无数教程，我就不再着墨了。

具体的软件有XP3Viewer、KrKrExtract等等。

二、处理美术素材

每个游戏存储的位置不尽相同，有的游戏会一起放进data.xp3，有的则会单独打包成xp3，我们只需要分辨名称即可。bgimage一般是背景，fgimage是立绘，evimage为游戏CG，而剩下的一些UI的素材（文本框、历史记录框之类的）我们同样需要放大处理。

针对CG等的处理

针对不同的素材我们也需要采取不同的放大方法，对于CG这种单纯的画可以使用网上随处可见的AI放大进行放大，我用的是上古年代收藏的一个叫「Bigjpg」的网站进行放大，高要求的处理要会员，不过我们只是试试水，因此用最普通的2x放大即可。

这种放大方式针对线条轮廓、衣服及头发线条的处理效果可以说是完美的，但对于Galgame其特有的上色方式比较突出的部位（如眼部及一些渐变色的部位），效果就显得相对一般。

即便如此，对于UP主这种不是很强迫症的人来说，效果还是很不错的。（毕竟都玩了不少上古作品了）

针对UI及立绘的处理

熟悉解包的同学应该知道，很多游戏的立绘都是由各个部件组合成为我们在游戏中看到的正常立绘的，而UI同样是由大量零碎的小「组件」组合成我们所看到的正常UI的。因此我们要使用别的方式来处理这些素材。

为什么不继续使用AI处理呢？首先是因为这些素材往往数量太大，既浪费时间，又浪费额度，其次由于这些素材过大或过小，抑或是比例过于奇怪，对于很多AI处理来说，其处理的效果并不是很好，因此我们需要另寻他路。

这里就必须隆重介绍Adobe Photoshop 于2018版本开始实装的黑科技：「保留细节2.0」，具体的原理算法我们就不去研究了，我们只需要知道这个功能相比传统的放大算法，效果的提升还是不错的。

例如本作中的立绘我便是使用该功能进行处理的，显示的效果还是不错的。

事实上本作是有高清的PS3版本的，不过笔者手边没有PS3的游戏资源，再加上PS3版裁剪了原版的CG导致很多场景看起来很古怪，因此笔者就直接对原版的素材下手了。。。

三、游戏参数的调整

上面两步可以说没啥技术含量，也并不复杂，相信此前也有不少人都这样尝试过。而接下来这步才是真正的难关，也让笔者在中途走了不少的弯路。

相信细心的同学已经发现，上面截图的对比中，修改后的版本与原版本人物的位置都有一定偏差，这是为什么呢？其实就是因为参数调整的问题。

1）全局设置

首先我们要打开游戏解包后的 Config.tjs 文件（每个游戏可能不一样，重要的其实是字段，如果没有找到的话建议用Emeditor批量打开文件检索关键字），然后寻找以下字段：

由于前述操作中，我们对游戏素材的边长分别*2，因此我们对游戏的基础画面的长宽比也设置成1600*1200。

是不是完成这一步就OK了？答案是否定的，我们继续沿着文件向下看，会发现很多关于图层画面的设定，我们需要对其一一进行*2处理。

这里需要注意的是我们不能看到数字即无脑进行处理，我们也得首先观察每行的名称，例如：

这里设置的其实是透明度，若是不在意进行了修改的话会导致画面显示出现问题。

2）字号设置

这里是笔者所走的第一个弯路，在 Config.tjs 中有如下一段：

字面意思，即设置游戏中出现的文字的默认字号。然而当笔者对数字进行修改后发现游戏中的文字大小并未改变，如下图所示：

但神奇的是，同样在 Config.tjs 中出现的：

字间距

ruby（标注振假名的那个）字号

皆在游戏中生效，而笔者设置的 defaultFontSize = 46 貌似仅对历史记录的字号生效了。这里笔者马上进入了第一个误区，我以为文本框，即「メッセージレイヤ（Message Layer）」对字号是有单独的设定的，因此笔者用Emeditor批量打开「main」、「sysscn」与「system」下辖的各个文件，利用关键词查找信息，针对 MessageLayer.tjs 文件更是逐行检查，最终却一无所获。

走投无路的笔者联想到翻译文本时曾留意到剧本中，即シナリオ（scenario）中，会对部分文本进行临时的字号标注调整，于是笔者想到是否可能在scenario中对字号进行了一个设置，于是笔者翻遍整个文件夹，最后发现了 macro.ks 这个文件（macro可以翻译成宏观，在这里可能翻译成全局设定比较好？）其实该文件笔者在之前也快速扫了一眼，但以为仅仅跟演出效果相关，并没有过多留意，这次我用Emeditor检索时留了个心眼，使用的关键字是「23」，通过前面的修改我们可以得知本游戏的默认字号应该是23，因此有23这个稍显突兀的质数存在的文件一定有猫腻，于是就这样笔者在 macro.ks 中发现了如下代码：

ん？有一条是不是有点眼熟？「deffont size=23」，在关于默认字号的设置后的注释中有以下说明「deffont タグの size 属性に相当」。。。结果不言自明，就是这个在所有剧本前最初进行的全局设置左右了剧本中的默认字号。

这里我们需要注意的是，如果游戏里对于文本有多种演绎模式，例如：

我们便需要对它进行同样的修改

3）UI素材与立绘设置

UI素材

接下来便是对UI素材与立绘数据的修改，为什么把这两个放一起介绍呢？其实笔者最初也认为这两者是不同的。

我们首先来看UI素材的参数，这些文件一般以csv格式（以逗号分隔的表格格式）存放在放UI图形素材的地方，接下来我们以历史记录的界面为例，解说如何处理：

首先用记事本打开 history.csv 文件，内容如下：

不难发现其内容格式整齐，其实就是表格文件，因此我们可以使用 Office Excel 对其进行修改。

左边是每个素材的名称，例如slider就是滑动块，pageup button就是向上的按钮。

右边的参数依次为left;top;width;height；怎么知道的笔者后面会提到，其中left和top表示的是绝对坐标，还有另一种表示形式为：xpos与ypos，坐标原点为画面的左上角顶点。width与height表示的是素材本身的长宽。

既然前文我们将图像素材皆做了（边长）放大到两倍的处理，我们对这些数据同样只需要*2即可。用Excel可以轻而易举地完成这一点。随后我们保存，再使用记事本打开源文件。

我们会发现格式发生了轻微的改变（逗号的标法），这时我们需要将格式复原为原格式，否则游戏在读取时可能会发生无法读取的错误。ps.活用替换功能可以轻松完成这一步。

有的文件可能是动画文件，这时我们同样要对动画文件进行修改，例如如下：

代码很好理解，即「把图像文件以72像素为单位分割，然后以50微秒的速度循环播放」。

完成上述步骤后打开游戏测试：

跟前文的截图进行对比，文本框「恢复」正常，可以在这个分辨率下正常运行。

立绘素材

立绘的数据一般与图形文件在一起保存在fgimage里

这里的txt格式文件是「以空格为分隔」的表格，同样建议使用Excel打开。

这里就非常清晰明了了，从左至右的数据分别表示left、top、width以及height。

详细姐说下表格内容：name一栏前几个有名字的即是表情或是差分，而最后纯数字10即人物背景，当游戏需要表示某个状态下的人物时只需要加载一次人物背景，再变动表情或差分即可，这样既可以提高效率，也可以节省存储空间。

同样的*2处理，注意不要动那四列以外的数据！

而立绘除了在此处有一个参数文件外，在data内还有一个定义文件，即位于main路径下的 charinit.csv 。

笔者最先没有意识到这一点，在修改了fgimage内的立绘参数后便以为万事大吉了，但事实上如果就此打开游戏的话就会出现以下情况：

笔者最初的想法是默认的坐标出现了问题，因为我发现了在 KAGEnvironment.tjs 中有关于角色默认位置的定义：

笔者认为应该有个地方定义了默认的立绘坐标，但顺着这个路线笔者一时并没找到相关线索，于是转而思考另外一种可能：即fgimage内的参数设置错误。基于此调整了半天，笔者发现只要调整第一个空白行的数据即可让立绘恢复，于是便自以为是地迅速将所有立绘都如此处理了。而此时的我还没有意识到这两个数据的含义。

后来在某个主角从天而降的场景中，笔者突然发现立绘的下半身不见了！？

此时笔者恍然大悟，这两个数据其实是设置输出图像的大小，如果设定的数据小于原图的大小便会对原图进行裁剪。下半身被裁剪掉的立绘自然就在画面上下沉下来，显得「正常」起来了。

笔者立马反应过来应该还是最初的思路正确，是坐标影响了立绘的展示，于是再次沿着这个思路思考。

「立绘那么复杂的文件，为什么只有参数文件而没见到定义文件呢？如果不对其定义怎么在剧本中引用呢？」

一个朴素的问题浮现在笔者的头脑中，顺着这个思考，我用主角的名字（即立绘的名称）再次搜索群组文件，果不其然轻而易举地发现了立绘的定义文件：charinit.csv

瞬间感觉最初用ypos之类的关键字尝试搜索半天的自己太蠢了。。。

还是老规矩修改数据，这样操作后立绘便可以正常显示在游戏中了。

4）细节调整

上面的调整只能让游戏的各个素材在游戏中正常显示，而想完美复原原来的演出效果，我们必须对一些细小的地方都进行修改：

例如 envinit.tjs 中对立绘位置（x轴）的定义：

由于分辨率提高，继续维持老的位置的话会让放大后的立绘挤在一起，这里修改的就是对立绘位置的定义。

此外还有剧本中对坐标的指定：

这些如果不进行调整的话演出效果就会怪怪的，建议自己编个程序或者用excel之类的软件批量*2

写在最后的话

理论上通过放大能够对老游戏的画质做出很大的提升，但具体的效果还是得具体问题具体分析，甚至在不同硬件、软件环境下的电脑运行效果都有差异。（最起码在我的电脑上显示效果非常棒！终于不用看模糊的线条+瞎眼的高糊字体了2333

此外修改这些也需要一定的基础，像笔者这种小白一头扎进来，实在是走了太多弯路，算是亲身实践了下桑代克的尝试-错误实验233333

不过有一说一摸索这种游戏还是蛮有意思的，果然本性难易（笑）。

另外我在日本的一些论坛看到有日本网友指出日本著作权法第二十条第三款指出这种修改甚至还是合法的？不知道大家怎么看23333

第二十条

著作者は、その著作物及びその題号の同一性を保持する権利を有し、その意に反してこれらの変更、切除その他の改変を受けないものとする。

2 前項の規定は、次の各号のいずれかに該当する改変については、適用しない。

一 第三十三条第一項（同条第四項において準用する場合を含む。）、第三十三条の二第一項又は第三十四条第一項の規定により著作物を利用する場合における用字又は用語の変更その他の改変で、学校教育の目的上やむを得ないと認められるもの

二 建築物の増築、改築、修繕又は模様替えによる改変

三 特定の電子計算機においては利用し得ないプログラムの著作物を当該電子計算機において利用し得るようにするため、又はプログラムの著作物を電子計算機においてより効果的に利用し得るようにするために必要な改変

四 前三号に掲げるもののほか、著作物の性質並びにその利用の目的及び態様に照らしやむを得ないと認められる改変

直译过来大概意思就是将不兼容的软件修改成兼容，或是为了更加「高效果」地利用程序才进行的必要的改变不构成侵犯著作权。。。反正我觉得也有点牵强

最后再安利下文章中出现的作品——智以类聚，虽然是老物，但在伪娘游戏中可以说是数一数二，长期在批评空间及bangumi霸占前三的位置，由于学业等原因，up的翻译进程比较缓慢，建议有条件的同学一定要去尝试下本作！（最好不要使用机翻哦~毕竟浮夸的语言也是日野亘的风格之一，可以学到一些不一样的日语2333

今后的智以类聚系列可能就会以高清版本继续翻译+录制了，敬请各位粉丝期待~~~~