______________
关于NScripter的Android版移植：
ONS和SDL：
大家都知道，日本人高桥直树是NScripter项目的发起者。
然而，事实上高桥直树开发的原始版NS程式早在09年就已经停止了更新，现今已很难再看见利用原版NS开发的程式。那么，NS为何还能有现在这么庞大的用户支持率呢？答案很简单，一切都要归功于ONS的存在。应当说，目前应用最广，也是真正让NS脚本发扬光大的，还要数第三方制作的ONScripter，这一完整支持NS脚本的跨平台AVG引擎不可（简称ONS，以下同）。
单独从编程角度上讲，ONS不等同于NS，由于高桥氏开发的NS程式并没有开放源码，因此ONS是通过黑盒方式参考NS效果自行模拟出的ONS功能（这个过程有点像制作游戏机模拟器），所以它并不是一个代码移植品，而应视同一个独立于NS原版的新型NS脚本解释与执行器。除了能解读同样的游戏脚本外，它与 NS就没有任何程式上的继承关系。
ONS相比较NS的最大优势在于，ONS和完全依赖DirectX渲染仅支持Windows系统的NS不同，它采用了一代神人Slouken制作的SDL框架进行脚本与计算机设备交互，天生具备SDL框架“骇人听闻”的跨平台移植能力。
无论是windows、linux、mac抑或PSP、PS3、PS2gs乃至wince、iphone、ipod、android平台都能看到它活跃的身影（当然，这需要相关的本地运行库配合，比如从渲染角度上讲，在Windows绘制画面既可以使用SDL提供的DirectX封装又可以使用OpenGL 封装，而到了Linux环境就只能使用OpenGL库，到了智能机或者掌机环境就要转到OpenGLES库，这些都必须有人提供相关的本地化封装，然后才能通过统一的API进行调用。即便所写代码在API层面高度一致，但在不同环境中的具体实现依旧是有差异的。也就是说，如果某个平台并没有必要的运行库支持，那么SDL也无法在该平台编译与运行。而SDL的强悍就体现在，它所提供的本地运行库相当完整，几乎涵盖了所有主流系统，兼容性却又相当优异）。
凭借这种优势，目前大家所见的，绝大多数使用NS脚本开发的AVG游戏（或者狭义的指galgame），大多是以ONS而非原版NS作为运行环境——在掌机和智能机上尤其如此。
可以说，没有SDL的成功，就没有今天的NS（ONS）的辉煌。
这里吐个槽，前一阵小弟在某书店读到某Android教程，其中以NDK5编译了某版本的《雷神之锤》，而后就反复强调NDK移植C/C++游戏是多么方便，多么简单之类的。小弟以为，这种说法实在有些忽悠了。众所周知，网上能找到的开源版《雷神之锤》（
http://www.libsdl.org/projects/quake/
），使用的就是SDL这个目前世界上兼容性最强的跨平台引擎（而SDL子项目
http://libsdl-android.sourceforge.net/
，早已提供了SDL与Android设备的完整交互支持）。因此，即便NDK5能正常编译SDL开发的游戏，也只能证明NDK5的基本功能正常（Android好歹也是Linux核心，如果SDL在上面都跑不起来，让Google情何以堪啊），却无法理解成NDK开发有多么便捷，更不能代表所有 C/C++游戏都能轻松移植到Android环境当中（
此前小弟曾和某友谈及怎么常有人能把DOS游戏移植到Android环境中运行的问题，小弟在此粗谈两点：一、世上有个开源项目叫DosBox，能够跨平台模拟标准DOS运行环境。二、DosBox是以SDL为核心开发的
），就别提完全取代Java开发模式了。
我们登录
http://onscripter.sourceforge.jp
，就可以获得关于标准版ONS的详细介绍与各版本下载路径。
至于ONS-Android，则是由ONS作者提供的，完全实现了ONS功能的，专门用于跑在Android平台的ONS版本。如果您要在Android上进行NS游戏移植，首先就离不开ONS-Android的下载与编译。
ONS-Android的编译：
ONS-Android的编译，仅需要如下步骤就可以做到。
1 下载SDL的Android版扩展库
由于标准版SDL源码包中尚未包括Android本地化支持，所以我们需要单独下载Android版SDL源码包，才能在Android环境中正常编译与运行SDL程序。事实上，所有想使用SDL以C/C++方式开发Android游戏的用户，也会需要这个SDL运行库的支持。
下载地址：
http://libsdl-android.sourceforge.net/
（PS： ONScripter-Android内置已是这个运行库，不必真正下载，此处仅说明来源）。
2 下载Android版ONScripter
下载地址：
http://onscripter.sourceforge.jp/android/onscripter_android.tar.gz
由于ONS-Android采用JNI方式，进行C/C++部分与Java部分的交互，因此下载后的源代码也就同时包含了java（功能集中在游戏载入，界面初始化与JNI调用）与纯C（sdl-android支持库）两大部分的源码。
不过，真正解释执行NS脚本的ONScripter本体（C++实现）这时却并没有包含在内（估计是作者考虑到ONScripter核心代码是所有平台共通的，才没有直接放入ONS-Android当中）。
现在，我们还需要下载ONScripter的核心源码部分，才能真正进行ONS-Android编译。
3 下载标准版ONScripter
下载地址（也可选其它版本）：
http://onscripter.sourceforge.jp/onscripter-20110619.tar.gz
好了，编译ONS-Android的要素全部齐备了。
现在，将最后下载的ONS核心源码解压，并放入onscripter_android的jni\application文件夹下（建议解压时不要改名，因为 ONS的Android.mk配置里默认就是编译onscripter*下文件，改名很可能导致找不到目标文件（除非您重写了Android.mk配置））。
这时，我们只要通过NDK编译onscripter_android项目，就能立刻得到相关的so文件了（累计将编译出九个文件，其中只有libapplication.so为ONS运行库，其余为SDL支持库），相当之简单吧？
下图为通过Cygwin在Windows中编译ONS的画面。
可以说，只要系统环境设定正常，原始ONS-Android配置已可保证编译成功。假如在编译时提示找不到某某文件，则说明环境变量中缺少必要的系统支持库路径，并非onscripter_android源码不全，请自行在Android.mk添加相关路径或者修改Cygwin环境配置，具体请参考NDK开发文档或Cygwin使用文档（当然，直接Ubuntu编译最简单）。
编译成功后，获得的so文件列表：
有了so支持库与Java代码，任何稍有Android（或Java）开发经验者，都能轻易将NS游戏运行于Android系统之上。
ONS-Android的汉化问题：
出于众所周知的原因，ONS-Android默认并不支持中文编码（它是日本人做的）。这样的设计，在使用原版ONS-Android运行日文游戏时并不会有太大问题（只要该游戏没有调用第三方插件，没有使用额外API）。但是，一旦我们想要让它跑一些经过汉化的中文编码游戏呢？显而易见，肯定会造成乱码的出现。
所以，如果我们想要ONS-Android能够正常地进行中文游戏显示，在进行ONS-Android编译时，便需修改其部分代码。更准确地说——是修改位于ONS核心包下的sjis2utf16.cpp文件来解决这一问题。
总体来讲，ONS的字符解码过程并不复杂，sjis2utf16.cpp中仅有initSJIS2UTF16（初始化解码表到sjis_2_utf16这一数组中）、convSJIS2UTF16（转化日文编码SJIS为UTF-16编码）、convUTF16ToUTF8（转化UTF-16为UTF-8编码）这三个函数在起作用。而ONS的所有字符解码部分也会经由调用convSJIS2UTF16和convUTF16ToUTF8这两个函数产生作用（注意，initSJIS2UTF16是sjis_2_utf16变量初始化赋值时使用的函数，仅会在ONS启动时调用一次）。
知道了这些，解决汉化问题就变得非常简单，只要根据现有的ONS解码规则，将其sjis_2_utf16_org数组中的SJIS日文编码表转化为我们需要的中文编码表（GBK也好，Big5也好，原理都一样，一个指定编码对应一个相对的UTF-16编码，然后以二维数组形式保存），就能够非常轻松的实现 ONS中文解码，甚至不需改写任何逻辑代码（如果有某些字符需要特殊过滤，也可以修改convSJIS2UTF16和convUTF16ToUTF8这两个函数进行拦截）。编码表较大，下文有相关下载地址。
当然，如果我们想保留原版sjis2utf16.cpp内容也没问题，大可以新建一个gbk2utf16.cpp之类的文件，让两套解码器并行存在，按需求进行切换（比如想根据手机环境自适配字符解码器）。怎么做呢？粗读ONS源码我们可以发现，它实际调用到字符解码器的部分，仅集中于DirectReader.cpp和 ONScripterLabel.cpp、ONScripterLabel_text.cpp这三个源文件当中。具体的说，在于DirectReader 中的convertFromSJISToUTF8函数（其中同时调用了解码器的convSJIS2UTF16与convUTF16ToUTF8函数。 PS：该文件中还有convertFromSJISToEUC函数，是给资源文件名解码的，如果文件名中没有稀奇古怪字符的话原则上可以忽视不管，如果有的话也需要进行适当修改），以及ONScripterLabel_text.cpp中的drawGlyph函数（调用convSJIS2UTF16）和 ONScripterLabel中的initSDL函数（调用initSJIS2UTF16）。如果想自适配解码器，只需创建出相关的解码用函数（放在 gbk2utf16.cpp、big52utf16.cpp随便什么中原理都一样，改个编码表而已），继而通过最简单的if……else……判定即可（如果想根据编译环境判定，直接#if defined也行）。
总之，ONS中文解码并不是什么复杂的问题，汉字编码表可以去
http://unicode.org
查询，或者参考Emacs项目提供的map文件（下载一个Emacs，解压后它的etc/charsets文件夹下全是后缀为.map的编码表）。还有，很久以前有人用google code发布过ONS的gbk解码版本（
http://onscripter-cn.googlecode.com/svn/trunk/
），有需要的朋友可以从svn下载过来参考。
ONS-Android的运行机制：
单从Java编程角度来说，ONS-Android的结构可谓非常简单，开放给用户的仅有Audio.java、DataDownloader.java、 GLSurfaceView_SDL.java、ONScripter.java、Video.java这五个Java文件而已(因为具体实现是 C/C++的)。其中Video.java最为重要，它包含有DemoRenderer和DemoGLSurfaceView两个子类，这不单是ONS- Android的渲染核心，而且包含了nativeInit, nativeInitJavaCallbacks, nativeDone,nativeResize,nativeMouse,nativeKey等六个jni接口。其中最主要的接口是 nativeInitJavaCallbacks以及nativeInit，只有执行了这两个jni函数，才能真正启动ONS（本质上是先启动SDL框架，附带唤醒ONS）。
而执行nativeInit函数时需要注入的地址字符串，默认来源于 ONScripter类下的gCurrentDirectoryPath这个静态变量。不管我们往gCurrentDirectoryPath中放入什么字符串，默认情况下ONS都会按照这个字符串去读取/保存游戏资源（如果不能找到该路径，则ONS会立即崩掉）。
至于其它，nativeDone是关闭SDL（由于ONS依赖于SDL，所以这些操作实际上都会先执行SDL部分，然后才转到ONS部分，以下同），nativeResize是改变SDL画面大小，nativeMouse触发SDL屏幕操作，nativeKey触发SDL键盘操作，皆属基础操作，并没太多好讲解的。
PS：上述部分jni源码位于
onscripter_android\jni\sdl\src\video\android
文件夹下，如果要修改Java类名或接口名，请注意同时修改相关C代码。
而 ONS-Android的启动用Activity是ONScripter类，其中真正调用ONS运行的只有runSDLApp这个私有函数，至于 runLauncher及runDownloader函数一者为要求游戏用户选择ONS资源所在路径，一者为通过网络下载ONS游戏资源，都只会在 runSDLApp执行前调用，也不会实际触发jni接口（只有runSDLApp触发jni操作）。所以，如果您不想让游戏用户使用您的APK启动其它人提供的游戏资源（也就是不想被人当模拟器用），则可以删除runLauncher函数，或者固定gCurrentDirectoryPath变量中路径字符串即可。
再者，游戏初始化后默认显示于画面右侧的仅仅是Java编码的ONS操作按钮（如ESC、Skip 这些），它们仅会通过JNI方式调用相应的SDL API，而不会真正影响C/C++实现部分。因此，如果您需要改变它们的显示位置，或者进行删除、修改这些按钮的操作，乃至用其它方式彻底替代它们（比如将相关JNI调用放入Menu中，按下菜单键时才起作用），都只需修改相关Java代码即可，无需改变任何C/C++部分。
另外，通过解读源码我们可以获悉，在ONS-Android初始化运行时，有三种文件必不可少。
一是脚本文件，它可以命名为0.txt、00.txt、nscr_sec.dat、nscript.___、nscript.dat这五种名称中的任意一种（后三种都属于NS的dat文件包，需要通过工具打包，网络有下载），但除此之外的名称一概不认，没有则无法运行游戏。
二是游戏资源文件，也就是NS中使用的arc.nsa，游戏中使用的音频与图像文件强制要求打成此包（NS提供有打包工具），并且保持此名称不变，否则ONS还是不认。
三是default.ttf，也就是字库文件，由于ONS-Android默认情况下不能使用Android字库，所以此文件必须存在，并且正常可读（必须能够被SDL识别），否则游戏会强制退出（没错，如果字库不存在或者读取异常，ONS直接就崩了~连错误都不报～）。有了上述三种文件，ONS才能在 Android中正常运行。
最后，虽然AVG游戏通常需要较大的音频与图像文件支持，Android版ONS默认要求将游戏资源文件保存于SD卡中。但经实测发现，如果将gCurrentDirectoryPath设定为其它可读写目录，只要上述三文件正常无误，ONS-Android一样能正常运行（比如APK的Cache文件夹）。所以，如果我们想对游戏资源作一些手脚（在内存而非SD卡中进行游戏什么的），完全可以根据此特性入手。
ONS-Android的运行效果：
真机运行效果：
模拟器运行效果：
(虽然ONS-Android默认使用GLES，可惜Android模拟器默认只支持PixelFlinger，因此建议真机测试，否则速度相当悲剧)
关于Krkr2（吉里吉里2）的Android版移植
谈完了ONS的移植，下面再来谈谈Krkr2这个著名的AVG引擎（其实，主要是做galgame～）的Android移植问题。
那么，开章明义，大家请首先注意好这一句话：
在Android中“直接运行”Krkr2游戏是不可能的
虽然仅就Windows系统而言，Krkr2游戏量远远超过NS游戏在这一领域的数量。并且Krkr2系统无论在操作方式、画面效果、脚本功能都较古老的 NS系统更为先进。然而，以下三点因素却决定了在Android系统中，向ONS那样直接运行Krkr2游戏资源将非常难以实现（其实任何系统都一样）。
一、首先，ONS源码不算SDL支持库，其大小仅有1MB左右，可谓短小精悍。而Krkr2呢？ 仅core包下核心源码就有将近10MB，代码量比ONS多了将近10倍（还不算plugins包下的一些必要插件），仅此一项就让移植Krkr2比移植 ONS所面对的工作量大了许多（代码越多，出Bug的机会也就越高）。
二、其次，ONS直接使用SDL框架开发，令它先天具备相当强大的跨平台特性（前文已述，SDL纯C打造，正宗的“一次编写，随处编译，随处运行”）。反观吉里吉里，W.Dee独立开发的 Krkr2核心显然没能达到SDL的高度，他在开发之初甚至就没考虑过跨平台的问题，因此要将它跨平台移植时所面临的问题也就可想而知。
比如Krkr2默认使用DirectX而非OpenGL，又不像SDL那样为每个平台都制作了必要的自适配图形接口，导致它的渲染功能被绑死在 Windows平台上，如果要移植只能重写渲染部分不算；最要命的是，它还大量使用win32 API，先天与Windows系统难以分离，否则很多效果都要从头摸索如何实现；并且，Krkr2还非常随性的提供第三方接口，毫无原则的允许大量第三方插件跑在Krkr2之上，直接导致很多游戏根本不是仅仅解决Krkr2运行环境就能够移植的。事实上，如果想让Krkr2正常运行在非Windows平台，没有相当大规模的代码重构（注意，是重构，而不是简简单单的修改），根本不可能实现（总不能在Android上跑个Windows模拟器吧|||）。事实上，Krkr作者为解决跨平台问题，自2005年起已着手制作Krkr3，至今依旧努力中……
三、最后，Krkr2基本结构是由一套C++核心（含基于DirectX的图像渲染部分及tjs脚本解释器与kag脚本解释器以及其它功能的复合），一套tjs 脚本库（依赖C++编译出的解释器运行，Krkr2特有的脚本语言，语法类Java），以及一套构建于tjs脚本及C++代码之上的kag脚本库（与 NScripter类似的命令行脚本，通过TJS脚本解释器与KAG解释器混合执行）这三大部分组成。
简单点说，Krkr2在核心程序上运行着两个有嵌套关系，但关系又不那么紧密的解释器，以一种不完全的，近似于模拟器上跑模拟器的形式存在着。虽然这种方式在 Windows环境中运行AVG游戏，甚至更复杂一点的游戏（比如RPG）都不会存在太大问题（现代CPU的速度优势）。然而，一旦迁移到手机或智能机环境中，这种方式所带来的后患将相当严重，庞大的资源损耗，将直接影响程序的运行效果（没见过模拟器跑模拟器多恐怖的朋友，可在Windows系统下运行 android 3.0模拟器体验类似的“速度感”PS：题外话，Android模拟器截至到3.0为止，在PC机上的运行速度一直逆增长，版本越高速度越慢，用 android1.5反而会比3.0快很多）。
综上所述，大家应该可以发现，如果想完整移植Krkr2游戏的运行环境到Android系统当中，将会是一件多么费力，而且很可能未必讨好的事情，就算有高人能完整的重构整个Krkr2项目到Android系统，最终也未必会在Android系统（或其它什么智能机平台）跑出“人类能够接受”的游戏速度来。
更简单的讲，完整移植Krkr2的难度相当之大，没能力者肯定做不到跨平台完整移植Krkr2。而某些有能力者呢？大约也没人会穷数月乃至数载之功，一丝不苟得做完Krkr2的完美移植，却平白开源出来给不相识的人免费使用（特别是原作者都没做到跨平台的时候……）。
所以，想和ONS一样近乎不改变任何游戏资源，直接在Android上运行现有NS游戏的美梦——是绝对不可能实现的。
在Android中实现Krkr2游戏移植是可行的
事实上，如果大家曾注意Android Market的AVG游戏动向，就会发现除了ONS的移植作品之外，还会有一些其它形式的AVG移植作品存在。但是，如果我们解压其APK，却很难发现诸如nscript.dat、arc.nsa这样明显的，和原版游戏同样的资源包存在。
那么，他们是怎么做到的呢？很简单，他们所采用的手段是真正意义上的游戏移植，而非ONS那样近似于游戏模拟器的重构了整个NS运行环境。
以Krkr2游戏移植为例，目前Android市场上可见的吉里吉里移植作品，大多仅仅模拟出了最容易实现的KAG3脚本部分，而无视TJS2脚本的存在，至于相应功能，则使用LUA脚本替代或者直接Java编码补全。
这样做虽然远没ONS移植省力，但在Krkr2运行环境几乎不可能在智能机完整再现的如今，也总比自己强行重构Krkr2，再来用它运行游戏要高效得多了。
——至少目前已知的，所有Krkr2游戏的Android移植项目，都是这样开发出来的。
而下文介绍的KAS项目，就是一个非常典型的Krkr2-Android版移植实现。
项目地址：
http://studiomikan.net
源码下载：
http://studiomikan.net/kas/
KAS参考Krkr2脚本实现，可以部分支持KAG3脚本（标准KAG脚本命令大约有150个左右，截止到6月23日的KAS中实现了不足1/3，而且完全不支持TJS脚本），脚本命名方式同样是.ks为后缀。
PS：突然发现一篇博文不可能写全，所以紧急收笔，有时间小弟将单独介绍KAS。下面是小弟贴出的一个KAS中TagHandlers类（翻译后的），其中包含了KAS目前所支持的全部标准KAG指令，另外下文有部分翻译后的KAS项目工程下载地址。
*****************
*****************
此外，KAS默认的屏幕大小为800x450。
作者给出的效果图：
模拟器效果：
（KAS采用Canvas渲染，在模拟器与不支持硬件加速的手机中速度会比ONS更快，缺点是Canvas在图像缩放时画质损失较大）
改变KAS的Util类中布尔值debug可以设定是否开启调试模式（原版默认为false，小弟修正包中默认true）
对了，在iPhone下有同类项目Artemis Engine，两者功能上基本一致（都是仅支持最基本的KAG脚本，与标准Krkr2最典型的差异是不能识别TJS文件以及不支持@iscript标记，也就是都没有提供支持TJS脚本解释器），有兴趣的朋友可以看看。
如果原版ONS或KAS运行时出现问题的话（比如无法直接显示游戏画面），也可下载小弟提供的修正版本（加入NS资源打包工具，给ONS加上了编译好的so 文件，修正成可读取assets文件夹下游戏资源（注意读取assets目录下压缩文件的大小限制）。给KAS加入部分中文注释，修正了原版的 Canvas设定，真机上大约比原版快12FPS左右，在画面缩放时稍微比原版清晰些）。
下载地址：
http://download.csdn.net/source/3516651
