搬运自X‘moe Project
快被标题给骗进来吧。 代码萌化=。= 就是叫你装逼，怎么样让弱弱的ONS代码看上去很高端。 这篇教程很短的，其实真正的目的是让你们从ONS脚本到lua脚本能有个过渡。 （会lua、C/C++的别在这里搅乱=。=） 我拿脏翅膀来举例子： b__say “必须要出声求救。”, 0, 0, 1, 1 b__say “可是，耳中却只能听到自己的牙关不停交战的声音。”, 0, 0, 1, 1 b__say “我是如此的无助。”, 0, 0, 1, 1
这个window对话框输出的话 如果换成我们的话，我们一般都会这样写。
必须要出声求救。 可是，耳中却只能听到自己的牙关不停交战的声音。 我是如此的无助。\
就是这个样子。你可以引入一个b_say的函数来做这些。获取的字符串变量直接打在屏幕上。 后面4个参数确定文字的效果及属性。
再来： ONS实际在用的时候是不需要一个个效果依次显示的。我们可以通过“排队”的方式来整合一下：
;multi task structure ;The number of tas ...
搬运自X‘moe Project
真﹒ONScripter吐槽篇。 我从ONScripter教程的第一篇就说了这货是单线程的。但是为什么我还是在发这货的教程呢。 按理说krkr2无论是画面还是脚本系统都比ONScripter先进。 下面的吐槽中我将对比ONScripter和krkr2引擎。 ONS有这么多的用户是这样的。 脚本简单。方便按自己的习惯自定义脚本系统。 语法简单，一看就懂。 最后就是NS引擎历史悠久(不带这种的吧) 所以基于这些理由来说，ONScripter的用户量还是很庞大的。 众所周知，ONS短小精悍。还是基于sdl写的。 然后sdl天生就有可怕的跨平台能力，基于这点优势，ONScripter可以说是没有不支持的平台，这对于游戏移植（开发）者可谓是福音了。 相对于ONS引擎来说，krkr2就过于庞大了。 虽然krkr2优于ONS引擎。但是krkr2从被开发的那天开始，就和win32 API绑在一起，虽然现在那位作者还在努力地实现跨平台，但是很困难，因为是重构。一切都要从头开始。 Krkr2向安卓移植的工程一直在进行中，但是还是没有完成的。我看上去基本上完成了60%的样子 ...
搬运自X‘moe Project
真﹒函数部分 前面第一节提过的。函数需要在define区域使用 defsub 来定义函数名，再在define区域以下的地方写函数的本体。而前面没有讲的是，ONS的函数是接受变量的，放回的是一个过程。 而获得参数需要getparam 指令来实现，参数用半角逗号隔开。 例子：
*define ny_fun game *start *ny_fun Getparam %1,$2 $2 Wait %1 Return
;实际上的调用：
Mov $3,”这是一个函数。”
Ny_fun 500,$3
这样就是函数的书写的函数的调用。
而且ONS不存在局部变量，也就是说，我先把$2赋值，而不是$3也是一样的。 假设我调用时，忘把$3打上去，那个wait指令还是有效的。 关于这种参数少加的bug，ONS一般是没有提示的。
最后一定要有return作为函数的结束标志！
我再拿一个语音播放作为例子吧。 大开发时。我们不可能这样写语音系统的： Dwave 2,”koe/voice/k254/00.ogg”
我们一般用函数。 假设目 ...
搬运自X‘moe Project
放弃了ONScripter，但总觉得还是要做点什么。我不会介绍ONScripter那是个啥，也不会解释ONScripter为什么用户量这么大，或者和NScripter有什么基情。请自己百度或者维基。转载么，你不给我打招呼也得注明个原作者（X’moe Project）吧，码字痛苦。
废话不说了，上教程。本教程就是的目的就是整合ONScripter全部的指令（完全没用的就算了）。
首先我要给ONScripter（下面简称为ONS）一个属性定义：单线程。 单线程就是不能有几个图形或内部操作同时进行的，所以在移植游戏的时候要注意。 关于ONScripter的显示效果：幻灯片。 用户不能进行像素级别的操作，唯一最“高端”的操作就是mask操作。
剩下的就在教程里讲了：
ONS的启动需要 0.txt 或者 00.txt（可以命名到99.txt）或者加过密的nscript.dat、nscript.__ 然后还有一个名字叫什么的。 无视了吧，常用的就是前三种。 还有default.ttf（字体文件，用中文支持的ONS那么字体文件也是支持ONS基于Unicode的 ...
搬运自TGbus
要想成功汉化完一个游戏，首先是要对游戏机有一定的了解，这一节将给大家介绍一些关于GBA的机能资料，一定会对大家是很有帮组的。
一、GBA系统配置 CPU 32位RISC CPU（ARM7TDMI）/16.78MHz 兼容性 集成8位CISC CPU兼容于GBC，但是不能和GBA的CPU同时工作 内存 系统ROM 16K字节（对于GBC是2K） 工作RAM 32K字节＋CPU外部256K字节（2倍周期） VRAM 96K字节 OAM 64位×128 调色板RAM 16位×512（256色用于精灵，256色用于背景 卡带内存 最多32MB ROM或闪存＋最多512Kbit SRAM或闪存 显示 240×160×RGB点、32,768色模拟显示、特效（旋转、缩放、α混合、浅入浅出和马赛克）、4图像系统模式（BG0-BG3） 操作 控制键（A、B、L、R、START、SELECT和方向键） 声音 4声道（相应于GBC的声道）＋2个CPU直接声道（PCM格式） 通讯 串口通讯（8位/ ...
搬运自TGbus
本节介绍几个常见的压缩算法。
（一） 字典算法 字典算法是最为简单的压缩算法之一。它是把文本中出现频率比较多的单词或词汇组合做成一个对应的字典列表，并用特殊代码来表示这个单词或词汇。例如： 有字典列表： 00=Chinese 01=People 02=China 源文本：I am a Chinese people,I am from China 压缩后的编码为：I am a 00 01,I am from 02。压缩编码后的长度显著缩小，这样的编码在SLG游戏等专有名词比较多的游戏中比较容易出现，比如《SD高达》。
（二） 固定位长算法（Fixed Bit Length Packing） 这种算法是把文本用需要的最少的位来进行压缩编码。比如八个十六进制数：1，2，3，4，5，6，7，8。转换为二进制为：00000001，00000010，00000011，00000100，00000101，00000110，00000111，00001000。每个数只用到了低4位，而高4位没有用到（全为0），因此对低4位进行压缩编码后得到： ...
搬运自TGbus
并非需要很多的计算机知识才能够进行程序跟踪，当然要想便捷有效的跟踪程序的确需要扎实的汇编语言基础。许多朋友都是出于个人爱好才接触汉化的，如果一开始进行跟踪就学习大量的硬件知识和汇编知识一定会感觉吃力而对自己丧失信心。其实学习ASM HACK完全可以遵循循序渐进的原则，先使用最简单但比较费力的方法，通过对程序认识的深入再不断改进自己的跟踪手段来提高效率。在这篇文章中我将讲解如何使用比较原始的方法来捕获游戏图片在ROM中的位置，这只是跟踪的第一步，如果想要捕获显示程序或解压程序就需要了解更多的知识才能实现，但这是后话了，让我们先从最简单的开始。
工具软件：
BATGBA模拟器（一款免费的GBA模拟器，带基本的DEBUG功能。对于初学者不推荐使用NO$GBA） UltraEdit（全球最著名的文本编辑器，功能强大，中文界面）
技术手册： ARM指令集手册（ARM是GBA使用的处理器芯片，学习汇编的必备工具书） 几本计算机基础书籍（良好的计算机基础是你进行汉化的必要条件）
其他： 很多很多的耐心和一点点运气
在我们开始跟踪之前有必要了解一下GBA ...
转载自TGbus
翻译完了也整理修改完了接下来就可以考虑把译文中出现的所有中文汉字的字模导入游戏文件里面，如果以前的日文字模都不会再出现的话直接覆盖掉原字模就可以了。多数时候可能还是会保留英文字符、符号、日文平假名、片假名而仅仅是替换日文汉字部分。由于中文汉字数量庞大，一个剧情比较简单的GBA角色扮演游戏少的都有八九百个中文字符，而原始的字库空间有限无法容纳下那么多中文汉字。比如《光明之魂2》原始字库有700个左右，去除英文大小写字母和符号就更少了。对于这种情况我们就必须对原来的字库扩容。
一般的情况下，每个游戏之中总会有部分空白区域，换句话说文件的内容并不一定连续，我们可以适当地利用这些空白，如果这些空白仍然不够使用就可以把新字库生成到原来文件的末尾区域以达到扩容的目的。新字库扩容后还需要修改字库地址的计算公式，很多时候文件中都有一个基址指针，适当地修改就可以达到目的，不过寻找起来有点麻烦，倘若运气好就是一个绝对地址，就像文本脚本的指针一样，这样寻找起来就比较简单了。还有两点需要注意：即便是在游戏末尾添加的字库也不能删除原字库，如果删除了会使字库后边的程序迁移而失去原有功能， ...
转载自TGbus
文本到底有没有导出完？这个问题基本上就是凭经验了，先大体上玩玩游戏，看看游戏中那些地方会出现文本句子。一般来说游戏制作者会把游戏中剧情对话做成一个脚本块；NPC对话做成一块；道具名称做成一块；菜单指令介绍等一块；相关介绍一块……。块与块一般情况下还是分开放置的，所以有时候就得分开查找。例如在《光明之魂2》中文本文字按照出现地点可以分为剧情对话、NPC对话、道具名称、介绍、指令和图鉴部分。运气特别好，虽然这几部分内容是独立的，但都被放在了一起（《光2》程序员BT啊，怪物图鉴部分竟然要做两套内容完全一样的文本脚本，分别对应一周目和二周目。当初我也没发觉这个问题，这也造成当时有很多人说图鉴部分没有汉化的原因）。
文本脚本也是非常之灵活多变的，基本上每启动一个游戏汉化项目就得重新做一次导入导出工具（也不是全部重新来，基本上修改个别参数、某个结构就可以了）。文本脚本在总体结构上可以分为三种类型：顺序结构、指针表结构、跳跃结构。
顺序结构：
这种结构最为常见也最简单，每一个文段都是紧挨着的，段与段之间有一个承接符来表示前一段的结束和后一段的开始。句子有伸长缩短改改 ...
转载自TGbus
在掌握字库修改和编码查找文本修改后基本上就掌握了游戏机游戏汉化的原理了，但仅仅懂得原理也还不够。虽然我们会使用《TLP》《UE》等这些工具来修改游戏，但这些工具的初衷并不是针对汉化设计的，面对如此多的文字内容要一点一点地人工修改，即便是神仙也会感觉到累，因此我们就有必要命令电脑来帮我们做一些规律性的操作（我很嫉妒电脑有光速一般的计算能力）。例如文本脚本的导入导出、中文字库的生成等等。
下个定义：文本脚本——文本内容依照指定的编码所对应的十六进制数字串。例如上一节找到“キャラクター……”的脚本“ 58 00 99 00 78 00 59 00……”。从这一段的特征上我们可以判断出“0058”对应“キ”、“0099”对应“ャ”等等，依此类推就可以得到该游戏的全部文字编码。得到了所有文字的编码后就可以编写程序，让电脑帮我们把这些数字化的文字给转换出来（导出）便于日后翻译，在翻译完后还要利用程序把翻译好的内容导入游戏程序中。文本脚本的导入导出实现的手段相对比较多，如多你稍微有一点编程能力的话还是最好自己编程，毕竟每个游戏都有每个游戏的特殊性（见得多了自然就会感觉到的）。如 ...
