KR引擎更改编码显示异常
qtlark opened this issue · comments
概要
游戏名:ひこうき雲の向こう側
参考视频:https://www.bilibili.com/video/BV1m64y187df
实现目标:不转区运行本体EXE
流程
-
提取data.xp3,将所有asd, func, tjs, ks, txt, ini, csv (以及stage, stand特有文件后缀)的编码从shift-js转到utf16 LE有签名,并且在Config.tjs里挂载了路径,在Override.tjs里挂载了CSV插件。最后打包成patch.xp3。
-
运行游戏,正常无报错。台词,人名,语音,BGM,背景图片等等显示正常,但立绘还是显示不出来。但此时转区运行正常。
想法
之前反应的黑框问题是乌龙,是忘挂载路径了。但挂载路径后,就出现了上述的③问题,就是黑框都没了,一片透明。个人感觉是加载到了TLG图片,但是显示不了?不懂,迷惑。
这个游戏封包里非常多文件使用了日文的文件名,一般这种建议直接走forcedataxp3的方法,因为path.xp3并不能很好的替换,当然想一点点把路径修好也是可以的,只是很麻烦。
目前来说你有两个选择
删除立绘控制txt
- 1、所有操作和你上述一样
- 2、把fgimage文件夹下各个人物名文件夹内的txt从patch里删除,比如 fgimage\いろは1\いろは1.txt,这些文件不要放入patch,其它操作一样,就可以正常显示立绘了
关闭forcedataxp3
关闭forcedataxp3,并修改exe中data.xp3字段成其它,比如date.xp3,使得引擎可以从游戏目录下的data文件夹优先加载文件
由于这个游戏data.xp3很大,所以还需要在data/startup.tjs中添加路径把一些资源的读取重新定向到封包中
谢谢大佬,已通过第一种方式解决!
但还是有点疑惑,这种相当于不对立绘txt转码,仍然是shift-js,按道理来说应该无法正常识别,为什么这样反而可以正常工作?
理论上来说无论什么编码,最终都是一串二进制序列,只要没对编码过的数据进行转换,就可以匹配到相应的文件,顶多只是显示出来的内容有问题,内部运行一般是不会有问题的。
然而比较糟糕的是Windows下通常不认为字符串是二进制序列,当然用户程序内部是可以无视编码的,只要你自己不去操作转换字符串(当然实际上很难做到,因为很多库函数也要和系统api交互,不可避免的涉及到编码转换,比如fopen,内部其是调用系统api CreateFile,但fopen的文件名参数是const char*,窄字节编码,那内部必须转换成wchar_t,那你这个const char*是什么编码呢?utf8?sjis?gbk?没人知道,系统直接假设日文语言区域就sjis,中文语言区域就gbk),但和系统api交互还是要考虑编码问题,不过一般非跨平台的Windows程序,特别是老的在用窄字节编码的Windows程序都很难做到这一点,所以一旦编码假设错,轻则乱码,重则直接崩溃。
不过这种情况只发生在调用窄字节api的程序上,也就是后缀是A的winapi函数,显然Windows至少20多年以前就提供了W系宽字符的api,而且其后的A系api也只不过是在内部转换成宽字节后调用W系的API。那些转区软件,本质上就是hook这些A系列的api,然后在内部使用用户设置的编码来进行转换,再调用W系的api,这样就解决了编码被假设错的问题。
但立本人跟不上时代,还在用窄字节的玩意写程序(当然这和Windows也有关系,没有全面推行宽字节编码,现在的vs都还是默认保存窄字节编码源文件),窄字节在Windows上通常会为字符串假定一个编码(对的只是假设,这些玩意统称为DBCS编码,没有任何标识数据来表示编码类型,这种假设编码的行为一部分可以由程序员决定,但系统的A系api,直接假设了编码依据系统语言决定,这就导致了大量使用sjis编码的程序在中文系统下被假设成gbk编码,如果假设的编码是错误的,那么转换出来的宽字符编码(utf16)的字符串也是有问题的,有可能少字符有可能全是问号,比如一个文件名,输入是sjis编码是但以gbk来转换,转换到utf16后,就完全是乱码的状态了,基本不可能通过这个文件名找到对应的文件(当然如果刚好能映射回去,也是可以能的)。
反正这东西就这样的,编码混乱,替换混乱,有些插件还不支持某些编码
所以最好是forcedataxp3从最顶级的data目录来替换文件,让所有编码都统一成utf16,就没这个问题了(当然有些傻x的插件没做utf16的bom检查和支持除外)
感谢大佬解释Orz