Project1

标题: RMXP系统里画图块的方式是每帧循环画，还是一次画好？ [打印本页]

作者: 流川枫 时间: 2007-12-27 17:47
标题: RMXP系统里画图块的方式是每帧循环画，还是一次画好？
RMXP系统里画图块的方式是每帧都用循环挨个画，还是一次画好？
说比如循环的话，就是每帧都要循环画20（或21）*15（或16）个图块```
如果是一次画好的话，就是一次画到一个内存场景里，然后每帧都只要复制一下就行````
我想这个操作应该是公开在RGSS里的吧？{/cy} [LINE]1,#dddddd[/LINE]版务信息：本贴由楼主自主结贴～

作者: 美兽 时间: 2007-12-27 18:22
一次画好，之后直接引用内存中的对象，自己查F1的cahce. [LINE]1,#dddddd[/LINE]系统信息：本贴由楼主认可为正确答案，66RPG感谢您的热情解答～

作者: 流川枫 时间: 2007-12-27 18:31
果然如此！谢谢了~~~~美兽{/tp}{/qiang}

作者: 流川枫 时间: 2009-10-8 21:13
3# 美兽
我计算了一下，RGSS不可能一次性将地图全部绘制在纹理里，应该是循环21*16对每个图块进行刷新，或者使用更好的优化算法（我自己想到一种就算每次移动只要画跨越的一行图块就行）。

RM最高500*500的地图：
32*32*500*500 = 256000000（像素）
如果是4直接的像素 256000000*4/1024/1024=976.5625（MB）
而且地图有三层，976.5625*3/1024=2.8（GB）

作者: goahead 时间: 2009-10-9 14:37
提示: 作者被禁止或删除内容自动屏蔽

作者: 流川枫 时间: 2009-10-9 15:20

再次证明TILMAP不是简单地把东西涂在一块地图大小的BITMAP上~~~~
goahead 发表于 2009-10-9 14:37

不过它也有可能更简单的循环21*16*3次来画图块。这样效率会吃掉很多的。不过我已经想到优化方法了

作者: goahead 时间: 2009-10-9 15:35
提示: 作者被禁止或删除内容自动屏蔽

作者: 流川枫 时间: 2009-10-9 18:35
8# goahead
其れは違うだよ～！
実は：
for(int y=0;y<=21;y++)
for(int x=0;x<=16;x++)
{
//draw(x,y)
}

作者: goahead 时间: 2009-10-13 09:44
提示: 作者被禁止或删除内容自动屏蔽

作者: 流川枫 时间: 2009-10-13 16:47

那是什么意思~~~~~ 我甚至不知道21*16是什么~~~~长宽的块数？
goahead 发表于 2009-10-13 09:44

這是舉個例子，因為屏幕裏同時最多可以出現21*16個圖塊大小。

作者: link006007 时间: 2009-10-13 17:08
本帖最后由 link006007 于 2009-10-13 17:14 编辑

其实这个应该去问问RGE的作者会比较好

作者: 流川枫 时间: 2009-10-13 19:40

其实这个应该去问问RGE的作者会比较好
link006007 发表于 2009-10-13 17:08

RGE是什麼？

作者: 紫苏 时间: 2009-10-13 22:30
屏幕上需要显示的只有 640 * 480 像素，也就是 1200 KB，而你在上面算的包含了不需要显示的信息，这些信息在内存中由 Tilemap 维护，显示的时候再通过算法描绘出位图，所以实际体积没有多大。内存中并没有保存着一张超大的位图。Tilemap 的显示是怎么处理的不清楚，不过归根结底还是不会脱离多缓存机制，即在缓存先循环描绘完 640 * 480 大小的所有图块，然后一次拷贝到屏幕上下文中。如果直接在屏幕上描绘，在固色填充（清除画布）的时候人眼就会看到闪烁。所以 RM 即通过循环描绘了图块，又把在缓存中描绘好的图块一次性的拷贝到屏幕上，因而你问题的答案是：Both.

作者: 流川枫 时间: 2009-10-14 16:43

屏幕上需要显示的只有 640 * 480 像素，也就是 1200 KB，而你在上面算的包含了不需要显示的信息，这些信息在内存中由 Tilemap 维护，显示的时候再通过算法描绘出位图，所以实际体积没有多大。内存中并没有保存着一张 ...
紫苏发表于 2009-10-13 22:30

いいえ、絶対に！
你誤解了我的問題，我的問題是RM是一切換地圖就一次性將地圖所有圖元（除了動態圖元）都畫在一張大紋理上，以後只需要從這張紋理上截取640*480的區域顯示，還是每次都循環21*16次將每個圖元畫到屏幕上（也可以畫到640*480的紋理上，如果不移動地圖，下次就不用循環，直接把這張紋理再貼上去）。（21*16次將重複3次，因為有3個圖層）
但是事實上，第一個方案的可行性為0，而第二個的話太浪費CPU時間片，所以RM可能用第二個方案，也可能用其他的優化方案。（其他的優化方案我想到了一個，每次移動只需要畫一行，而不是全部。）

作者: 紫苏 时间: 2009-10-15 00:21
不要在 2D 遊戲製作討論中引用 3D 遊戲製作的概念，紋理是 3D 遊戲中用 2D 位圖來渲染 3D 物體表面的貼圖技術，而 RM 中只不過是單純的位圖描繪而已～

RM是一切換地圖就一次性將地圖所有圖元（除了動態圖元）都畫在一張大紋理上，以後只需要從這張紋理上截取640*480的區域顯示

我假設你所提到的紋理是位圖的意思，我之前也說了內存中肯定不會隨時留著一張超大位圖，但內存中有 Tilemap 對象。Tilemap 對象有 map_data 成員（和 RPG::Map#data 一致），它是一個三維數組，實際保存了地圖圖塊的信息，其形式是：
data[圖塊 X 座標, 圖塊 Y 座標, 圖層編號]，其元素的類型是整型。
所以這個結構最大也只有 500 * 500 * 3 * 4 字節，也就是 3000000 B，2929.6875 KB，2.86 左右 MB，遠遠小於 500 * 500 * 32 * 32 的一張位圖。map_data 中每個元素是一個 tile_id，通過這個圖塊 id 就可以知道當前層中應該描繪圖塊集中的哪個圖塊。這時就需要 Tilemap 的 tileset 成員來引用圖塊集的位圖對象，然後就可以獲取到實際的位圖，所以緩存中，也就是 RPG::Cache，也隨時保存著一個 Tileset 的位圖對象。Tileset 中的單個圖塊是邏輯上唯一的，不會像保存一整張實際地圖的位圖那樣有很多重複的子位圖（即重複使用圖塊），而且一張 Tileset 也有尺寸限制。
可以把 Tilemap 地圖數據看成一個圖塊索引集合，它並沒有保存位圖，而是保存了圖塊的索引，實際渲染到屏幕上時只是通過圖塊索引去獲取 Tileset 中的圖塊位圖，并描繪而已～

還是每次都循環21*16次將每個圖元畫到屏幕上

還是之前說的，一般需要擦除背景的遊戲都是雙緩存，甚至更多緩存機制，圖塊肯定是循環描繪的，因為你需要一個循環來遍歷地圖上的所有圖塊。但你的循環描繪並不是直接把位圖描繪到屏幕上，而是描繪到一個兼容屏幕設備上下文的緩存設備上下文中，兩者描繪的速度不是一個級別的——前者需要在描繪后立即反映到屏幕上，而後者只是改變了內存中位圖。當一幀之間所有的需要顯示的東西都描繪到這個緩存當中后，這個緩存所維護的位圖就是一張可以呈現給玩家的遊戲畫面了，這樣直接把緩存通過內存拷貝的方式拷貝到屏幕上，即提高了效率，又避免了閃爍。

作者: link006007 时间: 2009-10-15 01:07
本帖最后由 link006007 于 2009-10-15 01:09 编辑

RGE就在这个版块里面。。。。。。。。。。。。
其实这种tile平铺地图的开源游戏多的是。
比如mana world，你如果有兴趣把他封装成一个ruby的内嵌类，
差不多就是一个带网络C/S功能的RM（当然当当了解那些SDL的函数就会吐血）

至于tile的描绘，算法本身就不唯一:可以
把该地图的图块元件载入缓存,不管你地图多大,他的内存大小始终都是图块元件的总和
只有在你需要改变某个元件的内容时，这时候看你的引擎如何处理了，大多数是为此元件专门创建一个副本
然后维护至少一个tile数组，每个元素都保存对应图块的缓存地址，显示优先级，通行情况等等信息
然后通过地图的偏移（RM里好像是ox，oy）索引到当前描绘tile数组的起始位置,以固定的行长度从数组里获取n列的tile信息。图像都是实时的贴到屏幕的(单纯的拷贝是很快的)
其实如果一个图块没有实时刷新，可以想象结果：上一帧如果有精灵在上面描绘过，那么下一帧如果不刷新（重新贴图块），那么那个精灵的图像就会留在上面.
至于RM本身如何处理，这个只有开发人员自己知道。

作者: 流川枫 时间: 2009-10-15 19:47
本帖最后由流川枫于 2009-10-15 19:52 编辑

不要在 2D 遊戲製作討論中引用 3D 遊戲製作的概念，紋理是 3D 遊戲中用 2D 位圖來渲染 3D 物體表面的貼圖技術，而 RM 中只不過是單純的位圖描繪而已～

我假設你所提到的紋理是位圖的意思，我之前也說了內存中肯定不 ...
紫苏发表于 2009-10-15 00:21

話說您怎麼也用繁體了？
您如果寫過RPG遊戲系統的話，應該就能理解我的意思。
不過很不幸，您完全沒有理解我和我所提的問。
儘管這是一個我已經宣佈解決的問題……

前面的我已經說的很清楚了，問題的答案。
我只想說明一下，RM理論上是用D3D寫的，不是DDRAW！
所以RM裏存儲圖像數據完全可能是用TEXTRUE（紋理），而不是DDRAW裏的SURFACE（頁面）。
為什麼要用D3D來做2D呢？原因很簡單，為了獲得更多的硬件加速！
就是這樣，其實紋理和頁面的區別不大，都是存儲圖像數據的媒介而已。

作者: 流川枫 时间: 2009-10-15 20:02

RGE就在这个版块里面。。。。。。。。。。。。
其实这种tile平铺地图的开源游戏多的是。
比如mana world，你如果有兴趣把他封装成一个ruby的内嵌类，
差不多就是一个带网络C/S功能的RM（当然当当了解那些SDL的函 ...
link006007 发表于 2009-10-15 01:07

SDL雖然沒用過，但是查看了相關的文檔，感覺可以用到的硬件加速很少。
SDL和DDRAW都很簡單，不過我覺得最簡單的是D3D，只不過元素多一點。
RGE是什麼？我猜 RPG GAME ENGINE？

作者: 流川枫 时间: 2009-10-15 20:08
哦，是RUBY GAME ENGINE啊。
好無奈啊

作者: link006007 时间: 2009-10-15 20:10
本帖最后由 link006007 于 2009-10-15 23:55 编辑

SDL雖然沒用過，但是查看了相關的文檔，感覺可以用到的硬件加速很少。
SDL和DDRAW都很簡單，不過我覺得最簡單的是D3D，只不過元素多一點。
RGE是什麼？我猜 RPG GAME ENGINE？ ...
流川枫发表于 2009-10-15 20:02

SDL硬件加速多还是少, 至少我不敢说... 因为SDL只不过是一个相对DX或GL高阶的图形库,它本身并不会直接和硬件打交道... DX(7)或GL对硬件有多大的支持, SDL就有多大...

既然你觉得D3D或DDraw很简单... 那就没有必要争论RM的tile如何描绘了
因为几乎所有用D3D写的游戏都有这么一个更新规则(DDraw也差不多,如果不是单缓冲的话):
Clear->BeginScene->your_scene_update_function->EndScene->Present

从RM对精灵的处理能力上来说,不太像用D3D写的
夏娜的RGE的原型HGE用的就是D3D, 在HGE里面,一个屏幕同时渲染2000个精灵(这些精灵每帧都在做旋转,缩放)时,在我的机器上FPS可以达到250+, 如果是RM...有谁可以再一个屏幕里面同时旋转缩放数百个精灵?
如果说是因为封装成ruby后的性能损失..ms也损失的太过分了- -
而且从RGSS102J.dll中也没有明显的连接d3d库的信息
个人觉得RM很多地方还是用软件处理图像... 旋转多个精灵时的FPS掉的太猛了,在RM的帮助文档里面也有提示旋转很发费时间... 如果是硬件加速, 单单旋转应该不会这么在意,在3D里面这算小的了

作者: 紫苏 时间: 2009-10-15 23:16
咦，原來“前面你已經說得很清楚了，問題的答案”？這麼說來前面那些“二選一”的“看似問題”都是在陳述撒……明白了！ =v=

先不说 D3D 也有 Surface、不懷疑 RM 是否用 D3D 寫的——RM 歸根結底是 2D 遊戲引擎，用的紋理也好表面也罷，都是畫布的概念，如果你用 GDI，甚至 Java 寫過遊戲，你就知道爲什麽你說的“第二個的話太浪費CPU時間片”這句話僅僅適用於“直接往屏幕上畫”了。在內存中循環畫出 640 * 480 大小的圖塊，較之直接畫出 640 * 480 的圖慢不了多少。我在 16 樓第二段針對的就是你這句話。

最後，確實沒用 D3D 寫過引擎，不知是否方便指點一下我是如何理解錯誤的呢？

作者: link006007 时间: 2009-10-15 23:35
本帖最后由 link006007 于 2009-10-15 23:53 编辑

发多了 - -

作者: 流川枫 时间: 2009-10-16 20:26
本帖最后由流川枫于 2009-10-16 20:27 编辑

SDL硬件加速多还是少, 至少我不敢说... 因为SDL只不过是一个相对DX或GL高阶的图形库,它本身并不会直接和硬件打交道... DX(7)或GL对硬件有多大的支持, SDL就有多大...

既然你觉得D3D或DDraw很简单... 那就没有必要 ...
link006007 发表于 2009-10-15 20:10

HGE的那个2000范例，在我机器上卡到只有7FPS。
DDRAW是LJ，这点是每个对比过DDRAW和DX9的程序员的一致肯定。
您对我们的理解是错误的，我们指的是我和我的提问。
因此，在您了解我们之前，请自重。

另外，无论是用TEXTRUE还是SURFACE，在DX9里都可以实现，这种问题请无视。

作者: 流川枫 时间: 2009-10-16 20:51

咦，原來“前面你已經說得很清楚了，問題的答案”？這麼說來前面那些“二選一”的“看似問題”都是在陳述撒……明白了！ =v=

先不说 D3D 也有 Surface、不懷疑 RM 是否用 D3D 寫的——RM 歸根結底是 2D 遊戲引擎， ...
紫苏发表于 2009-10-15 23:16

错误是必然存在的，正因为有错误才会有真实。
您一次又一次的误解，一次又一次的为您的误解而辩驳，一次又一次一次又一次……
但是，您所做的所有努力的出发点本身就是一个错误。
讨论问题时，最糟糕的不是找不到问题的答案，实际上却是对方的误解。
为了让对方明白自己的看法和观点，往往需要费耗尽体内近乎一半的查克拉。
如果您不能透过事物的表象看到其实质，您的讨论就等于在和妄想的对方讨论根本不存在的问题。

我的最后通告，我主张的问题RM是按1号还是2号方案或者其他：
1.只一次将地图上所有图元（除动态）绘制到缓存（不管是纹理还是页面，甚至是其他），以后刷新地图只需要从改缓存中截取640*480的区域绘制出来（不管绘制到屏幕上，还是另外一个缓存）。

2.每次需要刷新地图时，循环N次将每个图元一个一个一个一个地从地图元件图片上绘制出来（不管是绘制到屏幕上还是绘制到另一缓存）。（该方案一次刷新最少需要循环20*15*3=900次，为了将3层地图图元都绘制出来。这和只要绘制3次640*480的图像的1号方案相比，要花费更多的性能。尽管画出来的图像大小都相同，但是前者只要绘制3次，后者需要绘制900次。当然不一定到900次，但是最少也有300次，因为地图图层1是画地板的地方。）

作者: link006007 时间: 2009-10-16 21:54
本帖最后由 link006007 于 2009-10-16 22:59 编辑

我没打算介入你们的问题,我只知道描绘都是覆盖静态的图像,所以必然会有清屏和分层
我只是对你说的(1)"RM用D3D",又"是每帧描绘还是一开始画好",和(2)"SDL没有太多可用的硬件加速"感兴趣而已.
另外:
对感兴趣的问题都要自重那最好不要发帖,说多了什么都漏了,因为我是觉得有错误才能够自重,所以实在不好意思
我错在什么地方请你指出来
上次紫苏那个Viewport.Rect的我错了,和goahead的那个动画的,我也错了(加上潜水以前的,太多了),我感谢他们都可以指出

另外不要拿DDraw和DX对比....
最后确认下你那个FPS是7是可能的,比我N卡6800原始好多的,,,

作者: 紫苏 时间: 2009-10-17 00:25
本帖最后由紫苏于 2009-10-17 00:30 编辑

错误是必然存在的，正因为有错误才会有真实。
您一次又一次的误解，一次又一次的为您的误解而辩驳，一次又一次一次又一次……
但是，您所做的所有努力的出发点本身就是一个错误。
讨论问题时，最糟糕的不是找不到问 ...
流川枫发表于 2009-10-16 20:51

很抱歉浪费你的查克拉了，不过你的“最后通告”除了照搬你之前的问题和添加了对前面的讨论的一些注释之外，并没有指出你所谓的“我的理解错误”何在。

你现在就好像在给一个参与讨论，但你却觉得误解了你问题的人说：“你的讨论不OK，不work，你知道这世界上什么最糟糕吗，不是找不到解答，而是解答和问题不搭界，请你不要只看事物的表面，而是看清其本质，你是在妄想和对方讨论不存在的问题，但是，我才不试图让你明白我的问题呢，因为我要节约我的查克拉。”姑且先不用“我提出了问题，问题就存在，存在即合理”来跟你抬杠，我只是想表明一下我目前的心态，那就是——找出错误并改正。可惜的是，我们来回三四贴了，一直没有从你那得到这个机会。

那么师兄，我最后来尝试评论一下你的方案，尽量引用你的原文，如有半分误解，万望指点则个。虽然不好意思浪费你的查克拉，但是作为一个讨论者，我不想被人说理解错误，但是周旋了两三个回合之后还不知道对方所谓的错在哪儿……本着学习的心，也希望你不吝赐教 Orz

方案#1，你自己也算过了，那是不可能的，挥霍这般巨大的空间，没有什么游戏会这么做，而我在本贴中所有回帖也对此持积极态度——确实不可能。

方案#2，你在 25 楼之前对这个方案的看法都是“太浪费 CPU 时间”，所以我只能假设你这个方案是直接画到屏幕上，因为在内存中，即便是循环几百次，每次描绘 32 * 32 的位图，那在当今的硬件条件下，也不至于“太”浪费 CPU 时间。既然你的方案是直接画到屏幕上，那当然不可取，于是我提出了双缓存。在双缓存的机制下，你先要“循环N次将每个图元一个一个一个一个地从地图元件图片上绘制出来”到缓存上，然后你要快速地拷贝到屏幕上，所以前者是循环描绘，后者是一次描绘（拷贝），只不过这里的一次画好不是说一次画好整个地图，而是一次画好 640 * 480 大小的一个地图区域。

另外，我早就应该指出这一点：你这两个方案，无论哪一个，都有一个循环描绘图块的过程。方案#1是所谓的“只一次将地图上所有图元绘制到缓存”，你怎么个“一次绘制”法？map***.rxdata 是仅有的保存地图数据的文件，里面保存的 RPG::Map 对象有两个关于图块的属性，tileset_id 和 data，而后者和之前提到的 Tilemap#map_data 默认是永远保持一致的，在 Spriteset_Map 生成的时候，相应的 Tilemap 就生成了，而 Tilemap 的 map_data 属性就和当前的 RPG::Map#data 绑定了起来。然而，这个 data 它仅仅是一个图块的索引的集合，你只有索引，怎么“一次画好”？你只能循环遍历 data 数组，通过图块索引去访问 tileset 的相应图块，然后循环描绘到缓存。

于是：
方案#1要循环描绘图块到缓存；
方案#2要循环描绘图块到缓存；
方案#1要描绘的图块 >= 300 个；
方案#2要描绘的图块 = 300 个。

如果方案#1有着上述性质，且还是“牺牲空间换来了速度”的话，那方案#2 加上双缓存机制只能更快，不可能更慢。我注意到了你两个方案的括号中的内容，说什么不论是绘制到屏幕还是缓存，这压根就不能“不论”，因为两者在绘制时间上有天壤之别。

其实这贴应该讨论的是地图图块的绘制方式，而不是非要在你这两个选项中选一个，因为根据你的描述，你这两个选项单选任一个都不对。然而你在 25 楼又不动声色地加了一个“其它”，那我当然也要改一下我的答案，那就是其它。既然如此，我自始至终都是在议论地图图块的绘制方式，又有何“对你问题的解错误”可言？

作者: 流川枫 时间: 2009-10-17 18:52
本帖最后由流川枫于 2009-10-17 18:54 编辑

很抱歉浪费你的查克拉了，不过你的“最后通告”除了照搬你之前的问题和添加了对前面的讨论的一些注释之外，并没有指出你所谓的“我的理解错误”何在。

你现在就好像在给一个参与讨论，但你却觉得误解了你问题的人 ...
紫苏发表于 2009-10-17 00:25

我對您的無知表示同情。
現在已經不再是誤解不誤解的問題了，以您的智商我很難和您解釋。
您不是誤解，而是以您的智慧根本不能理解。

作者: 流川枫 时间: 2009-10-17 18:57

我没打算介入你们的问题,我只知道描绘都是覆盖静态的图像,所以必然会有清屏和分层
我只是对你说的(1)"RM用D3D",又"是每帧描绘还是一开始画好",和(2)"SDL没有太多可用的硬件加速"感兴趣而已.
另外:
对感兴趣的问题 ...
link006007 发表于 2009-10-16 21:54

您繼續和您妄想出來的東西做鬥爭吧。
您們兩位，請先學好遊戲編程再來和別人討論技術問題吧。
現在的您們，沒有讓我認同的資格。

作者: 流川枫 时间: 2009-10-17 19:02
還是讓美兽出來回答您們的錯誤吧，我在幾樓前就已經解決所有問題了。

作者: 霜冻之狼 时间: 2009-10-17 19:05
提问区也要战了么？
强帖留名……

作者: link006007 时间: 2009-10-18 01:50
本帖最后由 link006007 于 2009-10-18 15:19 编辑

lz你好,lz生气了!! lz再见..............

作者: 猫哥哥 时间: 2009-10-18 07:57
引擎和游戏逻辑是两码事。直接拿directx写游戏逻辑不方便。就像有了汽车还用骑马，除非马术很高超。

windows下的SDL包装的directx，硬件加速没问题，可以用OpenGL
HGE是包装的directx8，用了D3D
RGE内核目前是HGE

作者: 胖达达人 时间: 2009-10-18 08:06
不明真相的群众前来围观。

作者: 流川枫 时间: 2009-10-18 16:15

引擎和游戏逻辑是两码事。直接拿directx写游戏逻辑不方便。就像有了汽车还用骑马，除非马术很高超。

windows下的SDL包装的directx，硬件加速没问题，可以用OpenGL
HGE是包装的directx8，用了D3D
RGE内核目前是HGE ...
猫哥哥发表于 2009-10-18 07:57

我看过HGE的源代码，但是看不出HGE到底哪里好了。
这么简单的封装，还不如直接用DX9。

作者: 流川枫 时间: 2009-10-18 16:18

lz你好,lz生气了!! lz再见..............
link006007 发表于 2009-10-18 01:50

本当の鬼を見せてやる。

作者: 奶油Da蛋糕 时间: 2009-10-18 18:25
楼主

佩服

作者: 猫哥哥 时间: 2009-10-18 19:15

我看过HGE的源代码，但是看不出HGE到底哪里好了。
这么简单的封装，还不如直接用DX9。
流川枫发表于 2009-10-18 16:15

想起了一个老外说过的话：people who knows DriectX thought they are elite....楼主你觉得直接用DirectX好用，当然不会明白小的们喜欢偷懒，不敢重复制造车轮的心态了……:(

HGE是自带了GUI的，还有粒子和动画精灵……以及更多……简单的封装…… = =b

作者: 流川枫 时间: 2009-10-18 19:32
本帖最后由流川枫于 2009-10-18 19:34 编辑

想起了一个老外说过的话：people who knows DriectX thought they are elite....楼主你觉得直接用DirectX好用，当然不会明白小的们喜欢偷懒，不敢重复制造车轮的心态了……:(

HGE是自带了GUI的，还有粒子和动画 ...
猫哥哥发表于 2009-10-18 19:15

不是說不要用引擎，而是要選個功能更全面的引擎。
HGE的功能實在是太少了，假如您需要手柄控制，HGE根本不提供這個功能，您衹有自己用DX底層代碼去寫。（HGE是用GetAsyncKeyState函數獲取輸入的。）
那個GUI連個P用都沒有，如果要做像RM那樣的GUI，還是要自己寫才行。

作者: 猫哥哥 时间: 2009-10-18 21:06

不是說不要用引擎，而是要選個功能更全面的引擎。
HGE的功能實在是太少了，假如您需要手柄控制，HGE根本不提供這個功能，您衹有自己用DX底層代碼去寫。（HGE是用GetAsyncKeyState函數獲取輸入的。）
那個GUI連個P用 ...
流川枫发表于 2009-10-18 19:32

比HGE优秀、全面的2D引擎当然有，还不少，不过都是收费的。:(

RM的GUI和没有GUI没差别……

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