[推荐]delphi for php

shawind

原来wx还有这么多功能，学到了一点，有空就去看看wx文档。

果然把tjs给抽出来了，期待这个东西的发布。
不知道嵌入使用，简单不。

看来不用java理由也是因为它慢。java写命令行的未必慢，gui基本上没法顺心。
两年前想学这个的，后来看到javabuilder那个运行速度，立刻放弃了。
c＃其实倒不是很慢，就是启动的时候很慢，平台适应能力连c++都不如。
好像开发kkde的那个作者就说过，c＃的程序太重了。
这两个对底层的调用，好像也不差多少。
dx sdk中，就有托管的dx例子，看着还可以。

Risse，又开发了一个新的脚本语言，这些人真是利害。
都说不要重复发明轮子，他们似乎已经发明了不少了。
感觉他们在脚本语言上的野心蛮大的，不会是想再造一个ruby吧。

krkr虽然是个多用平台，但是也很多的限制，如只能用gdi等，还有是多了kag这一中间层。
印像中，只有一个日本人用krkr做一个stg引擎，而且还没发布出来。
这样一来，就导至了多数人只是用它做avg而已。
不说hs，就在日本人的站上，对它的介绍也就是说它是avg制作工具。
对于学了很多tjs，并能熟练使用的人来说，
他们更有可能去选c，c++等语言的引擎，以获得更好的效率和自由度。
krkr的定位就有点尴尬了。
看介绍，虽然krkr也有好几位开发人员，但为krkr开发各正tjs程序的并不多。
估计kiyobee写了不少，fate中tjs的运用相当引人注意。

krkr和rmxp很不相同。
rmxp用的ruby，ruby慢是慢，但用处比tjs广得多了，乐意去学的人相应也多点。
因此也想到，krkr3会不也遇到krkr2这样的情况？
本来应该是一个多类型游戏，最后却只能是一个特别强的avg工具。
残念。

pascal是个异类。能在c＃，java，c++的围攻下，活到现在。
事实说明他可能还是有优点的，尽管不多。
我估计这些人写begin end习惯了，没法适应｛｝吧。 [s:2]

Miliardo

嵌入使用……嘛……和写Kr的DLL插件的难度差不多吧……原理是一样的……个人觉得挺简单的……

至于Krkr的STG……其实我们也正在玩XD= =

至于Krkr比较夸张的粒子……Fate / Hollow Ataraxia集成了数个小游戏，包括一个ACT，还有一个纸牌游戏……shawind大可以看看……

至于Risse，目标是至少达到现在TJS2的执行效率。TJS毕竟还是比Ruby快很多的。我目前没有看到一个相同的引擎具有和TJS2一样的设计和执行效率，所以我想，也许是作者需要设计这么一种语言所以设计的。

Krkr2虽然现在是一个泛用工具，但是实际上那个引擎确实是从一个纯粹的AVG引擎开始起步的，历史因素也是一个原因吧。
而Krkr3完全和现在的架构不同了……首先图形效率可能会有提高，此外很可能不会内置KAGParser= =（也许会作为插件提供，或者直接把剧本编译成字节码），好像希望更多让用户通过TJS去得到更强的功能……

Pascal不是一个很糟糕的语言，现在的问题就在于失去了标准。

至于RMXP……顺便问下大概做STG在典型的机器上，30fps能处理多少个精灵？
……我觉得制作非内置类型游戏的方面，国内RMXP的用户群远多于Krkr的……

shawind

等你们的stg弄出来后，看看会有什么效果。

很有兴趣的问问，fate里面付的那些游戏是多大分辩率的？几GHZ的cpu下，fps一般多少？
（Fate / Hollow Ataraxia，我没下到这个东西。）

我看，krkr3也有点失去方向了。
如果把kag剥离出来，最后出来的东西和ogre+lua，irrlicht+java或是微软的那个xna，有什么区别呢？
还花了那么大的力气，去做一个不通用的脚本语言，还不对已前的旧有资源兼容，真有点弄不懂他们是怎么想的。
或许这么随意，反而会出极品吧。

rmxp的效率我也没有测过。现在机子上根本没有rmxp。
以前看看rmxp中默认的fps，图形是20,40fps，脚本是40fps。想高，都没有。
不知道他原来默认的刷新图形办法是不是基于脏矩形技术的。
另外还有碰撞算法等等，完全不知道他的后台是怎么实现的。
可以先写一个demo测测看。
rmxp就是IO部分慢，资源全载入后，速度还可以。（我2.5g的CPU）
估计300-500个，应该是可以的，更多的就不知道了。

