Project1

标题: 正在复制rmvx，请大家给点建议 [打印本页]
作者: 老邢    时间: 2011-3-2 00:41
标题: 正在复制rmvx，请大家给点建议
使用lua作为脚本语言，因为目前只有lua可以运行在所有手机上，包括iPhone和Android，已经完成了游戏函数库，下一步是翻译scripts中的脚本。

播放器（相当于game.exe）已经做好，在android真机和iphone模拟器跑了，都没问题。设计器还没做。
作者: 楼主是烧饼    时间: 2011-3-2 04:41
你真是个天才！楼主加油啊
作者: IamI    时间: 2011-3-2 06:15
scripts没啥，Tilemap和Window任重道远啊
作者: 老邢    时间: 2011-3-2 08:41
tilemap和window基本完成了。昨天半夜没睡就是在弄window，本来想都弄完的，结果上网乱转耽误时间了，一下到了12点多。还差个openness一会儿加进去。

tilemap的确比较麻烦，不过比起显示地图，我觉得做地图设计器更复杂，我已经把显示部分全做好了，包括所有动态图块的显示，效率也还不错，800x600，60帧无延迟。目前只是完全兼容vx，没做扩展。


老邢于2011-3-2 08:43补充以下内容：
另外我没有在tilemap，window，plant内部使用sprite，估计这样效率能高一些。
作者: v2sam    时间: 2011-3-2 08:58
写一个同样的游戏，LUA那东西用的时间，用RM可以做几个了。LZ真有恒心啊，佩服。
作者: 老邢    时间: 2011-3-2 09:48
本帖最后由 老邢 于 2011-3-2 09:54 编辑

ruby的确比lua舒服，如果不是因为iphone不支持ruby，我也不会从头学lua。当我想像自己的rm制作完成，有宠物，有坐骑，有纸娃娃，可以联网。。。恒心就像恒星那么大，哈哈


老邢于2011-3-2 09:50补充以下内容：
最后一个隐藏对象window已经完成，正是进入Scripts的翻译工作。

贴一大段代码show一下
  1. function MainImpl()

  3.         local reload = false
  4.        
  5.         local x, y = 0, 0
  6.                
  7.        
  8.         local plant = Plant.new()
  9.         plant.bitmap = Bitmap.new("Graphics/Parallaxes/Sea")
  10.         plant.zoom_x = 0.5
  11.         plant.zoom_y = 0.5
  12.         plant.ox = 20
  13.         plant.oy = 50

  15.         local spr1 = Sprite.new()
  16.         spr1.bitmap = Bitmap.new("Graphics/Characters/Actor1")
  17.         spr1.x = 190
  18.         spr1.y = 0
  19.         spr1.src_rect = Rect.new(0, 0, 32, 32)
  20. --[[       
  21.         local map = Tilemap.new()
  22.         table.insert(map.bitmaps, Bitmap.new("Graphics/System/TileA1"))
  23.         table.insert(map.bitmaps, Bitmap.new("Graphics/System/TileA2"))
  24.         table.insert(map.bitmaps, Bitmap.new("Graphics/System/TileA3"))
  25.         table.insert(map.bitmaps, Bitmap.new("Graphics/System/TileA4"))
  26.         table.insert(map.bitmaps, Bitmap.new("Graphics/System/TileA5"))
  27.         table.insert(map.bitmaps, Bitmap.new("Graphics/System/TileB"))
  28.         table.insert(map.bitmaps, Bitmap.new("Graphics/System/TileC"))
  29.         table.insert(map.bitmaps, Bitmap.new("Graphics/System/TileD"))
  30.         table.insert(map.bitmaps, Bitmap.new("Graphics/System/TileE"))
  31.         map.map_data = Table.new(24, 24, 1)
  32.         for y = 0, 23 do
  33.                 for x = 0, 23 do
  34.                         map.map_data:set(x, y, 0, 2048 + 80 * 48 + y * 24 + x + 7 * 48)
  35.                 end
  36.         end
  37.         map.ox = 20
  38.         map.oy = 20
  39. --]]


  42.         wnd = Window.new()
  43.         wnd.windowskin = Bitmap.new("Graphics/System/Window")
  44.         wnd.x = 20
  45.         wnd.y = 20
  46.         wnd.width = 400
  47.         wnd.height = 200

  49.                
  50.         while true do
  51.                 _Input.update()
  52.                 spr1.x = x
  53.                 spr1.y = y
  54.                 spr1:update()
  55. --                map:update()
  56.                 if wnd.openness < 255 then
  57.                         wnd.openness = wnd.openness + 5
  58.                 end
  59.                 Graphics.update()
  60.         end
  61.        
  62.         return reload
  63. end
