總之先比較下 update 速度吧，畢竟是要每畫格用一次的東西，
以下是 全按鍵(Kboard.update) 和 內建(Input.update) 的比較結果：
...內建方法超爆幹快的有木有啊，不愧是內建
之前的版本是用 WIN32 API的
GetAsyncKeyState 但這方法一次只能判斷一個鍵，於是update就要一個鍵一個鍵去call API判斷
聽說RGSS去call API的過程很慢
所以想到的辦法就是控制一畫格call API的次數
總之上網找了下有沒有一次取得所有按鍵狀態的方法，這樣就能一畫格只call一次
最終找到了GetKeyboardState
排除一切萬難後(什麼上位下位啦、結構體啦、指針啦、byte數組等一堆從沒看過的東西)終於做出了 Kboard.update2
再來比較下速度：
比舊版快了一倍，這就是成長的證明啊！不過還是輸內建10倍
...
本來想說就這樣了，不過在敲這篇的同時又想到：
「其實我要用全按鍵腳本判斷的鍵也就20幾個，就不能只更新它們嗎」
修改之後得到以下結果：
(ﾟ∀。)b 水啦！完全大幅成長！無敵了！！
我甚至在想內建腳本能用的按鍵這麼少是不是因為這個
好，就這樣，腳本也更新了，歡迎取用
其實就是有人問RM怎麼優化，但這不是一兩行能說明的，所以就打了這篇
事件當然也可以優化，在有限的規範內榨取更多效能，不就是優化在做的事嗎
有摸過RM的都知道並列處理用多了會很卡，
像是玩那些小黃油常有那種紙娃娃角色在畫面右邊，有人就會用個定期處理去檢查換裝
或是什麼小時鐘，每畫格都加一次時間單位...
然後就卡爆了
換裝呢，既然是純事件，那都是用技能或道具在換，可以把換裝判定寫在這些事件的最後
時鐘也可以做成觸發事件、過地圖等才計算
像這樣，就可以減少使用並列處理的頻率 (當然如果非用不可，也只能用了)
---
不過如果是個還沒做出東西來的新人，可以先不管優化什麼的，
東西都還沒做出來就在研究怎麼更快已經本末倒置了，做完之前，你也不知道怎麼更快
做完之後，通常還是不知道
你看那個已故的茶時間優化這麼慘遊戲還不是照出
它就是個可能哪天查資料查到一半才會發現，
或是像這篇文打到一半忽然靈光湧現的...經驗的累積
(如果在這之前沒研究搖桿API，那個Kboard.update2也寫不出來)
像是八方向判斷，你要怎麼做，假設 x: -1是左、y :-1代表上
(ﾟ∀ﾟ)/ < 我知道我知道，用條件分歧：
if x == -1 && y == -1 return 7 elsif x == 1 && y == -1 return 9 elsif x == -1 && y == 1 return 1 elsif x == 1 && y == 1 return 3 elsif x == -1 return 4 elsif x == 1 return 6 elsif y == -1 return 8 elsif y == 1 return 2 else return 5 end |
好，因為RMMV的 Input 直接開源，我們看它怎麼寫：
嗯
就這樣，一行
看到這行前我從沒想過可以這樣寫，然後前者速度輸後者30%
唯有寫過才能感受到那一行散發出來的霸氣
經驗的累積啊...
LINE