Project1

标题: 高手讨论→RM里你们在乎程序效率吗？ [打印本页]

作者: 九夜神尊 时间: 2010-9-15 16:00
标题: 高手讨论→RM里你们在乎程序效率吗？
本帖最后由九夜神尊于 2010-9-15 19:28 编辑

忘了是哪位高手说的，RM的内部结构不是最优的。

那时候我还不懂，只是记住并知道这么回事。

在我写自己的系统的时候，写到了人物属性的取得。
这个模块我想大家都很熟悉，防御 =武器防御+帽子防御+盾防御+衣服防御。

但是，每次获取防御力都要经过这么一次运算，然而结果却大部分相同。显然程序效率低很多（当今的电脑似乎可以忽略）。

不过我想，RM作者最初不会没考虑到，而是为了让使用者容易上手。如果把每个属性保存成一个变量，每次读取的时候，直接
调用，在换装备的时候，再改属性。虽然效率会高很多，但是新手却很难上手。

不晓得各位高手对程序效率怎么看待的，就我本人而言，一个程序在我能力下，有优化的空间，我就觉得这程序没完成。

不过像我说的，属性的获取我倒是决定不优化，因为优化后会与现有大部分脚本脱节。

以下是我的一个感叹

血条，每次都要描绘么？

不，只需要在HP 或MAX_HP有改变的时候重新描绘

每次改变都要重新描绘么？

不，血多了就描绘一段红色把黑条盖住，血少了就描绘一条黑色把红条盖住

然而最后要吐自己的是：在乎效率就别用RUBY

作者: moy 时间: 2010-9-15 19:26
别同?是指别用麽......

作者: 紫苏 时间: 2010-9-15 20:41
程序效率是一个大话题，够写好几本书了（编译原理中的编译器优化理论），不过概括地说，常用的手段有：

降低算法复杂度
包括优化整体算法结构，使用合适的、高效的数据结构，给耗时的运算添加合适的分歧跳转（即主楼提到的“只需要在HP 或MAX_HP有改变的时候重新描绘”）等

最小化冗余
见 http://rpg.blue/thread-154785-1-2.html 11楼

紧密分配相关性强的代码和数据的位置
这提高了空间访问局部性，也就提高了 Cache 和内存操作效率

发挥内存阶层的长处
效率上，目前主流的配置大概是：CPU 寄存器 > CPU Cache > 闪存（USB 内存） > RAM（主内存） > HDD（硬盘） > 磁带 > ……
效率越高的存储方式在内存阶层中越处于上层，要尽量使用上层的存储，比如 RM 的 Cache 就是避免了频繁进行硬盘读写操作，而把位图的存储带到了相对高效的 RAM 内存中（因为 RAM 在 HDD 的上层）

简化语言相关、机器相关的运算
有些运算方式在有些语言或机器上效率低于另一些运算方式——
语言相关：如在头部检测条件的循环效率效率低于在尾部检测条件的循环
机器相关：如加减法效率低于乘除法、浮点数效率低于定点数

以上，优化 in a nut shell

作者: 死伤殆尽 时间: 2010-9-16 00:17
RM这系列软件，乃至整个tkool系列，从一开始就不是作为普通的游戏制作软件而开发的
这系列的特色和优势就在于使用简单，容易上手，只需要掌握最基础的操作就能轻松地制作出自己想要的作品
我认为在这个前提下，谈论效率是毫无意义的

作者: 熊的选民 时间: 2010-9-18 01:44
必要的优化还是要的，比如至少不能每桢都refresh一次，尽量避免遍历事件列表

作者: 六祈 时间: 2010-9-30 11:33
回复 九夜神尊 的帖子

小九注意到脚本的效率是很可喜的。

话说愚者第一次注意到这点是因为【后知后觉】前辈的点评。http://rpg.blue/forum.php?mod=vi ... p;page=1#pid1456488

为此愚者重新写了那段改变选项颜色的代码【没能完善，后来坑掉了】

目前的经验就是：对于bitmap类的draw_xxx方法【其它涉及到bitmap位图类的方法也是】，代价是很大的，还是应该在非draw不可的场合再draw。其它类似一些数据计算或者数据计算之类的迭代，时间效率还是非常不错的。

另外对小九的一些想法有一些不同意见：

【防御 =武器防御+帽子防御+盾防御+衣服防御。但是，每次获取防御力都要经过这么一次运算，然而结果却大部分相同。显然程序效率低很多】

如果用一个新变量来取值的话：

首先，增加内存开销，空间效率下降【虽然也是忽略不计】

其次，每次更新【武器防御】或【任意护具防御】的时候，都要顺带更新这个【防御】，额外的计算量降低时间效率【依然忽略不计】

最后最重点的是：用【查询方法替换冗余变量】可以使程序结构更易懂【有点拗口么。。试想一下，如果一个类有20个实例变量和它如果只有10个实例变量，哪种情况更易读】

