[RGSS雜談] RPG::Cache、讀取畫面

這次不是教學，是牢騷(淦)，文長注意



讀取這件事嘛...就我理解的理解如下：
生成物件、運算都需要時間，
即時生成一兩個物件沒什麼影響，但若要連續製作就不免會有點延遲現象
有打過雪仗嗎，沒有？沒關係我也沒有(拖
不過起碼知道事先做好一堆雪球擺著 v.s. 邊打邊捏兩者的速度有差唄

所以呢，當載入的量變得龐大時，
我們可以先把物件通通做好放在後台，之後呼叫時就可以省下生成的時間
在這過程中會有段少許的等待時間，這時候就可以亮一張圖或一個動畫通知玩家「我正在忙...」


BUT，就是所謂的「但是」

ﾟÅﾟ)  
⊂彡#))д´).; .

RM本身的設計不怎麼需要這個   (#)´д`).;*.
一個場景所需的物件量沒多到需要讀取畫面來擋
基本上換個畫面「啪」的瞬間，釋放和載入的動作就已經結束了

oh，你說並行事件放太多會很卡？那我會建議先減少事件量，這種需要即時運算的東西也不好預先載入...

---

先來說說 RPG::Cache 這玩意，Cache翻譯過來叫作快取

我們先來看電子說明書的解釋：

讀取 RPGXP 的各種圖片，建立並存儲 Bitmap 對象的模塊（高速緩存）。 該模塊為了讀取的高速和節約內存，把建立的 Bitmap 對像保存在內部的哈希表中，當再次使用同一位圖時就返回已保存的對象。 因為上述動作，與其他精靈傳送元指定相同的位圖請注意不要用 Bitmap#dispose 釋放掉。當使用位圖時如果該對像已釋放則會自動重新建立。位圖會消耗大量內存，所以較少使用的位圖還是將其釋放為好。 當指定的文件名為空字符串時，會建立並返回一個 32×32 的 Bitmap。這與 Maker 的「(None)」 指定相對應。

霧煞煞...沒關係，我一開始也是，學程式有個問題就是專有名詞TMD多，理解都有困難


額，我本來打了一堆名詞解釋，後來想說太無關就扔了，用比較好懂話的翻譯上文就是：

安安你好，這是一個保存圖片的模塊☆ 為什麼要特地建立一個這樣的模塊呢？因為圖片根本就是記憶體的吃貨！ 如果同樣的圖連續作出好幾個實在太耗資源了， 你想想看，同一張圖、然後10個人要用，那不就要作10個同樣物件？不環保啊！！ 所以我們決定把已經生成的圖片保存在一個地方，在偵測到有人又準備生成同樣的圖時就取消！改用我們這裡已有的 不過要注意！因為同樣的圖在這裡只有唯一一張，請不要隨意將它修改或刪除造成其他使用者的困擾

額，還不懂？那用圖解

這是沒用快取的情況：


這是有用快取的情況：


好啦，其實重點不在生出幾個物件占了多少空間
而是要顯示圖片時，如果圖片對像已經保存在快取(緩存)區

就不用再生成一次了 (←重點)

有差嗎？有的，舉個例子：小風先生的勇者物語，真TMD神作也！快玩！額咳...
這遊戲裏面有些場景會不斷重新調用戰鬥動畫(ex：魔界大門、夜晚的街燈...)

不知有無注意到每次動畫重播時遊戲就會頓一下？什麼，沒有？好吧你家電腦好...
頓一下的原因就是每次播完要重播時就會釋放、再載入動畫圖
載入圖片(正確來說，是生成Bitmap) 這動作既然大到會頓，就表示資源吃很多，圖片越大這情形越明顯
偶爾生成圖片一下沒什麼，但連續一直來就很明顯感受到：啊好卡啊，怎會這樣...

所以如果碰到要不斷切換圖片(生成Bitmap)的狀況，不如先將它們預先生成、再等適當時機使用吧。這時候就能用 RPG::Cache 來管理它們。
但如同說明，因為調用的都是同個圖片物件(Bitmap)，因此生成後就不要動它了，
一改下去，其他有用到那個Bitmap的場合都會受影響
等確定不需要，再通通進行釋放(dispose)

如果真的要臨時修改還是另外開個Bitmap物件吧...

註：RPG::Cache 的機制是用圖片路徑來分，
所以假設要像格鬥遊戲那樣每人有各自的Bitmap大概要自己做個暫存用數組
或者角色開個空白的 Bitmap 用 blt / stretch_blt 去畫，不過這樣有沒有效率我不清楚，而且Bitmap要開得夠大、還要不斷的用clear......

---

好，知道預載的用處了，利用這點就可以來做讀取畫面
這裡指的不是放張圖然後設個等待n秒再撤掉的那種假loading (不過這段等待有沒有緩衝作用我倒是不清楚)


大致上的結構如下：

生成讀取圖 ↓ 等待物件載入完畢 ↓ 移除讀取圖

ﾟÅﾟ)  < 講廢話逆！
⊂彡#))д´).; .

靜態讀取圖沒什麼，不過現在的遊戲如果讀取畫面不會動會很乾
那動態要怎麼做呢

我可以告訴你其實我還在研究嗎 ヽ( ﾟ ∀ 。)ノ

ﾟÅﾟ)  
⊂彡#))д´).;' .,


至少確定要兩張以上的圖，然後要update(不然怎麼叫動畫)
至於在什麼地方放入update呢？啊什麼？放在Scene的 loop do 不就好了

