正在复制rmvx，请大家给点建议

老邢

回复 死伤殆尽 的帖子

图形功能也不是rgss提供的。我说过，图形功能是c语言（也可能是其他语言，但是c的可能性最大）编写的ruby扩展，他提供了rgss中bitmap等对象的原始处理。rgss是一系列封装了游戏逻辑的ruby脚本。所以gui不是rgss提供的，没有rgss，有gui就可以直接编程。

死伤殆尽

老邢 发表于 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-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的东西是一样样的。

老邢

我觉的Tilemap的动态地图设计的很巧妙啊，虽然完全没有找到算法，暴力实现的。全屏动态地图在我的milestone上30fps没有问题。

yangff

老邢 发表于 2011-3-3 18:22
我觉的Tilemap的动态地图设计的很巧妙啊，虽然完全没有找到算法，暴力实现的。全屏动态地图在我的milestone ...

VX的地图只多计算了宽高各32px= =导致某个脚本不能运行你说是不是罪孽深重

老邢

如果自己做一個Tilemap就沒有這個問題了，理論上完全可以使用Sprite重新寫一個Tilemap。

苏小脉

老邢 发表于 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 中的部分无须依赖于自己创建的窗口，而是通过外界传递进来的窗口资源标识（句柄）来处理各种和窗口有关的内容。

老邢

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

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

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

关于rgss与gui的关系，我说rgss不提供gui，这种说法也是不对的。Bitmap的确叫做RGSS内部类。我当时想说的是Scripts中的脚本，具有游戏逻辑那部分。那天下载了神兽大战倭寇，应该就是脱离了scripts自己编写的游戏逻辑，还有鼠标的支持，的确很强大。

从小就暴力

哇，楼主好厉害~我的手机是android，期待能跑RMVX起来~

老邢

目前完成了rm用户手册中的
RGSS 内建函数
RGSS 内建类
RGSS 内建模块
RPGVX 数据结构
在这个基础上已经可以做游戏了。目前正在翻译Scripts下的脚本，同时制作设计器。脚本翻译完成后，通过一个程序将标准的rmvx游戏数据转换成lua格式，就可以实现跨平台游戏了。设计器也可以按照自己的想法，加入宠物、坐骑之类设计界面。