复制代码
作者: 觉醒の赤翼    时间: 2011-3-2 12:22
复制V叉
羡慕啊,
编译器一定花了不少时间把(除非你是CP的)
作者: DeathKing    时间: 2011-3-2 12:40
能达到GameLoft游戏的水平么？
作者: 死伤殆尽    时间: 2011-3-2 17:53
请注意版权问题，其余没什么可说的。有这个能力不如自己做个类似的软件而不是单纯复刻，因为复刻RMVX这代真没多大意义，还不如XP呢。
作者: 老邢    时间: 2011-3-2 18:46
我虽然很早就听说过rm系列软件，但从来用他们做过游戏，也不知道vx和xp具体的差别。说是复制vx就是觉得vx的图像比较漂亮。不过话说回来，现在做的东西似乎跟版本也没什么太大关系，因为没有做设计器，只做了底层的图形、声音、控制接口和地图、精灵的封装，这一层面上xp和vx应该没有多大差别，包括其他游戏引擎也都是这样的。这个引擎目前已经可以用来编写跨平台游戏了。可以考虑先做个连连看之类的demo试试效果。另外我还准备引入box2d和粒子系统，让他变成通用引擎。
作者: zh99998    时间: 2011-3-2 19:02
Android有个sl4a可以支持ruby，不过效率不咋地


zh99998于2011-3-2 19:03补充以下内容：
好吧我错了，Android是完美支持Ruby的，要知道Ruby除了有官方的C实现之外还有个Java实现，叫Jruby，这个可以在Android下完美运行
作者: 老邢    时间: 2011-3-2 19:10
我只在android上编译过命令行的ruby，不知道效率怎么样。有空把argss移植到android上试试看。
作者: david50407    时间: 2011-3-2 19:18
对于不同的分辨率的自动调整
不同系统的通用性
作者: DeathKing    时间: 2011-3-2 22:49
回复 老邢 的帖子

ruby核心解释器就是ruby.exe / ruby.bin 啊。RGSS和Ruby是两个概念。
作者: 苏小脉    时间: 2011-3-3 08:30
老邢 发表于 2011-3-2 19:10
我只在android上编译过命令行的ruby，不知道效率怎么样。有空把argss移植到android上试试看。 ...

JRuby 实现据说还是不错的，看过一个 benchmark，除了在 Linux 下不如 CRuby 1.9 以外，其余平台在众多实现中都名列前茅 =)
作者: 老邢    时间: 2011-3-3 09:41
回复 DeathKing 的帖子

只用ruby.exe没法做游戏啊，连gui都没有。只有rgss也不行。rm之类的软件是对ruby做了封装，增加了gui。所以说到效率，ruby的效率并不是最重要的，gui的效率才是关键。有了gui，没有rgss一样可以做游戏。


老邢于2011-3-3 09:44补充以下内容：
另外argss是rm的game.exe的另外一个开源实现，不是rgss。
作者: 苏小脉    时间: 2011-3-3 10:30
本帖最后由 苏小脉 于 2011-3-3 10:30 编辑
老邢 发表于 2011-3-3 09:41
回复 DeathKing 的帖子

只用ruby.exe没法做游戏啊，连gui都没有。只有rgss也不行。rm之类的软件是对ruby做 ...


“没法”用过了，GUI 只是提高了开发效率，缺了 GUI，只有 SDK 不也照样活。

执行效率和开发效率应该是平行的嘛，这两者的轻重各人心中不尽相同，硬要权衡还真没啥意义，制作游戏的人也并非全都肯为了开发效率而牺牲执行效率呢。
作者: 死伤殆尽    时间: 2011-3-3 10:33
老邢 发表于 2011-3-2 18:46
我虽然很早就听说过rm系列软件，但从来用他们做过游戏，也不知道vx和xp具体的差别。说是复制vx就是觉得vx的 ...

