______________
關于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
更多文章、技術交流、商務合作、聯系博主
微信掃碼或搜索：z360901061
微信掃一掃加我為好友
QQ號聯系： 360901061
您的支持是博主寫作最大的動力，如果您喜歡我的文章，感覺我的文章對您有幫助，請用微信掃描下面二維碼支持博主2元、5元、10元、20元等您想捐的金額吧，狠狠點擊下面給點支持吧，站長非常感激您！手機微信長按不能支付解決辦法：請將微信支付二維碼保存到相冊，切換到微信，然后點擊微信右上角掃一掃功能，選擇支付二維碼完成支付。
【本文對您有幫助就好】元
