年末因為發現好像很久沒有上巴哈了、
現在趕快來清個草發篇文，順便作個近況更新。
之前的大學修課修的比較勤，所以都沒什麼在推進度。
直到國外研究所申請完過一個學期結束、慢慢掌握這邊的生活步調後，
才開始慢慢推以前的坑。
已經很久沒有碰 RM 了，引擎都已經從 XP 出到 MV/MZ 、
如果再不換引擎真的就滿過時的了，
之前還立過 flag 說不換引擎就懇請鞭小力點 XD，
但老實說又不想放棄 RMXP 美好的地圖編輯器（是說 VX 那個我到現在還是沒有搞懂怎麼畫），
於是我近期把 RMXP RGSS Runtime 換成用 VXACE 的，
這樣有幾個好處：
- RMXP/RMVXACE 的程式碼都能夠被正確的執行。
- RMVXACE 的一些擴展庫也可以被使用。
- Ruby 1.8.6 -> 1.9.2 官方說明效率 5x faster。
- Graphics FPS 從 40 -> 60 （雖然 XP 本身就可以直接調整成 60 FPS 就是了）。
- Screen resolution 能自由改變。
- 私心最想要的 RMXP 編輯器還是能繼續使用。
唯一一個小缺點就是改成 VXACE Runtime 之後就不能用 RMXP 內建的加密功能，
不過我本來也不打算用，畢竟好幾年前就已經出現過傻瓜解密器，再繼續用感覺頗問號。
於是用好之後開始推進度，像是劇本大綱 refine 成一節一節的對話、
選單介面素材輸出、人物戰鬥動圖（認真覺得這個最花時間最不想做，但又不能不做 
）。
）。本來每天都開開心心的推一點進度，
結果居然被我發現到了一個神物：mkxp，
真的是脫離 R 屆太久了，原來早就有人不爽 RMXP 低效能，
直接把整個 Runtime 重寫並且 Open Source 出來。
主要的用法就是直接把它 pre-built 好的 binary 放到遊戲專案目錄底下執行（也可以用 command line 額外傳 argument 指定遊戲目錄就是了），或者有辦法的話也可以裝好 building dependencies 自己 build 一個 RMXP Runtime 出來。
使用 mkxp 的好處有：
- 底層的 window, bitmap, viewport 等類別全部用 C 重新實作，效能加速。
- 支援 RGSS 1/2/3 。
- 用 OpenGL 來繪圖提升效率、甚至可以自己去改 shader。
- 可以同時支持 Linux/Mac/Windows。
- Ruby 版本採用 2.0。
- 支持原本的加密格式。
- 開放原始碼，能自己添加想要的功能再編譯。
⋯⋯
RMXP 原本的 Runtime 沒記錯的話似乎全部的繪圖都是丟給 CPU 做，
加上單線程，所以效率真的比不上其他遊戲引擎。
雖然一般簡單的 2D 遊戲是也不需要多大的運算量，加上現在硬體設備的提升，
即使單核應該也沒什麼問題，但是如果可以將繪圖處理 offload 到 OpenGL 用 GPU 幫忙繪圖，
Sprite 精靈類應該可以再更瘋狂地被使用，同時可以做到一些 OpenGL 支援的繪圖效果。
另外雖然 Ruby 2.0 的語法在字串處理上改滿多的，
但是 Semantic Versioning MAJOR 更新通常是有重大改進，效能一定比 Ruby 1.X 要好。
真要說他的缺點大概就是沒辦法用 Win32API 做一些 Windows 平台上的騷操作功能，
但如果已經有專案原始碼了，如果有什麼新的底層 feature 想要添加也可以自己加然後 compile。
然後我就又繼續 survey 了一下，其實還有另一個 Open Source 的專案是 fork mkxp 叫做 HiddenChest
它直接把 Ruby 版本更新到 2.6，這個效能又比 Ruby 2.0 快更多（詳細參考這裡）。
感覺認真追都追不完，決定停損在 HiddenChest 就好，再查下去感覺又會蹦出了什麼神奇的東西。
有嘗試把 HiddenChest 專案下載下來自己 compile 是可以 work 的，
但目前還是決定先繼續使用 RMVXACE Runtime，有多餘的時間在整合 HiddenChest 進來。
以前的時候還不覺得使用 RM 默認的 script editor 麻煩，
但後來發現每次同一個地方要稍微修一點小地方（尤其是在寫選單介面的時候）就要： F11 開啟 script editor -> 切到你要的 script -> 找你要修改的段落 -> 修改 script -> 儲存 -> F12 執行遊戲 -> 確認效果，這個流程有夠長⋯⋯
所以後來我把全部的 script 都 export 到外面，遊戲執行的時候在 import ，
如此一來所有的 script 可以變成用 rb file 的形式用別的 editor 打開。
像我就喜歡用 Visual Studio Code，還可以裝 extension 幫忙自動縮排之類的，
同時我額外寫了一小段 Ruby script 用來監聽我的 rb file 有沒有被改動，
一旦有被改動就幫我重新啟動遊戲。
這麼做的好處是：
- 修改同一個地方的程式碼流程被簡化成：修改 script -> 儲存 -> 確認效果。
- 能夠得到你 editor 支持 programming 的好處（ex: 額外的插件）。
- 可在最後打包前用 obfuscator 保護 script，就算 dump memory 出來也會拿到辨識度低的程式碼。
- 方便做 code analysis (e.g. static analysis, performance benchmark, etc.)。
雖然流程變短了，但是還是有一個問題就是：
developer 必須要執行遊戲才可以知道目前寫的程式碼是不是對的，
但有些 developer 寫的專案中在進入遊戲前可能需要加載素材會很花時間之類的，
正在考慮要拿 RGSS 的 DLL 寫個 vscode extension 會 real-time 把你目前的 rb file 丟給 RGSS 內的 Ruby interpreter 自動提示你程式碼哪邊寫錯的，
這樣以後可以在存檔前至少把一些基本的 syntax error 或者 undefined variable reference 這種低級錯誤先修掉。
除了遊戲引擎以及開發流程上的改變之外，最近也在開始著手地圖美化。
主要是想要添加光影，於是跑去參考了月見斐夜大的教學文替場景增加陰影光暈。
但是身為一個 programmer 又不想要每張地圖輸出 png 一張一張改，
光是用想的就覺得工程超浩大⋯⋯感覺既然 3D 遊戲可以給定光源座標自動生成陰影／光暈，
2D 雖然沒有 X, Y, Z 的資訊，但應該也能產出個類似的東西？
於是上網 survey 了一下發現實際上有開源專案是可以自動生成 shadow。
它的效果如下所示：
左圖是原本的地圖，右圖則是套用了生成出來的光暈以及陰影，
至於效果嘛⋯⋯還算堪用？未來研究完把它生成光暈／陰影的方式再重新改寫一下，
總覺的生成出來的分割感有點重。
這個專案用法是執行前給定光源座標、畫面上的元素後會幫你的場景自動生成出光暈和陰影兩個檔案，
如此一來再套用月見斐夜大的教學文的方式就可以達成了。
然而使用這個需要輸出畫面上的元素來做陰影光暈的繪製計算，
最簡單的方式就是在分層繪製地圖將場景上的元素用不同 layer 分開、
接著輸出地圖畫面的時候分層輸出、再全部丟過去自動生成光暈／陰影。
但是這麼做有個壞處：代表在畫地圖的時候沒辦法透過不同 layer 繪製物品部分區域重疊，ex: 路燈柱子後想要多畫一張椅子的話，不能讓路燈的柱子在 layer 3、其餘的部分在 layer 2、椅子在 layer 2。
暫時還沒想到這個該如何解決，於是目前就只能暫時手工拼貼物品部分區域重疊的地方。
以下貼一些進度
主要把遊戲畫面解析度從 800 * 600 調整到 1024 * 576 (16:9)，同時支持全螢幕放大。
添加行走圖待機動畫。
多加了燭光動態陰影。
戰鬥畫面動態運鏡，是說有一些畫面上的元素還在原本 800x600 的位置。
以前直接寫死座標，之後應該會調整
雯娜待機、攻擊修正。
以上 