作者: 禾西 时间: 2010-10-1 10:07
ruby 的效率雖然多有咎病，但問題其實不算大嚴重。如果沒有良好習慣的話，就算是匯編也救不了你。
1不要用大數值運算，2不要重複讀取大量數據，3不要不要過多刷新bitmap或使用諸如rand，GC.start等高代價方法。
這樣寫出來的程序效率其實還是蠻高的。
底層語句不得力不是借口，我們選擇ruby是因為他方便易用。而方便易用其實和效率并不衝突，在力所能及的位置對程序進行優化是必不可少的工序。君不見提問區老是出現：為甚麼我的遊戲做出來會卡？而其他人的不會？——這就看出水平的高低了。

作者: 柳柳 时间: 2010-10-1 11:14
实践证明，RM的效率还行。之前为了游戏的帧率，用了个微秒测试器仔细测过游戏里所有主要函数在大多数情况下的运行时间。即时以我优化得最差的时候，基本也是逻辑占10%时间左右，渲染占90%左右。优化好一些逻辑占时间更少。
总之和画图相比，逻辑占用时间几乎可以忽略。除非游戏画面是静态的……那就当我没说好了=。=

作者: 熊的选民 时间: 2010-10-2 03:54
回复柳柳的帖子
看是什么类型的游戏了，如果是arpg，而每桢都要计算的话，逻辑占用时间也是很恐怖的。比如我发出一串子弹，每颗子弹每桢都要遍历事件列表检查是否与其他事件相撞。

作者: 紫苏 时间: 2010-10-2 07:51

底層語句不得力。
禾西发表于 2010-10-1 10:07

Ruby 1.8 高层也不甚得力，主要还是由于 MRI 直接在语法树上求值，既没有经过优化的中间代码，也没有即时编译的代码 Cache 机制。

之前为了游戏的帧率，用了个微秒测试器仔细测过游戏里所有主要函数在大多数情况下的运行时间。即时以我优化得最差的时候，基本也是逻辑占10%时间左右，渲染占90%
柳柳发表于 2010-10-1 11:14

不知这个测试器是如何获取渲染时间的？Graphics.update 中进行实际的屏幕渲染也是需要考虑的，但它同时也包括程序空闲时间（不占用 CPU 的时间），直到从调用为止到结束经过了固定的时间（取决于 FPS）才返回。

作者: 九夜神尊 时间: 2010-10-2 09:55
回复 熊的选民 的帖子

你说的子弹实际上是因为算法的问题

如果需要处理很多的碰撞问题，就要用另一种数据结构了

在每个物体移动的时候，都要反馈一个自己的ID到坐标表中

直接调坐标就能得到事件的ID。

而这个坐标表实际上就是一个三维数组

obj[x][y][p]

当从4，5移动到4，6 的时候

就会在obj[4][5]中删除自己的ID
然后在obj[4][6]中再添加自己的ID

作者: 紫苏 时间: 2010-10-2 10:15
本帖最后由紫苏于 2010-10-2 10:16 编辑

回复 九夜神尊 的帖子

三维数组的空间代价比较大，而且每次移动都添加/删除元素也不是个办法，如果需要表示二维场景并进行简单的碰撞检测，可以选择用四叉树之类的稀疏结构节省空间，同时移动节点的频率也没有数组那么高。

作者: 九夜神尊 时间: 2010-10-2 10:38
回复紫苏的帖子
我表示关于2叉3叉4叉一类的我不懂。

作者: 熊的选民 时间: 2010-10-2 10:56
回复紫苏的帖子
以前做过类似的游戏，用的是网格或者树，加上visitor。不过要是从头开始写一个这种东西很烦啊。

作者: Tabris_Air 时间: 2010-10-9 10:42
哇，听的似懂非懂的飘过。。。=。=。。。

作者: 熊的选民 时间: 2010-10-9 15:32
主要的步骤有两个吧，一个是在事件每次移动时改变它在容器中的位置，另一个是在需要时对半径内的事件进行搜索得到一个列表。不过就算应用了高级的数据结构，也不知道性能可以提高多少。本来一幅图中的事件也就几十个，不是有成百上千个怪的大型游戏；而rm脚本的效率又不高，用高级数据结构的额外支出可能还抵不上带来的收益。

作者: DeathKing 时间: 2010-10-12 23:30
不是很纠结那东西，除非在很要手感的情况下。。。。
因为让我独立用SDK并用C/C++语言写游戏的话我觉得不会这样做。。。感觉好麻烦的说。

其实我觉得无论是立即数（存放在实变量中）还是通过方法获得，其消耗时间应该相差不是很大。再者，通过方法获取弹性更大。在我正在计划的武器天赋中：重定义了原获取攻击力的方法

alias _fsl_eg_atk atk
def atk
# 代码有省略
return @gifts.atk_plus + _fsl_eg_atk
end