图像什么的有侵权危险，最好别直接搬过去，做成兼容素材格式让用户自己添加就好。就地图编辑器部分而言，XP的比VX的好很多。


死伤殆尽于2011-3-3 10:35补充以下内容：
RM并不是Ruby的封装。RM的核心和图形化编辑器部分在先，基于Ruby的RGSS脚本语言只是后来增加的一个功能而已，RM不是用Ruby实现的。
作者: 老邢    时间: 2011-3-3 15:15
回复 苏小脉 的帖子

我说的gui是game.exe中显示图形的部分，不是地图编辑器。ruby本身是没有显示图形、处理声音以及鼠标输入等功能的，gui包含了这些功能。说白了，就是你不能用ruby.exe做出一个显示位图，播放声音的游戏。你在脚本中用到的bitmap，audio之类的东西，不是ruby提供的，而是通过c编写的ruby扩展，然后注册给ruby解释器提供调用的。



老邢于2011-3-3 15:16补充以下内容：
资源文件的确是有版权限制，如果要作为产品发布，得重新制作。我所知道的vx地图编辑器最恼人的问题是不能分层编辑，但是我自己做的时候肯定会做成分层的，因为这样开发难度比较小。
作者: 死伤殆尽    时间: 2011-3-3 16:44
老邢 发表于 2011-3-3 15:15
回复 苏小脉 的帖子

我说的gui是game.exe中显示图形的部分，不是地图编辑器。ruby本身是没有显示图形、处 ...

Ruby没有提供那些功能，那些功能是RGSS提供的，RGSS和Ruby不能简单等同
作者: 老邢    时间: 2011-3-3 17:20
回复 死伤殆尽 的帖子

图形功能也不是rgss提供的。我说过，图形功能是c语言（也可能是其他语言，但是c的可能性最大）编写的ruby扩展，他提供了rgss中bitmap等对象的原始处理。rgss是一系列封装了游戏逻辑的ruby脚本。所以gui不是rgss提供的，没有rgss，有gui就可以直接编程。
作者: 死伤殆尽    时间: 2011-3-3 17:28
老邢 发表于 2011-3-3 17:20
回复 死伤殆尽 的帖子

图形功能也不是rgss提供的。我说过，图形功能是c语言（也可能是其他语言，但是c的可 ...

对，基本可以肯定RM使用的是C。Game.exe的名称就是RGSS Player，执行游戏的过程大体上是用它（事实上是RGSSXXX.dll），在DirectX的环境下，实现从RGSS语句和其它数据到实际游戏的转换。在没有加入RGSS编辑器功能之前的RM则是用Game.exe和其它dll执行预制好的游戏引擎并读入游戏数据文件。大致上我明白你的意思了。
作者: yangff    时间: 2011-3-3 18:17
老邢 发表于 2011-3-2 08:41
tilemap和window基本完成了。昨天半夜没睡就是在弄window，本来想都弄完的，结果上网乱转耽误时间了，一下 ...

VX的Tilemap纯属混蛋玩意（只刷新部分混蛋啊 ）
莫非是传说中的跨平台 ？？？


yangff于2011-3-3 18:19补充以下内容：
你觉得Game.exe有GUI吗？你敢说那是GUI
再说Ruby也有wxRuby啊……


yangff于2011-3-3 18:21补充以下内容：
应该是C没错了，RGSS.DLL使用的是Ruby强大的扩展性支持的，事实上就和VBA之类7788的东西是一样样的。
作者: 老邢    时间: 2011-3-3 18:22
我觉的Tilemap的动态地图设计的很巧妙啊，虽然完全没有找到算法，暴力实现的。全屏动态地图在我的milestone上30fps没有问题。
作者: yangff    时间: 2011-3-3 19:04
老邢 发表于 2011-3-3 18:22
我觉的Tilemap的动态地图设计的很巧妙啊，虽然完全没有找到算法，暴力实现的。全屏动态地图在我的milestone ...

VX的地图只多计算了宽高各32px= =导致某个脚本不能运行你说是不是罪孽深重
作者: 老邢    时间: 2011-3-3 20:52
如果自己做一個Tilemap就沒有這個問題了，理論上完全可以使用Sprite重新寫一個Tilemap。
作者: 苏小脉    时间: 2011-3-4 01:54
本帖最后由 苏小脉 于 2011-3-4 03:44 编辑
老邢 发表于 2011-3-3 15:15
回复 苏小脉 的帖子

