请问RM有无快速的描绘方法

aseesa

使用fill_rect,set_pixel等描绘命令时,速度很慢,比画面刷新的速度慢很多
而RM显示图片或动画时RM描绘速度很快,它是如何实现的呢?

---

此贴于 2007-9-4 21:40:13 被版主柳柳提醒，请楼主看到后对本贴做出回应。

aseesa

使用fill_rect,set_pixel等描绘命令时,速度很慢,比画面刷新的速度慢很多
而RM显示图片或动画时RM描绘速度很快,它是如何实现的呢?

---

此贴于 2007-9-4 21:40:13 被版主柳柳提醒，请楼主看到后对本贴做出回应。

aseesa

就是在给出图片的 大小 位置 RGB 后迅速将图片显示出来,需要怎么设置呢

柳之一

请楼主给出你的脚本。理论上用这个命令是一点不慢的，估计是楼主的写法有问题

aseesa

$aseesa = Sprite.new
$aseesa.bitmap = Bitmap.new(640,480)
for i in 1..640
  for m in 1..480
    $aseesa.bitmap.set_pixel(i, m, Color.new(255,255,255))
  end
end
这个脚本要运行2秒左右才能画出图片,普通的显示图片只要一瞬间就显示出来了
虽然同为307200个点,但显示的速度差很多,显示图片一定有特别的显示方法,它是如何实现的呢?

柳柳

让我回答吧，因为最近正好制作新的RPG制作工具，正好解决过这个问题。

当然慢了，因为你这种设置是307200个点×RGB三色浮点运算，在内存中完成，然后将其挪到显存，最后绘制。

而显示图片则是通过成熟的系统函数打开图片，然后将其直接扔到显存做alpha_blend粘贴出来(显卡处理alpha_blend速度极快，都是硬件电路)，至少至少节省了100万次运算（何况RM的RGB还是浮点运算），何况RM的图像还是Bitmap，封在Sprite里面，这里面的颜色矩阵，光想也知道汇编出来之后寻找内存位置。

所以原则就是绝对不要去手动操作象素点，这种东西太底层了，必须交给硬件去处理。系统API和DirectX等内部都有硬件接口，它自己处理了，而你的程序则是完全不可能调用硬件。

柳之一

让我来解决一部分问题吧，晕。本来悬赏太低，又不能确定一定能够得到认可，不想管这个问题，但是楼主的问题得到柳柳的pm的举荐，就给你发上来。附带范例。
http://rpg.blue/upload_program/files/jiejuewenti7.rar

范例说明：左面的小人是解决办法1的脚本加载，发现快了不少。右面的小人是预先加载，显示几乎不需要时间。上面的是原问题脚本，2到3秒的加载。


描绘都是“一瞬间"的。之所以楼主觉得慢，不是描绘问题

1. for i in 1..640
   
2. for m in 1..480

复制代码

你看看这个？相当你描绘多少图片？你要是描绘1个点，速度我敢说和比显示1张图片快。
到底描绘1个点和显示1张图片的速度关系是多少，我没有测试过，也不是很清楚。不过你要是用for的命令去放上很多图片，仍然是很卡。不信，楼主请显示地图的一个元件，让他铺满屏幕1024的，仍旧是很卡，不过比点好点。难道是for有错吗？的确。本身ruby的执行效率就有问题，color的建立是罪魁祸首。其实楼主基本上把所有可能减慢速度的因素全加进去了。

解决办法1：

1. $aseesa = Sprite.new
   
2. $aseesa.bitmap = Bitmap.new(640,480)
   
3. color=Color.new(255,255,255)
   
4. for i in 1..640
   
5. for m in 1..480
   
6.    $aseesa.bitmap.set_pixel(i, m,color )
   
7. end
   
8. end
   

复制代码

把颜色独立出来，发现速度大为上升，帧数才掉10，原来的掉没了。这已经是快速不少。

在开头画面预载图片，不要释放掉，在显示，发现这回更快，和加载一般图片已经没有区别，反而更快。但是开头显然会卡一下，这时候，预载脚本就可以发挥作用了，而不是视觉的摆设，任何脚本都是要有实际用途的，而摆设脚本不是。

另外，怎么进行图片加速的问题有人已经研究过，我的正在研究中，不拿出来献丑。

柳柳

时间可以做个简单测试，楼上。首先加一个高精度计时器：http://rpg.blue/web/htm/news225.htm，便于计算毫秒数。

然后640*480个点的绘制运算：

1. p "测试开始"
   
2. 
   
3. a = $sys_timer.now()
   
4. $aseesa = Sprite.new
   
5. $aseesa.bitmap = Bitmap.new(640,480)
   
