两仪式 发布于三月 10, 2015 分享 发布于三月 10, 2015 セリカ・シルフィル 发表于 2015-3-6 01:17心愿屋已经在收钱了，我表示就笑看有多少人过去送钱。 A社的系统比E社容易解决，外加作品多名气大，拉一大 ... 实际弄一次后你会发现Ｅ的程序远比Ａ的容易搞，Ａ的程序才是真麻烦，而且文本提纯也远没有Ｅ方便直观。不过Ｅ的文本量太大，有出2.0的游戏纯文本基本都有3M了。 链接到点评
两仪式 发布于三月 13, 2015 分享 发布于三月 13, 2015 セリカ・シルフィル 发表于 2015-3-13 07:51我确实是没解决过E社的程序，但情况如何我还是有所了解的。 E社程序里一堆奇怪的设计，不是说能提取文本就 ... 以我个人来看，Ａ从汉化整体进行的角度来说，要比Ｅ麻烦很多很多。 Ｅ的程序、脚本和图片格式都对汉化人员非常友好，而且因为它会优先读取外部文件，测试起来简单方便。 而且Ｅ的程序是属于那种弄好一个之后，后面就能坐享其成的类型。从实现汉化的角度来说，程序本身也没有什么特别麻烦或是难搞的地方。 所以我才说程序压根就不是Ｅ汉化的绊脚石，关键还是文本太多翻译压力山大时间拖得久最终沉迷于新作／舰娘ＬＬ大法／现充最后不了了之。 而反观Ａ这里，System4自采用Asra_framework开始，开始采用自带字库，这里要么自己解析fnt文件后生成个新字库，要么修改程序调用使用GDI渲染字体，而选择后者的话意味着需要要进游戏对照实际屏幕显示的字的大小去微调jaf文件里面为数不少跟字号有关的参数设置。 而且Ａ的程序只会读封包不会读外部独立文件，所以得自行写直接对封包操作的工具来测试完成后的图片，当然这也算不上是什么难事。 不过最麻烦的果然还是脚本汉化这一块，不像Ｅ的脚本简单方便直接从bin里面抽取就是，Ａ的脚本是包含代码的jaf文件，剧情相关的文本可以通过自行编写工具来分离提纯文本，但是系统相关的文本只能靠人去一个个查看文件和修改，而且一些特定的系统文本的修改，比如说人名，会直接影响到立绘、ＥＸ、模型等文件的读取和函数的调用，哪些系统文本内容可以独立修改哪些需要统合外部其他文件修改这都是需要程序员探明的。修改jaf导致的出错不像Ｅ的程序直接弹出个框告诉你XXX.bin的XX地方有问题那么简单明了。 最后就是Ａ的程序员比较累。像Ｅ的程序，每次的新游戏也就ＥＸＥ里加若干新操作码完事，基本框架和脚本和图片和封包格式万年不变，Ｅ的程序员可以偷懒到飞起。而Ａ的游戏不但每次都会换点新东西（比如４月新作的体验版里旧封包格式ALD彻底消失了），同时每次换个游戏都需要再走一趟大量修改jaf和其他文件的流程，很烦。 所以从汉化难度来说，果然还是Ａ远远甚于Ｅ。 链接到点评
两仪式 发布于三月 13, 2015 分享 发布于三月 13, 2015 八雲 七罪 发表于 2015-3-14 00:49A社有通用解包封包工具，还自带全脚本解析；E社呢，这么多年只看见了解包工具。 既然没什么难度，还望大神 ... 我上面所说的不难是从实现汉化的角度来说的，要实现汉化只需要弄明白跟文本有关的操作码即可。而写脚本解析器可是要把500多个有效操作码全部解析出来，这个工作量和仅为实现汉化而做解析的工作量不可同日而语。 而且我帖子的本意是希望大家不要被E的程序难这种观念先入为主，从而错误的对E社程序产生一种恐惧感。一些潜在的对E汉化有兴趣的人很可能会被E程序难搞这种错误的说法害得早早就放弃了尝试的想法，我觉得这是非常遗憾的事情。 链接到点评
推荐贴