【不是创意的创意】RM内存自动清理脚本（XP&VX） v 1.00

精灵使者

以前夏娜的10s脚本使用线程的创意启发而来
最近发现RM游戏会占用越来越高的内存。
使用线程原理，定期使用GC.start来清理内存，可以有效的解决吃内存现象。
使用方法：直接插入脚本最上面即可

更新日志：
2011年11月21日 发布原版
参数说明：
GC_FREQ = 1 #清理内存的频率（如果卡机，请调大清理频率，默认1秒整理1次）
GC_TRANSITION = true #场景变换的时候是否立即清理（推荐开启，转移的时候清理掉上次地图的内容，减少卡机）

1. ############################################################################
   
2. # RM内存自动清理脚本（XP&VX） v 1.00
   
3. # 作者：精灵使者 创意：夏娜 各种压力的猫君
   
4. # 按惯例，此类脚本应该放在最上面，就会自动工作。
   
5. # 使用方法：直接插入脚本的最上面即可
   
6. # 如果感觉卡机，请修改GC_FREQ
   
7. ############################################################################
   
8.   #--------------------------------------------------------------------------
   
9.   # ● 设定部分
   
10.   #--------------------------------------------------------------------------
    
11. module GC_CLEAR
    
12. GC_FREQ = 1 #清理内存的频率（如果卡机，请调大清理频率，默认1秒整理1次）
    
13. GC_TRANSITION = true #场景变换的时候是否立即清理，默认开启
    
14. end
    
15.   #--------------------------------------------------------------------------
    
16.   # ● 创建自动清理线程
    
17.   #--------------------------------------------------------------------------
    
18. @gc_thread = Thread.new{loop{GC.start;sleep(GC_CLEAR::GC_FREQ)}} if @gc_thread.nil?
    
19. 
    
20.   #--------------------------------------------------------------------------
    
21.   # ● 场景变换时清理部分
    
22.   #--------------------------------------------------------------------------
    
23. class << Graphics
    
24. alias origin_transition transition unless method_defined? :origin_transition
    
25. alias origin_freeze freeze unless method_defined? :origin_freeze
    
26. 
    
27. def transition(*args)
    
28.   origin_transition(*args)
    
29.   GC.start if GC_CLEAR::GC_TRANSITION
    
30. end
    
31. def freeze
    
32.   origin_freeze
    
33.   GC.start if GC_CLEAR::GC_TRANSITION
    
34. end
    
35. end
    

复制代码

D_Lohy

VA能用吗

enghao_lim

我记得……这脚本很久以前美兽就写过了……==''。
用的是RM的方式，自定义释放内存，可以参考。

忧雪の伤

有意义？

yangff

= =Cache的管理都能写一篇论文了，涉及到人工智能，期望之类的东西，当然最简单的就是资源表+背包XE

q857539182

好像不太必要，我发现许多人玩完就删了

小湖

有一个疑问……

我使用连续播放图片的方法循环播放一段动画，为了使动画流畅，我事先将图片都显示了一遍放入缓存，这样显示的时候就不会卡了，如果用了这个脚本，每次都要重新加载，岂不是又要开始卡了……

第七水螰

禾西 发表于 2011-11-23 14:22
在不確定要使用多少內存的情況下討論緩存管理，有意義嗎（挖鼻孔）Ruby的GC和RM的Cache完全是彼此對立的兩 ...

RGSS 默認的 cache 是用了多少內存就有多少緩存，這會導致資枯竭問題。我們討論的是給 cache 塊的大小加一個上限，無論內存的使用量如何，緩存都只能這麼大。

禾西

在不確定要使用多少內存的情況下討論緩存管理，有意義嗎（挖鼻孔）Ruby的GC和RM的Cache完全是彼此對立的兩個觀念。

第七水螰

Shy07 发表于 2011-11-22 09:27
Cahce.clear是整个RGSS2可见部分唯一调用到GC.start的地方，我觉得eb的本意是让用户自己在事件或脚本中手 ...

原來是這個意思，看四樓說「Cache貌似可以直接扔掉了」，我完全理解為「cache 沒有用」了。

我觉得eb的本意是让用户自己在事件或脚本中手动调用Cache.clear [...] 如果要严格控制内存的话，其实可以在Scene.start里用Cache.load_bitmap加载该场景需要的所有位图，Scene.terminate里调用Cache.clear，清空内存并进入下一个场景

你說的很貼近於一種叫 Belady's Algorithm 的 cache 算法，即 cache miss 時總是拋棄未來不會使用的時間最長的內容。然而，這種思路在實踐時幾乎沒有可行性，因為在足夠動態的環境下根本無法確定某個信息是否還會被引用或是會被引用多長時間。手動清空 cache 時，如何能確定清空的位圖在下一個場景中不會被使用？如果這些位圖僅存在於一個場景中，那「在該場景中重複加載這些位圖」的概率能有多高？相比於「在所有場景中反復加載這些位圖」的概率來說自是不算高。按照十一樓提出的方法，「在一個場景中重複加載位圖」的概率越高，cache 的價值才越高，而「別的場景也加載相同位圖」的概率越高，cache 的價值就越低。在編程時或許能確定場景 A 和 場景 B 都用到了位圖 P 而場景 C 沒有用到，但在運行時卻無法預料遊戲到底會過渡到場景 C 還是場景 A、B。 目前 RGSS 的 cache 就像一個巨大的位圖池，無論是在什麼場景使用某個以文件路徑標識的位圖，只要經過了 cache 這層，就永遠只需要加載一次，所以它壓根沒有考慮訪問局部性之類的 cache 問題，它只是默認已經擁有可以快速查閱的表。在一個理想的（無限內存） RAM 計算模型下這是時間上最優的一種設計，但在實踐時卻需要考慮計算機內存的有窮性。

CPU cache 可以看作是 cache 算法的最基本也是最重要的一個應用，不同的硬件採用的 cache miss 處理算法也不同，像拋棄最不常用數據的 LRU，拋棄最常用數據的 MRU，隨機化的 RR 等。RM 理論上完全可以實現這樣的一個 cache。