[-_-b秘笈]真．动画播放的提速，效果显著的方法哦～

FantasyDR

原来的那篇文章，实在有点误人子弟了。虽然前面大体分析过程没有错误，但是后面的改法有点效率低下，而且存在错误……我也就不细说了。下面已经改过了……

==========================我的名字大家都知道 我叫分..-_-b=============================

最近我发了个叫做《Strike》的射击游戏Demo，虽然很卡，不过速度上面应该比纯事件制作的快一些。其中子弹的效果是一个空白的事件，然后在其身上播放一种动画来表现。最初很快发现一个问题，即使在P4，2.8G的CPU的机器上面，按下子弹发射键依然会卡一下才能继续。

这对于游戏的表现力很有影响，所以就探察了一下原因。

开始以为是并行事件调用的原因，后来发现，如果一个动画正在播放中，那么再次播放它就不会有停顿。如果是一个独立的动画，开始的时候就会卡。于是看是分析动画播放相关的内容，追溯到RPG::Sprite这个内部类。

还好，帮助里面厚道的给出了RPG::Sprite的实现方法，否则真的死在这里了。而且，帮助文件里面厚道的提示了以下内容：
显示的动画图像从 RPG::Cache 模块中取得，动画结束时为了节约内存而被释放。

现在又仔细理解了一下那个RPG::Sprite的定义，发现还是不要把Sprite的dispos也去掉为好，因为显示层的关系。

根据这条线索，阅读RPG:Sprite的代码实现，发现每次播放动画前，会载入动画所需的素材图片。接下来分析了下代码，发现其实原本素材的bitmap是存放在一个Hash表里面的，也就是本来是可以实现类似缓存加速的效果的，当有动画调用这副素材，这副素材的引用数量就被加1，如果这个动画播放完毕，引用数量减1，当引用数量为0，素材图片被释放……

问题就在这里。

这也就解释了为什么同样的动画一起播放反而不卡的原因，因为只有一次new和一次dispose，中间都是直接取Hash里面的对象，省略了大量的初始化时间。

那么改造方案也就出炉了，重载这个方法，去掉相关的资源释放的内容。以下是代码，从帮助里面粘贴出来，代码中被我注释掉的是释放资源相关的内容。只有在头一次按播放某个动画的时候会稍微卡一下，机子好的话不会有感觉，以后都不会卡了。

而且，其实速度的关键就是那张动画图片的加载，现在可以确定，这种改法至多会让你浪费掉Animation目录下面的图片所消耗的内存，其他没有任何副作用。
但是觉得RM游戏动画播放所消耗的内存应该不足以致命吧？至少我的游戏是正常的……

如果在调用动画之前卡一下觉得不爽的朋友们，就加入这个脚本吧。
甚至可以可以尝试动态Loding。在需要的时候，把Animation目录下面的图片随便用
RPG::Cache.animation("文件名",色相值)
赋给某个变量，这样就相当于预载入了图片。播放的时候一点都不会卡：）
那么，文件多的话，做一个Loding画面也就不过分了：）

脚本请插入工程的Main之前：

2. module RPG
3.   class Sprite < ::Sprite
4.     def dispose_animation
5.       if @_animation_sprites != nil
6.         sprite = @_animation_sprites[0]
7.         if sprite != nil
8.           @@_reference_count[sprite.bitmap] -= 1
9.         #  if @@_reference_count[sprite.bitmap] == 0
10.         #    sprite.bitmap.dispose
11.         #  end
12.         end
13.         for sprite in @_animation_sprites
14.           sprite.dispose
15.         end
16.         @_animation_sprites = nil
17.         @_animation = nil
18.       end
19.     end
20.   end
21. end

复制代码

CountD

XP居然没有在适当场景预载和卸载动画的功能……= =|||
连LM2都有，我寒。（虽然LM2速度慢到可怕的程度……）

FantasyDR

其实不能说完全没有，比如动画1正在播放中，又有事件显示动画1，那么动画1说调用缓存里面的。
可是如果动画1暂时没有人播放了，那么动画1的相关资源就会被释放。

假如是频繁的单个动画播放，那么就是……卡啊卡……

寒死。至少我是这样感觉的，不知道分析的对不对。结果上看，速度确实上去了。

CountD

嗯，不过其实应该在事件里添加预载和卸载指令的……
嗯，不知道可以用事件调用的脚本达成的难度……

FantasyDR

说起来LM2也是EB的东西吧？
所以听了CountD关于LM2动态加载的介绍后，我又重新看了看，发现自己犯了一个错误。

原本是有动态加载功能的，只不过卸载的条件有点不对。只要改动一点点就可以，而且是很安全的改法。

于是赶快把顶楼误人子弟的帖子编辑掉了……

CountD

其实LM2是属于RPG MAKER系列之一哦，至少使用规定上是这么说的。所以素材可以通用这点是最让人高兴的了，嘿嘿。

幻の飞鱼

没搞清楚怎么用
在事件里用脚本试着预载了一个，结果出错了- -！

幻の飞鱼

还有个比较麻烦的问题，XP里选图片色度的时候是个滑块
我怎么知道具体的值是多少了- -1