Miliardo

FHA是800x600，fps我没法统计……反应速度么……
反正在97年左右的机子上会比较卡……不过总体在稍好些的机器上还算相当流畅……

我们测试大概33fps左右，Krkr大概最多可以支持250-350个粒子吧……
如果控制好屏幕尺寸什么的我想应该足够了……

嘛……吉里吉里3/KAG4的设计现在并没有确定，我所说的只是作者的意向和曾经的想法……
Risse在语法上和以前不会差别太大，但是具体的图形等方面现在还没有确定。不过不完全兼容以前的东西这一点应该是不必疑问的。

= =RMXP不仅IO慢，我觉得Ruby自身的速度就很成问题。所以用着破烂本本的我基本不敢碰……

yoxola

RMXP的圖形是基於D3D8加速，並且把圖像繪在平面上的「硬件加速2D」，
除了表現能力很強之外，在支持D3D且VRAM足夠的情況下，速度應該飛快，
而且像擴大，縮小，混合等等都很強大。

但是腳本語言用的是RUBY，儘管大家說他多好用多簡單，
憑良心說，我沒法把他歸類為高速的語言，尤其對於中低階系統。
(如果哪天更好的VM/JIT寫出來，那也不關RMXP的事)
而RMXP的事件，還要基於RGSS解析，自然更慢了。

我會繼續用那些RMXP用戶覺得落伍的BASIC吧，
不過我很清楚，對於FreeBASIC/BitzBasic這些編譯器來說，
光是介面就原始到不行(FB甚至還要用命令行)，會嚇跑很多用戶。

Miliardo

我觉得RMXP可能是DDraw加速，不可能是D3D加速，除非内置双后端……
因为我本本的显卡完全不支持任何硬件加速，D3D8/9连HAL设备都创建不了，但却可以正常运行RMXP的游戏。

Ruby设计的理念似乎就是简单……XD
不过我还真不知道，Ruby有JIT么？按理上说用了JIT优化的东西速度应该不会太糟糕……
……但是我总觉得JIT对可移植性的危害很大……

= =我总觉得Ruby的龟速和Python有得一拼了，大概比Python还要慢不少吧……
估计可能和Tcl差不多慢……ORZ

嘛……我现在有点神经过敏……除了开放源码的脚本语言和C/C++之外我不怎么敢用别的语言= =
特别对于高度封闭的东西，有标准却故意破坏标准的东西，还有某些专有而又奇奇怪怪的专用语言……
总感觉不能掌握在手中又不能保证知识稳定性和通用型的东西不怎么可靠……可能是吃的苦头比较多有点过敏了……

shawind

rmxp的我试了一下，结果连10个都不能跑。
300个以上内存疯涨,1G一会就没了。
我ruby没学好，所以也写不好，就利用他自己的原来的sprite和bitmap，不知道这里面要怎么取巧优化。可能要用hash表什么的（不是太懂这个）。
但就启动瞬间，内存耗不多时的情况来看，3，500个没有问题。（如果能解决了内存耗用问题）

ps.python比lua还快一点点，比ruby更是快了一倍以上。
ps2。作那个测试的时候，查了一下帮助，原来rmxp也是可以自定义帧率的,最高可到120.

yoxola

剛好可以測試一下顯卡，在此給出兩個範例

1.GDI繪圖
http://bugdie.org/_wrx/SnakeInvaders.zip

2.D3D7硬件加速
http://bugdie.org/_wrx/VectorZone.zip

不支持D3D的應該是不能跑第二個，至於是什麼工具編譯的，先不說明。
DDraw我還真沒什麼用過...我覺得要在那種環境下實現縮放旋轉很吃力，
實際作過的人應該很清楚。

shawind

うそ！SnakeInvaders, 更本无法启动。而VectorZone正常。
不会我的机子只支持d3d，不支持gdi吧。

缩放什么的，有不少现成的代码可以借鉴，写起来不难。
问题在于这样做，只能是软件处理，硬件加速功能就用不上了。
怪可惜的。

Miliardo

VectorZone是C++加上HGE吧……
SnakeInvaders我猜应该是Delphi或者BCB，或者其衍生物，那个出错信息应该是Borland的风格……

猜错了不要骂我，我两个都没用过，都是猜得……

PS，SnakeInvaders我也无法运行……