【更新】提高游戏运行速度(v1.01)

一箭烂YiJL

0.序
往往游戏过程因为太慢，所以想高速测试有难度。
最简单的办法是将帧频率调高，但是不能超过120。
这办法适用在游戏测试中(尤其是破关时间)，请不要发布于游戏中，
因为速度不等于效率，极快会感觉一卡一卡。

1.讲解
当删掉Graphics.update时，会出现画面不更新，但是操作极快的问题。
loop do绝对超过一秒60次(帧频率)。于是这是我的猜测：
Graphics.update除了有更新画面的基本动作外，还会有：

1. sleep(1/Graphics.frame_rate - 更新画面的时间 - 逻辑运算的时间)    # 此处经过修正

复制代码

所以不用Graphics.update就会高速不断地循环计算。

2.脚本
综合以上，脚本如下：

1. 
   
2. #==============================================================================
   
3. # ■ 提高游戏速度(v1.01)    by 一箭烂
   
4. #------------------------------------------------------------------------------
   
5. #  设置$Speed_Lv以致提高游戏速度,
   
6. #    请插在main之上, Scene_Base之下
   
7. #
   
8. #  更新：
   
9. #
   
10. #    - *1.0.1* (2011-04-21) By 一箭烂(YiJL)
    
11. #      *对Graphics.frame_count的修正
    
12. #      
    
13. #
    
14. #    - *1.0.0* (2011-04-21) By 一箭烂(YiJL)
    
15. #      *初版
    
16. #
    
17. #==============================================================================
    
18. class Scene_Base
    
19.   $Speed_Lv = 2     # 正常速度的倍数
    
20.   #--------------------------------------------------------------------------
    
21.   # ● 主处理
    
22.   #--------------------------------------------------------------------------
    
23.   def main
    
24.     start                         # 开始处理
    
25.     perform_transition            # 执行渐变
    
26.     post_start                    # 开始后处理
    
27.     Input.update                  # 更新输入讯息
    
28.     #------------------------------------------------------------------------
    
29.     # 添加部分
    
30.     old_time = 1
    
31.     #------------------------------------------------------------------------
    
32.     loop do
    
33.       #----------------------------------------------------------------------
    
34.       # 添加部分
    
35.       old_time += 1
    
36.       old_time %= $Speed_Lv
    
37.       if old_time >= ($Speed_Lv - 1)
    
38.         Graphics.update           # 更新游戏画面
    
39.       else
    
40.         Graphics.frame_count += 1
    
41.       end
    
42.       #----------------------------------------------------------------------
    
43.       Input.update                # 更新输入讯息
    
44.       update                      # 更新画面
    
45.       break if $scene != self     # 切换画面时中断循环
    
46.     end
    
47.     Graphics.update
    
48.     pre_terminate                 # 结束前处理
    
49.     Graphics.freeze               # 准备渐变
    
50.     terminate                     # 结束处理
    
51.   end
    
52. end

复制代码

用#------
　#------包着的这些是外加的意思。

3.其他
实质上帧频率不变，但是做一次Graphics.update(画面更新)就等于做了x次的其他数据运算。
当数据运算量太大时就可能会有卡的状况。(Speed_Lv影响着数据运算比起平常倍数！)
还有现在的版本只能加速/不加速，不能减速！

4.范例
没什么范例可给的，一插脚本就见效嘛~伸手要范例的回帖去吧。
已经把回复可见去掉了，VX区为啥这么多人想在草原中奔跑呢?= =
提高游戏速度_v1.01.zip (261.49 KB, 下载次数: 609)

2011-4-21 23:19 上传

点击文件名下载附件

zx工作室2

沙发！
为什么是VX的范例啊·····

daipeng76

支持，抱走了，看看是否能流畅的运行99个并行事件

link006007

最好  能够考虑到，画面只是游戏流畅度的一部分。对于每帧都有逻辑或AI计算的游戏来说，画面和这些部分不同步也会有很多问题。

kaveil

容易出错吧这样弄

summer92

是吗?超过120.....挑战CPU啊

苏小脉

嗯，有些人称这种方法或现象为“跳帧”。
另外睡眠那里应该是减去游戏逻辑耗费的时间比较合理，因为是固定帧率。

变慢的话可以调用两次 Graphics.update，不过这么做只能是帧率的倍数，任意比率的话就只能手动 sleep 了，嘿嘿。

一箭烂YiJL

回复 苏小脉 的帖子

那么也就是Graphics.update已经考虑到逻辑运算所消耗的时间了。
如此推论的话，当实际fps下降是因为RM进程(Game.exe)/RM线程的优先级不够高？
然后抢得CPU使用量不够多？于是我做了一下实验：


用SetProcessWorkingSetSize函数将RM进程(Game.exe)提升到最高级(即时)：

1. SetProcPriority = Win32API.new("kernel32", "SetPriorityClass", "ll", "i")
   
2. SetProcPriority.call(-1, 0x100)

复制代码

然后用"跳帧"的方法，10倍的跳帧。
应用在我计划的一个即时性战斗游戏里，重点在于即时性，双方、动画、逻辑运算越来越多。
然后设下一个按钮开关，准备将优先级降低至悠闲级(最低)。

然后开始，不一会，CPU介乎于90~100%，然后把优先级降低至最低，
CPU使用率马上下降了，游戏也慢了下来。

苏小脉

一箭烂YiJL 发表于 2011-4-21 15:14
回复 苏小脉 的帖子

那么也就是Graphics.update已经考虑到逻辑运算所消耗的时间了。

实际帧率下降主要还是逻辑超出了预期运算时间了（预期最大不超过 (1000/帧率) 毫秒），所以原本固定 40 帧每秒，实际可能只渲染了不到 40 帧。

在抢先式多任务的操作系统下通过调整优先级就算有性能上的改善，也不是解决问题的正途，因为这种行为很流氓。抢先式系统下资源大家共有，地主老财作风从来不被提倡。微软操作系统缺省的排程还是比较人性化的，在前台的程序优先级总是稍高于后台程序。

Rings

我喜欢收藏，所以要回复也下，切~。。。