我说的gui是game.exe中显示图形的部分，不是地图编辑器。ruby本身是没有显示图形、处 ...


Ruby 的标准库中封装了调用本地函数的抽象接口，所以“只用ruby.exe没法做游戏啊”仍然是可商榷的，取决于你如何定义“只用ruby.exe”。我是把你这句“只用ruby.exe”理解为只用 Ruby 了，那么当 Ruby 使用了可执行程序外部以 C 扩展的形式提供的 Ruby 标准库时，仍然算作“只用ruby.exe”。如果是 Win32 平台，用户可以通过 Ruby 标准库中的抽象接口调用 gdi32 和 user32 中的函数，不需要用户亲自写下任何本地扩展，就可以“显示图形、处理声音以及鼠标输入等功能”，以我的理解，这仍然是“只用ruby.exe”。其它平台也有各自的接口。当然，这样做会产生不必要的组件间通信，执行效率低。

ruby的效率并不是最重要的，gui的效率才是关键。

在你消除歧义之后，我对你这句话的理解也变成了“包含显示图形、处理声音以及鼠标输入等功能的部分才是关键”。没错，底层引擎的效率确实很关键，但对于像 RM 这种完全把执行权交给 Ruby 的宿主和寄生物的关系，Ruby 的效率也是游戏流畅性的枢纽，特别是在高层处理大量数据的时候。就 RMVX 使用的 CRuby 1.8 来说，纯粹的抽象语法树步行器，保守的 GC 算法（mark and sweep），绿色线程等机制都是致命的杀手，使得 1.8 效率低于 1.9 将近一倍。如果 RM 采用 Ruby 1.9，就能为 CPU 和 Cache 节省到近于之前一半的时间和空间。又如只是把 Ruby 的使用嵌入到特定的非重要逻辑控制的场合（如用于撰写某个 NPC 的有限状态行为的脚本），而非是完全让出执行权，可能 Ruby 层的效率也就不那么重要了。Lua 这样的轻量级语言是很容易写出高效实现的，其效率自然比所有 Ruby 实现都高，但在语言层也少了很多重要的东西。

-----------------------------------
编辑（回的时候没没看到本主题第三页）：

我说过，图形功能是c语言（也可能是其他语言，但是c的可能性最大）编写的ruby扩展，他提供了rgss中bitmap等对象的原始处理。

C++ 的可能性比较大，因为以前根据对 Game.exe 入口点的分析曾推断出该可执行程序是由微软的 VC++ 生成的，我想不至于又专门用 C 去写 DLL。

图形功能也不是rgss提供的。
rgss是一系列封装了游戏逻辑的ruby脚本。所以gui不是rgss提供的，没有rgss，有gui就可以直接编程。

能否引用一下你这些结论的资料来源？我之前所理解的 RGSS 不仅仅是高层的脚本，同时还应囊括底层引擎，是游戏引擎 + RPG 系统。从抽象接口上来看，Sprite、Viewport、Window 等虽然是引擎的部分，但他们都是可编程的，尽管实现被隐藏了，但其接口也以 Ruby 类的形式在 Ruby 之上的抽象层存在，这些接口形成了整个“脚本系统”（RGSS 中的 "SS"）的基础部分；从文件命名上来看，这些底层接口被封装到一个叫 RGSS????.DLL 的共享库中，可见实现者认为引擎也是 RGSS 的一部分。

当然，依赖于本地环境的 OS 窗口本身可以是由 Game.exe 提供的，把这个排除在 RGSS 之外倒是很合理，因为封装在 DLL 中的部分无须依赖于自己创建的窗口，而是通过外界传递进来的窗口资源标识（句柄）来处理各种和窗口有关的内容。
作者: 老邢    时间: 2011-3-4 10:36
本帖最后由 老邢 于 2011-3-4 10:50 编辑

小蘇的回復真是詳盡透徹。我以前的说法基本都错了，哈哈

首先对于ruby.exe，因為我一直使用c扩展（是lua的c扩展），所以我说ruby.exe就想指ruby的标准库。就如yangff所说，使用wxRuby之类扩展库书写的程序也是通过ruby.exe运行的。所以只说ruby.exe不能做图形程序完全没有道理。