6. color=Color.new(255,255,255)
   
7. for i in 1..640
   
8. for m in 1..480
   
9.   $aseesa.bitmap.set_pixel(i, m,color )
   
10. end
    
11. end
    
12. a = $sys_timer.now() - a
    
13. p a.to_i,"先创建Color，绘制填满640×480个点"
    
14. 
    
15. a = 0
    
16. $aseesa.bitmap.dispose
    
17. $aseesa.dispose
    
18. 
    
19. a = $sys_timer.now()
    
20. $aseesa = Sprite.new
    
21. $aseesa.bitmap = Bitmap.new(640,480)
    
22. for i in 1..640
    
23. for m in 1..480
    
24.   $aseesa.bitmap.set_pixel(i, m,Color.new(255,255,255))
    
25. end
    
26. end
    
27. a = $sys_timer.now() - a
    
28. p a.to_i,"每次创建Color，绘制填满640×480个点"
    
29. 
    
30. a = 0
    
31. $aseesa.bitmap.dispose
    
32. $aseesa.dispose
    
33. 
    
34. a = $sys_timer.now()
    
35. $aseesa = Sprite.new
    
36. $aseesa.bitmap = Bitmap.new("white")
    
37. a = $sys_timer.now() - a
    
38. p a.to_i,"从图片读取，填满640×480个点"
    
39. 
    
40. a = 0
    
41. $aseesa.bitmap.dispose
    
42. $aseesa.dispose
    
43. 
    
44. a = $sys_timer.now()
    
45. $aseesa = Sprite.new
    
46. $aseesa.bitmap = Bitmap.new(640,480)
    
47. $aseesa.bitmap.fill_rect(0,0,640,480,Color.new(255,0,0))
    
48. a = $sys_timer.now() - a
    
49. p a.to_i,"绘制矩形，填满640×480个点"

复制代码

在我电脑的情况：
第一种情况：290毫秒
第二种情况：910毫秒
第三种情况：15毫秒 (用的"white"是photoshop做的640*480图)
第四种情况：2毫秒

这就是为什么说最好不要用手动操作象素，290毫秒和15毫秒的差距。

当然，毫无疑问，这些图形生成之后就已经是一个内存对象，再次加载的速度理论上是一样的——这就是楼上所说的加载速度问题，预加载等方法。但是楼上和我讨论的不是一个事情，我现在说的只是用不同方式创建图象(生成BITMAP的过程)---->然后显示图象，这个过程的速度。楼主问的也是为什么同样是640×480个颜色点的一次创建，手动操作象素点要比读取图片的创建速度要慢。结论实际上就是“计算比拷贝要慢”这样一句。

至于创建完毕后从内存加载到显卡速度基本都是相同的。

这个东西的引申就是当年曾经考虑使用set_pixel制作图片的特效，形成斜切或者透视的效果，以此完成小幅度的3D效果（SFC的那种）。但实际上set_pixel运算压力太大，这么做之后帧数只能有0.5到1帧左右。虽说现在电脑硬件升级了，能有1－3帧了，但set_pixel手动生成还是不太可取的方法。

Ruby的for循环效率有问题？这点我倒不知道。不知怎么追踪他的效率，和其他语言做对比？我没研究过Ruby运行时候的汇编情况，这里就不多发表意见了。

柳柳

以下引用柳之一于2007-9-5 3:23:26的发言：

   本帖相关代码如下：
for i in 1..640
for m in 1..480


你看看这个？相当你描绘多少图片？你要是描绘1个点，速度我敢说和比显示1张图片快。
到底描绘1个点和显示1张图片的速度关系是多少，我没有测试过，也不是很清楚。不过你要是用for的命令去放上很多图片，仍然是很卡。不信，楼主请显示地图的一个元件，让他铺满屏幕1024的，仍旧是很卡，不过比点好点。难道是for有错吗？的确。本身ruby的执行效率就有问题，color的建立是罪魁祸首。其实楼主基本上把所有可能减慢速度的因素全加进去了。

像你说的这个，有一些地方缺乏逻辑性。比如描绘一个点和加载一张图片，这两者之间没有任何共同点，实际上比较他们的速度没有任何意义（就像比较进行1次乘法运算和打开一个声音文件播放所需要的时间一样，这两者没有什么直接联系的）。你需要的是加载图片生成10000个颜色点（比如100×100），用这种方法生成10000个颜色点，然后对比速度，至少这样才有意义。

如果你的意思是用set_pixel和一个只有1象素的图片做对比……那结果不好说，我估计两者速度相当吧。

至于悬赏，这种东西不用太看重吧，呵呵