loop do for i in 0...8 a += 1 end p a break if a > 6 end

假設：
for 循環＝準備物件
p a ＝更新loading動畫

實際上運行結果只會看到p a執行一次，也就是要等所有物件準備好才會看到動畫跳一格
那讀取動畫就沒意義了

所以我目前想到的也只能把 update 放進 for 循環當中了
另外要注意RMXP特有的10秒陣亡機制，準備物件的過程中記得放入Graphics.update，不然超過10秒就爆炸了(預載的物件量如果龐大到要跑loading畫面沒意外都要10秒以上)

有Graphics.update自然也不用擔心動畫問題了

...不過真的要這樣嗎，我有三個循環要處理不就要看動畫開始結束三次？
所以說要放一起？
額看來也只能這樣了...



ﾟÅﾟ)  < 你在自問自答什麼啦！
⊂彡#))д´).; .'.

---

重申，
如果只是普通的RPG，基本上不太需要注意快取和用到讀取畫面
而arpg和橫向動態戰鬥看起來動作很多，但實際上都是跑同一張動作圖(至少我目前看到的腳本都是)
反倒是arpg需要即時播放戰鬥動畫，某程度上會影響節奏，有餘力的話修改一下RPG::Sprite吧
參考一下這篇和這篇


Oh my god...這篇打了快6小時，耶－－－－

ﾟÅﾟ)  < 沒人想知道！
⊂彡#))д´).; .'.

---

還是發個應用範例好了，將它貼在main腳本之前
不過這個只對作業系統是W7以後的使用者有用，XP只是個假loading
這個的用途是事先驅動RM本身的 midi 裝置(實際上我不知道它到底啟動什麼，只知道「第一次」放 midi 時都會卡一陣，bgm 和 me 播放還分開的，搞不好 bgs 和 se 也是。既然要卡就在起動時讓它卡吧，在遊戲中多煞風景)：

使用前得先自備一張loading圖和一首midi (無音譜最好)，
分別放在 Picture 和 BGM 資料夾


# 用W7就設為 true
$w7debug = false
# 生成loading圖
@loading = Sprite.new
@loading.bitmap = RPG::Cache.picture("loading")
# 等個5畫格讓loading圖能確實出現
for i in 1..5
   Graphics.update
end
# 當flag成立的情況，先執行一次bgm和me播放
unless $w7debug
   Audio.bgm_play("Audio/BGM/load")
   Audio.me_play("Audio/BGM/load")
   Audio.me_stop
end
# 移除loading圖
@loading.bitmap.dispose
@loading.dispose


W7使用者應該會在midi播放那段卡一陣子，
然後搭配loading圖就會讓玩家有「欸欸欸好專業喔居然有讀取畫面」的錯覺，好啦實際上真的有在跑什麼，不過...嘛...

初次放midi會卡這問題到VX ACE都沒解決，
VX是強制預載(測試時會抓狂)
ACE似乎注意到VX的問題，改成啟動選項有問要不要預載(VXｪ....)。而且ACE內建音樂幾乎都換成ogg...

---

附錄：剛剛說明文中的名詞


Bitmap：位圖
就是圖片，至於圖片是什麼，你懂的
只是RM要讓圖片顯示還需要Sprite物件，所以要顯示一張圖最少要這樣：

pic = Sprite.new pic.bitmap = Bitmap.new(圖片路徑)

錯誤示範：這樣圖片確實有被叫出來，但因為沒 Sprite 你神馬都看不到

pic = Bitmap.new(圖片路徑)

總之，把 Sprite 當作一張無限大小的畫布或畫框吧，圖片要在畫布上才行
這樣做有好有壞，好處是可以一個Sprite顯示好幾個Bitmap，類似拼貼(追加Bitmap要用別的語句)，不過我生成一堆圖片疊在一起不也一樣效果...？
壞處就是...要知道兩邊各自能做的事，像移動是操作畫布(Sprite)而不是圖片(Bitmap)
有時候會搞混

注意，Bitmap做成時要設定長和寬(有現成圖就是用圖片本身大小)，可以做個空的Bitmap之後再慢慢貼圖進去
...這樣說起來Bitmap到底是神馬東西，我也搞不懂了...好像也不單單就是指"某張圖"


精靈：
就是剛剛講的 Sprite，要顯示圖片它就必須存在，是連個中文名稱都很難懂的存在。
不要問為什麼要顯示圖片先作成這個，這是規定


釋放：
以比較能懂的話來講就是：
變量會依照它的類型，命令電腦的記憶體開闢一個適當大小的資源空間讓他暫駐
釋放這動作，就是「你沒用處了，為了省資源快滾吧」(欸
總之沒用到的東西就釋放掉吧，其實轉換場景過程有些東西不釋放好像會出錯的樣子...
(哪個小兲蛋留下這沒用的吃貨，不爽啦彈game)


哈希表：
Hash，懂Hash前必須先懂Array
如果有個Array是： ["A","B","C"]
用Hash表示就像是：{0=>A, 1=>"B", 2=>"C"}
Array 的 index 變成可以讓使用者決定名稱，方便辨識，稱之為「鍵(key)」
不過也因此Hash沒有順序
(不要說0~2怎麼會沒順序，對系統來說那只是一個識別標籤而已)



傳送元：
我也不知道(淦
到底誰來告訴我這是什麼，please tell meeeeeeeeeeeeee！

---

額，晚點發一下FTG系統的改造狀況好了...