关于ruby效率的问题也是我理解不够。以前只用过ror，而且用的也不多。

关于rgss与gui的关系，我说rgss不提供gui，这种说法也是不对的。Bitmap的确叫做RGSS内部类。我当时想说的是Scripts中的脚本，具有游戏逻辑那部分。那天下载了神兽大战倭寇，应该就是脱离了scripts自己编写的游戏逻辑，还有鼠标的支持，的确很强大。
作者: 从小就暴力    时间: 2011-3-4 12:02
哇，楼主好厉害~我的手机是android，期待能跑RMVX起来~
作者: 老邢    时间: 2011-3-4 13:33
本帖最后由 老邢 于 2011-3-4 17:19 编辑

目前完成了rm用户手册中的
RGSS 内建函数
RGSS 内建类
RGSS 内建模块
RPGVX 数据结构
在这个基础上已经可以做游戏了。目前正在翻译Scripts下的脚本，同时制作设计器。脚本翻译完成后，通过一个程序将标准的rmvx游戏数据转换成lua格式，就可以实现跨平台游戏了。设计器也可以按照自己的想法，加入宠物、坐骑之类设计界面。
作者: yangff    时间: 2011-3-4 21:33
老邢 发表于 2011-3-3 20:52
如果自己做一個Tilemap就沒有這個問題了，理論上完全可以使用Sprite重新寫一個Tilemap。 ...

有人干过，不过请相信源代码不会这么2的


yangff于2011-3-4 21:35补充以下内容：
Game.dll是C++但是Dll也就是解释器+引擎是C写的，是Ruby的拓展借口。包裹底层类也是C写的，这点从[Bi]结果可以轻易看出
作者: 老邢    时间: 2011-3-5 15:57
我看rm帮助文件里面写的“Tilemap：管理元件地图的类。元件地图是显示二维游戏地图所使用的特殊概念，在内部由多重的精灵所组成。”

不过我实现的时候没敢尝试这种方法，总觉得弄一堆对象出来太浪费内存了。

刚刚做了简单的压力测试，macbook pro，分辨率800x600，999精灵，一个动态地图，一个背景，fps在26左右，这个数据正常么？

作者: ok5677    时间: 2011-3-5 15:59
提示: 作者被禁止或删除 内容自动屏蔽
作者: tamashii    时间: 2011-3-5 16:04
没意义啊 - -
有这技术还不如单独出一个基于Lua的游戏引擎呢
作者: 老邢    时间: 2011-3-5 19:55
本帖最后由 老邢 于 2011-3-5 22:13 编辑

这就是一个基于lua的游戏引擎，只不过提供了与rm一样的底层接口。。。

刚刚在我的milestone测试了一下，854x480分辨率，60个精灵30帧左右，100个精灵20帧，降低分辨率没有多大差别。


老邢于2011-3-5 20:25补充以下内容：
刚刚测试了一下rmvx，只有999个精灵，fps显示为0。。。


老邢于2011-3-5 20:26补充以下内容：
难道是因为virtualbox的原因？


老邢于2011-3-5 20:50补充以下内容：
用pc测试也是一样，999个精灵，fps显示0...

我也不太了解rmvx，不知道这样测试对不对
  1. sprs = []
  2. for i in 1..999 do
  3.   sprs[i] = Sprite.new
  4.   sprs[i].bitmap = Bitmap.new("Graphics/Battlers/Angel")
  5. end

  7. loop do
  8.   for i in 1..999 do
  9.     sprs[i].x = rand(500)
  10.     sprs[i].y = rand(400)
  11.   end
  12.   Graphics.update
  13. end
复制代码
作者: david50407    时间: 2011-3-5 23:03
还是这句：
对于不同的分辨率的自动调整 3：4  16：9 或其他诡异的分辨率比例

不同系统的通用性 如 Mac & Win & Linux 上有键盘 鼠标, Android iDevice WMobile 上啥都没 顶多有触摸屏
不过鼠标的点击与触摸屏的又不同了
（不过这可依游戏定位）

然后再来是图形引擎的问题
你是用啥来实现图像的？
Win有Dx Linux有OGL Mac貌似也是OGL

