總之先比較下 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%
唯有寫過才能感受到那一行散發出來的霸氣
經驗的累積啊...