浅谈火红叶绿汉化中的培育屋BUG

K.SKT

万分感谢阁下，这才是技术力爆表的本格的原创研究。
而技术力全无的本人表示遇到这类问题，也总是会去找一些野路子，仅此而已……实在是有些东西所以简单说说……
倘若是基于反编译汉化的话，个人如同白痴般単純的解决思路无非就是换版本找答案，即使没有GF给出的友情解决方案，没有这个问题的PokeEmerald之中的函数名和功能也与PokeFirered大同小异，几乎连调整都不用就可以简单的复制粘贴就可以搬过来。


（当然以上只是个人野路子，对其中的原理真的一无所知……
不过古早接触汉化时因为D商ROM的本身空位安排布局的和压缩文本空间的特殊性，所以养成了一律FF填充后改指针的习惯，估计乱搞规避掉这个BUG的可能性也不是没有……）
但是遗憾的是，个人在印象里的D商汉化貌似是没有这个问题的。为此还测试了一下，也暂时并未在其中发现同类问题……
（毕竟继承了衣钵，也算是稍稍地为师父正个名了）。
（不知道GIF能不能看，姑且就这样吧……）


配合文字转换工具和CT反查到D商的那串字符（「返回前面！」）位于083DD871这个地址，上面还一样附带了那个「是\n否」……
使用無料GBA单刀直入直接打开玩家电脑界面断点是成功的。但重复在培育屋的一系列对话之后始终没有触发……






（怀疑是D商和POCKETSTARS SP一样修改了文本指针。阴差阳错地去掉了这个BUG……
原版日版倒是还没确认，等有时间确认一下……）
另外，顺手还看了下日版FRLG源码中的「sodateya.c」，虽然本身各类函数命名与排布同PRET项目相差甚远，不过也有幸找到了疑似同款函数（毕竟就是英文版「准确地来说可以被叫做英化版吧……」前身）。


构造貌似应该是与英文版1.0类似，理论上也应该是有这个问题的。但不知为何，基于日版汉化的D商版其实貌似是没有的，且中间也没有发现添加00空位的痕迹……
最后一句，个人所说的这些只是一些废话而已，过于深奥的技术与汇编层面几乎可以说是一窍不通。见笑还请见谅。
以上。

K.SKT

卧看微尘 发表于 2023-9-11 10:42
我想想，说d商版是因为当时在群里讨论时，有一位小伙伴提及10年的时候也遇到过卡死问题，那个时候新汉化 ...

感谢阁下对于这个问题的进一步研究。另外有了些个人而言的一些稍稍有点价值的新发现……不过毕竟本人经验技术力相对而言不足。如有错误还请见谅
冒昧跟阁下稍稍讲一下，个人查出的具体地址貌似是0821C2B2，与阁下的地址相比稍微差了两行……不过区域也大致在附近，证明阁下的发现是对的……


当然可能也是本人出错了，技术不精，如有错误还请见谅。另外本人没有用断点的方法，而是直接查看的代码（因为前者对于汇编知识的要求，就技术力全无的本人而言实在是無理），前面应该有一串与之相并排的「やめる$」的（PRET项目里「$」就是FF了，不过原代码里是用「_EOM（End Of 文字【もじ】，相当于PRET中的EOS【End Of String】）」这样的一个名称表示）。




发现这两者外加一个换行键貌似被写在了一起……所以文字一转换就很容易地被查出来了……
把得到的地址反拿回到D商版，更令人驚奇的事情出现了，D商竟然漏翻了这个「やめる$」……这也就导致了两者在这一块的文本是一样的……

拜读完阁下的回复后，本人顺手做了个小实验（既然文字都一样，就用了D商版，因为毕竟串不了档），首先把后面补的这个00，也就是阁下认为的中止判断大胆改成了FF，其目的无非就是来测试ROM会不会出现显示上的BUG……


结果并没有发现ROM存在数值溢出问题。文字显示也很正常。


另外再将前面的FF改成了00，倒是发现先前的文本起了变化。说明在日版中，不出意外的话，起到中止作用的是FF，而不是00。




最后把两个数值都改成了00，虽然没有出现溢出问题，但文字显示还是不正常的……




经过上面这一番简单的验证，个人猜测不会日版的strcopy不会就是和PM_TextPrint（也就是所谓的StringCopy）一样仅仅用FF判断中止？（虽然从常识来看纯仮名字里行间必须要空格隔开要不真的是全然），且本身英文版文字显示系统相较于日版进行了非常大的修改，如此涉及到ROM底层修改专业的问题，技术力全无的个人是无法解决和深究的。
再其次，就是版本的问题，这里没有质疑阁下的意思，不过十年前倒推的话，现在通行的新汉化FRLG，应该已经出来了说不定，毕竟POKESTAR的新汉化FRLG最早应该是2012年4月发布的，也就是2011年暑假绿宝石新汉化出来约大半年之后。现在算来，也已经有10年了。不过个人印象里火叶是没有和绿宝石一样以「口袋妖怪」为标题的汉化版本，实在是可惜了。
第三世代的FRLG的话，个人手里也属实是有收集好几个DUMP出来的其他版本，但归根到底，都是D商从日版为基础汉化出来的。本身就是同一版本，但由于应该是出自不同的卡带，大的不同虽然没有，小的不同应该是有的。袁叔叔的加密壳在GBA领域是出了名的黑科技。各位卡商魔改或是碰到了什么底层机制也不一定……要不然就没有诸如当年绿宝石有一部分卡带坐船死机，而有一些卡带却正常这样的事情了……
这些非常见的D商汉化版本，多数是OVERDUMP以及存在各种BUG的BADDUMP（有一个版本连精灵查看界面打不开……选择即黑屏，而印象里某个版本的叶绿性格是未汉化的乱码等等……），另外大约是一两年前在某论坛还找到了内销转出口的海外特供版D商英化叶绿和英化蓝宝石（之前看到过资源吧那边有人搬过D商英化绿宝石，也就是大名鼎鼎的Chinese Emerald），然而貌似都是32MB的OVERDUMP，且连档都存不了……


等个人之后有时间的话，也许会具体尝试，至于其他的版本，恕本人见识真的不多，认知水平有限。是真的没有再见过了。
最后，个人也去看了一下PokeRuby，发现正如阁下所言，变动相对较大，但其实在分函数里貌似好像也是用到了StringCopy这个函数的……






我个人没有具体测试这两个函数的効用，根据英文名称和结构推测应该是负责显示精灵列表中的昵称和等级，不过仅仅只是本人的猜测……至于「LV」这个字符是如何显示，个人理解是dest附着的数值之中，这一过程与FRLG和EM不同，其实就是从操作数据方面着手，直接输入代表LV这个字符与空格的数值。和日文版在数量词后面显示诸如ひき和こ之类的単位貌似是同一个道理。对照Charmap.txt查看一下，也许应该就相对明显了吧……


最后，以上全部只是本人的猜测和个人略微的一些単純的思考，仅此而已。如有错误，真的还请见谅。