这样对程序的兼容性很有帮助，也就是说，不但可以使用我的增益脚本，也可以使用其他程序员的。这些取舍，就仁者见仁智者见智了。

最后一句话说得不错。。。（纯Ruby的环境的确很快，RGSS2的结构比RGSS赞。。。）

作者: buruohuainian1 时间: 2010-10-12 23:48
提示: 作者被禁止或删除内容自动屏蔽

作者: 柳之一 时间: 2010-10-13 02:46

很精辟的一句话:在乎效率就别用RUBY
buruohuainian1 发表于 2010-10-12 23:48

我反而觉得是正是因为我在乎效率采用的ruby
开发一个小软件 ruby的开发速度是c不能比的
对于商业来说，开发效率才重要啊，管你用户死活

作者: sftk 时间: 2010-10-22 21:29
提示: 作者被禁止或删除内容自动屏蔽

作者: orochi2k 时间: 2010-10-22 21:32

我反而觉得是正是因为我在乎效率采用的ruby
开发一个小软件 ruby的开发速度是c不能比的
对于商业来说， ...
柳之一发表于 2010-10-13 02:46

开发效率最高+1 ~\(≧▽≦)/~

作者: 熊的选民 时间: 2010-10-23 03:43
忽然想到一个问题。假如有m个子弹和n个敌人，都储存在数组中。如何在最短时间内找出所有重叠的子弹-敌人对？如果逐一搜索，要做m*n次检查。

作者: 紫苏 时间: 2010-10-23 05:31
本帖最后由紫苏于 2010-10-23 05:34 编辑

主而rm脚本的效率又不高，用高级数据结构的额外支出可能还抵不上带来的收益。
熊的选民发表于 2010-10-9 15:32

Ruby 有本地接口，可以用 C 来写数据结构。

忽然想到一个问题。假如有m个子弹和n个敌人，都储存在数组中。如何在最短时间内找出所有重叠的子弹-敌人对 ...
熊的选民发表于 2010-10-23 03:43

这个就是求交集的算法了，目前最常见的做法是把其中一个方位向量的数组转换为散列表，然后迭代另一个方位向量数组，判断当前元素是否在之前转换的散列表中。
见：http://rpg.blue/forum.php?mod=viewthread&tid=157558
不过这个也是限制在你用无序的数组保存方位的假设上。如果是有序结构或四叉树，一次遍历就完事儿了（当然，如果用了有序或四叉树结构，那可能就不会这么做碰撞检测了，而是在插入/移动节点的时候就判断）。

作者: 熊的选民 时间: 2010-10-23 05:53
回复紫苏的帖子
并不只是寻找交集，如果坐标是连续的，就得进行距离检查。比如把“重叠“定义为“距离小于5.0“

作者: 九夜神尊 时间: 2010-10-23 08:57
托紫苏大人的福，我已经开始对4叉树研究了。
已经研究出来最快速度获得指定范围内的对象了。

作者: 熊的选民 时间: 2010-10-23 10:20
回复 九夜神尊 的帖子
期待能用上你做的4叉树系统

作者: 紫苏 时间: 2010-10-23 10:30

回复
并不只是寻找交集，如果坐标是连续的，就得进行距离检查。比如把“重叠“定义为“距离小于5.0“

...
熊的选民发表于 2010-10-23 05:53

换汤不换药，数组转换为散列表后，想如何实现元素的二元关系都行，普通情况下是判断相等，你这里可以判断距离

作者: 九夜神尊 时间: 2010-10-23 10:46
回复 熊的选民 的帖子

现在在实现任意几何图形范围内对象索取。

作者: wubugui 时间: 2010-10-23 13:03
对于一般程序已经不在乎效率了，在乎易读。

作者: applesnake 时间: 2010-10-24 12:37
本帖最后由 applesnake 于 2010-10-24 12:39 编辑

RM以牺牲效率和灵活性来换取简单性。越灵活的系统效率会越高，但是使用会更复杂。灵活性和复杂度并非简单线性关系，增加一个维度的灵活性的同时复杂性会随之成几何级数的增长——对比2D游戏和3D游戏的绘图过程就可见一斑。
对于现在的计算机游戏逻辑的处理的开销几乎可以忽略，除非超大型的循环、遍历或复杂的物理，AI计算。
脚本本身具有很强的针对性，而RM又是在这个基础上做了进一步的强化——针对多数2D RPG。所谓需求决定实现，所以RM的体系结构并不适用于构造过于复杂图形子系统。
对现有体系结构中的图形和特效的处理需要专业背景和对RM体系结构的深入了解，一般的使用者无法做到。建议：一般使用者不要在RM中使用脚本构建过于复杂的图形子系统，因为这超出RM框架本身包括图形库的能力。

作者: potatoking 时间: 2010-10-28 21:48
考虑到现在机子的效率
还是把更多的精力投入到游戏设计上比较有爱啊...

欢迎光临 Project1 (https://rpg.blue/)