还有底层效率
不同的实现 有不同的效率
总不能在Win下良好Mac下悲剧了

以及API的调用
要依据不同系统 写出通用的API接口
不然跨平台是跨平台了 可是却没API可用...
作者: 老邢    时间: 2011-3-6 08:06
关于分辨率，我想采取固定分辨率的方式，就是制作的时候确定分辨率，这样触摸屏响应的代码都是固定的。显示的时候进行缩放（看具体情况是全屏还是等比例），再将触摸屏实际的坐标往游戏转换。这个我在一个android游戏中已经尝试过了，各种比例都没问题。

关于输入，只支持触摸屏（鼠标），运动感应，键盘无视。

图形引擎是gl的，我现在就在mac下开发，还不知道windows悲剧不。

api接口与rgss的内部模块和类完全相同。除了输入类增加了一些功能。以后如果加入物理引擎和粒子系统还会增加一些接口。
作者: 苏小脉    时间: 2011-3-6 09:52
老邢 发表于 2011-3-5 19:55
这就是一个基于lua的游戏引擎，只不过提供了与rm一样的底层接口。。。

刚刚在我的milestone测试了一下，85 ...

像通过 Graphics.update 这样的一次性事件统一进行描绘的机制，用来管理精灵的（有序）数据结构很重要，不知道你用的什么呢？
作者: 老邢    时间: 2011-3-6 10:04
回复 苏小脉 的帖子

单向链表list = {value = nil, next = nil}
作者: 苏小脉    时间: 2011-3-6 10:55
老邢 发表于 2011-3-6 10:04
回复 苏小脉 的帖子

单向链表list = {value = nil, next = nil}

是按 Sprite#z 排序的吧，如此一来每次插入新的精灵，不是都需要线性的搜索吗？如果采用过红黑树，各种操作的最坏场合也能控制在对数级别之内:)
作者: yangff    时间: 2011-3-6 11:19
苏小脉 发表于 2011-3-6 10:55
是按 Sprite#z 排序的吧，如此一来每次插入新的精灵，不是都需要线性的搜索吗？如果采用过红黑树，各种操 ...

我靠……红黑树……你敢用AV树吗？
作者: 老邢    时间: 2011-3-6 11:28
实际上的情况是：几乎每次插入操作都在表头。。。


老邢于2011-3-6 11:32补充以下内容：
顺便问一下，猛击多个广告是否能增加网站的收入？不会当成恶意騙点击率的吧。。。
作者: 苏小脉    时间: 2011-3-6 12:34
本帖最后由 苏小脉 于 2011-3-6 15:28 编辑
老邢 发表于 2011-3-6 11:28
实际上的情况是：几乎每次插入操作都在表头。。。


不解其因，愿闻其详 o_o

yangff 发表于 2011-3-6 11:19
我靠……红黑树……你敢用AV树吗？


你是说 AVL 树？对于精灵的集合来说，再平衡的需求量（分配、回收、精灵对象以及改变其纵深时）应该大于非变异的查找，而在再平衡时的旋转运算上，AVL 树需要的时间是 O(log n)，红黑树最多旋转两次（所以是常量时间），平均下来 AVL 树插入删除的效率就不及红黑树，所以窃以为后者更适合。
作者: 老邢    时间: 2011-3-6 13:28
我还没有使用完整的游戏做测试，我想实际运用中，通过刻意控制viewport，可以减少sprite创建时产生的排序问题。回收不删除对象，只将其置空(value=nil)，显示的时候少量空值影响不大。如果反复创建回收就人为收缩一下。

最重要的，单向链表最简单，哈哈，如果因为这个问题影响了效率，我会使用小苏的方案。目前看动态地图blt的效率最低，因为vx的地图设计，一个图块需要4次blt，看来必须要使用buffer了，用空间换时间。
作者: 从小就暴力    时间: 2011-3-7 15:20
问楼主，什么时候能有android版RMVX？
作者: david50407    时间: 2011-3-11 20:29
回复 老邢 的帖子
api接口与rgss的内部模块和类完全相同。

有关系统的API呢？
例如：time, OS type... 之类的 （我也举不出啥例子）



欢迎光临 Project1 (https://rpg.blue/) Powered by Discuz! X3.1