CodeGear 最近推出了delphi for php，也就是php语言的Rad工具。
里面包含了整合式调试除错工具、程序代码编辑工具与跨平台部署工具。

Delphi for PHP完全支持双位的中文，内建50多个VCL for PHP组件，可以直接用PHP开发Ajax接口。
VCL for PHP是用php写的。包含了常见的窗体控制组件、Ajax组件与数据库控制组件。
点选组件的名称，便可直接打开源码自行修改。
就像pascal的delphi，或ms的vb那样，通过拖拉vcl for php来所见即所得式的开发网页程序。
也就是说，可以用这个工具简单直观的开发基于web的avg，rpg，slg式游戏。
比以前的那些开发环境方便得太多了。
（可惜，我没学过php。）

同时发布的Delphi 2007 for Win32，也有直接开发Ajax接口的能力。
也就是说今年6月要发布的C++ Builder 2007中，也会有这样的功能。
等出来后，就可以去试试做web avg了。

另外，据说Delphi for ruby也有可能就是CodeGear的下一个产品。
这很让人期待啊。
不知道CodeGear什么时候会出Delphi for python。

= =之前CodeGear把垃圾邮件发到我邮箱来了……XD
还是不怎么喜欢Borland的东西……总觉得非常没有通用性和标准性……又不稳定……

嘛，说到底PHP只是后端，
我觉得依靠浏览器和HTML自身的界面表现力要实现一个让人不会感到难受的AVG不是那么容易的……

引用:

原帖由 jaycn 于 2007-11-14 07:54 发表
= =之前CodeGear把垃圾邮件发到我邮箱来了……XD
还是不怎么喜欢Borland的东西……总觉得非常没有通用性和标准性……又不稳定……

嘛，说到底PHP只是后端，
我觉得依靠浏览器和HTML自身的界面表现力要实现 ...

拿来做游戏时，肯定是要用Ajax的。
而且Delphi for php是可以跨平台布署的。通用性应该说没有什么问题。
至于表现出来的avg能做到什么程度，只有等懂php的高手试试才知道了。

pascal上，delphi本来就有LINUX版的，另外还有一个开源项目free pascal来支持pascal。

c++上，bcb+vcl的通用性确实不行，这在KRKR上表现得特别明显。当然这和KRKR选用的库也有莫大的关系。就网上的一般评价来说，都认为BCB对标准c++的支持得更好一些。（当然bcb和vc在这方面都不如gcc）。如果krkr是用标准c++写的，移植上应该没有问题。

用bcb做大项目的人很多，他们都说bcb是很好的开发工具。国内有一个商业化了的游戏引擎叫古月，就是用bcb+OPENGL写的。5W一套，贵啊。当年borland不想开发bcb的时候，还有一大堆程序员签名强烈要求Borland继续开发BCB 。如果有不稳定的问题，他们应该不会这么狂热吧。我觉得，不稳定多半是用了第三方的库吧。

开发的成品还好……不知道为什么开发工具自身非常不稳定……
基本上我用IDE编译一次Krkr，我的机器就要崩溃一次……后来都只能导出Makefile，小心翼翼得来……

感觉现在Pascal已经完全被控制在Borland手中了，然后Borland又利用Pascal试图同化C++，然后弄出一个混合了Pascal和C++的畸形怪胎。我不知道现在怎样，但这就是以前的BCB。
至于FP、Lazarus和Delphi的兼容性，那叫一个天方夜谭……FP毕竟还是要照顾标准的为主的。而那个Delphi/BCB for Linux，或者我们应该叫做Kylix，因为没有开放源代码，已经倒在了Linux环境频繁的库版本更新中，我记得Debian 3.1上，Kylix的IDE就不能用了，只剩下一个编译器。

另：Krkr3将改用gcc作为标准编译器，使用WxWidgets作为基础框架。

krkr就是用的那个免费的bcc 5.5吧，命令行无敌。

pascal还有一个free pascal，这个东西和gcc比起来，还是一点的优点的。
像编译速度快，生成的代码效率高，等等。
不过，我就是想不通，pascal干嘛要begin end。
后来的Ruby也是，虽没有begin，却有end。
这样的写法太僵死了。

可以看到krkr3已经在写了。
除了gcc和wx，让人关心的是，他还似乎用了opengl。
看来krkr3适用的游戏类型可能会比现在的krkr2更多。
不过，要等到什么时候才会有稳定版？

其实我个人认为，avg游戏，根本没有必要去追求跨平台。
linux下有windows的虚拟机，像ro那样的大型3D游戏都可以直接在linux玩。
相对简单了许多，要求低了许多的avg，在liunx直接运行根本不会成为一个问题。

Linux下确实有一个叫做Wine的Windows模拟器，它不是一个虚拟机，而只是模拟Windows API而已……此外有一个叫做Cedega的，是Wine的修改版本，支持DirectX（实质上是映射成OpenGL运行）。
但是很可惜的，Wine并不完美，特别在执行有加密的游戏的时候加密系统一般很难正常运作。

此外，Cedega能模拟DirectX，Wine自身支持OpenGL，模拟的效率也相当不错，可以支持一些大型的3D游戏。但是两者在模拟GDI的时候都无法达到游戏需要的效率。所以，Krkr2/KAG3等使用GDI的AVG引擎在Wine下基本都无法完美运行。（不过已经很了不起了，以前AmaroK不完善的时候我都用wine模拟foobar2000放音乐听XD）
此外还有一些类似于Encoding、字体等方面的问题，使得模拟更加不容易完美。特别是高度依赖字体和字体效果的AVG类游戏。

除此之外，Wine要求被模拟的程序需要处理器和运行模拟程序的处理器相同，也就是模拟x86 Win32程序，必须使用x86的Linux。因而，Wine现在还并不是非常完美。系统的差距始终存在，平台的特性毕竟不同，依靠模拟器并不是一个很明智的行为。

所谓的可移植性，并不是x86 Linux<->x86 Win32那么简单的，真正的可移植性，是要可以移植到其它处理器，例如Sun的SPARC工作站，IBM的Power工作站和使用PowerPC核的旧苹果电脑，还有PlayStation、XBox，甚至PSP一类的游戏机上。

PS：我没听说FP生成的代码比gcc高效，倒是fp的Bug远多于gcc这是真的……

PS Again：Krkr2使用了VCL，还有一大堆官方库。光有命令行的bcc是不能编译的，还是需要BCB。他的Unicode支持完全是靠内部中间层模拟得到的，他使用的API并不是Unicode的。否则的话，我们就没有那么辛苦去做汉化的必要，直接处理下msgmap.tjs挂给用户就好了。

原来是这样。
Wine我就用它玩过oc，但是嫌他字体不好看，就放弃了。
还是虚拟机里装个windows比较好点。
他对gdi处里，我认为以后会完美的。（在桌面Linux普及前）

http://shootout.alioth.debian.or ... st=all&lang=all
这个比较中free pascal是排4。
但我记得有一个比较表中，free pascal是排1的，现在找不到了。
估计那个表上的排名是平衡了开发效率之类的因数吧。

移植性也是相对的，就比如wx，它也不是什么平台都有的。使用它的软件必然会因此受限。
应该没人先去做移植wx的工作，再移植自己的程序吧。
就像java，说是跨平台通用，但如果一个硬件平台上没有java的vm实现，java代码对它也就没有意义了。

ps. 对krkr有个很奇怪的疑问。一方面它对windows的依赖较大。另一方面，既然在windows平台上，却不用dx。不太清楚作者是怎么考虑的，能流畅跑动tjs写出来的特效的机子，还能用不上dx加速么？

我觉得所谓的可移植性，并不只是现在支持平台的数量，也包括了对其它平台的移植难度，和对可能出现的新架构的支持能力。

Wx的话……移植方面一个最大的限制就是需要多窗口支持，在游戏机上就需要自己模拟窗口管理器，这就是问题吧……要用于游戏机的话，大概底层得使用那个WxUniversal。

但是基本上，在桌面计算机平台上Wx的运行是可以保证的。Wx的后端支持Windows GDI/Mac OS X /Unix-X11 GTK+ & Motif，甚至WinCE、OS/2等等。此外，还有一个基本是平台无关的后端WxUniversal。其中，GTK+和WxUniversal这两个后端的通用性应该是相当高的，移植难度并不大。

可移植性的问题在设计软件的时候就要考虑，否则后患无穷。Krkr3如果使用Wx，不包含太多平台相关的部分，要移植到新的平台也并不是很困难的。相比之下，VCL语法上依赖了Borland的扩展，功能方面又完全在Windows API的基础上设计，而Krkr2内部的工作又使用了Windows API，这样一来，Krkr2的可移植性就相当有限了。作者曾经尝试过将他依赖于VCL的部分移出，使他可以在Win32下的VC和gcc等编译器中编译，结果失败了。之后，他又考虑把Krkr2移植到GTK平台下，结果还是失败了。这就是设计初期欠考虑造成的结果。所以，吸取了这个教训，在Krkr3中，作者一开始就考虑了多平台移植的问题。

一样的道理，我想，Java能够在手机等移动设备上那么普及，那么这东西的可移植性应该不弱。如果JVM没有使用汇编，用的是纯粹的C或者C++编写的话，那么即使更换了目标平台，只要有一个用于目标平台的编译器一样可以在短时间内移植。

虚拟机= =Windows= =我以前就是那样做的，需要一点额外的内存，不过兼容性还是不错的。[嘛，OpenGL和D3D就不要想了]

Pascal现在国际标准已经过时，而且现在的Pascal功能和结构已经几乎可以称作C的子集。我觉得这个东西可能不是很有前途的讲。FP不可能排到第一，从开发效率上讲，gcc可以利用的资源远远多于fp。

Krkr2的开发大概在1999-2000年左右。当时我觉得GDI和DDraw的效率差已经开始被硬件机能的发展填平了（我觉得这个应该是测试的结论）。当时的D3D也还没有发展到令人满意的地步，并且对D3D和OpenGL一类硬件加速的支持并不像这个年代那样天经地义。
能跑动TJS写的特效的机子，有时就是用不上DX加速，这样的机器我用了3年，用到现在，我想我可以理解低端兼容性的意义。
Krkr最大可能成为瓶颈的我觉得应该是那个虚拟机架构……

这大概就是avg引擎的特色吧。
需要的硬件条件不高，可以到处移植。
但是那些移植底层的东西，现在还不能想像。
不是说会有多难，但麻烦是少不了的。

很想知道，krkr的作者有没有考虑过，在java上写krkr3。
即使不想用vm，还可以用gjc来编译。
krkr移植上手机了。可用的平台就多了，而且都是现成的。
现在他是选了wx，wx作一个gui库，它对krkr3能有多大作用？
（除了建一个窗口容纳游戏画面外。）

原来是作者没法在krkr2上动手术了，我还以为是他认为硬件加速对avg引擎没用。
tjs的脚本引擎，做得很不错的，krkr的最大亮点，用起来也方便。
如果能单独拿出来，说不定能当lua一样用。

做为一个开源项目，krkr2＆3一直都是作者一个人在作么？
krkr3应该是对krkr2完全兼容的吧，看他开发的时间那么长。

http://shootout.alioth.debian.or ... s=1&recursive=1®exdna=1&revcomp=1&spectralnorm=1&hello=1&sumcol=1
对了，是这个，这个是内存使用量，我给记错成所有指标了。

freepascal是oo语言，开发速度当然比面向过程的gcc高。
这和类库数量多少无关的。（只要别连最起码的类库都没有。）
何况，有一个jedi组织专门为pascal类语言写类库的。

现在问题就是，freepascal能不能超过g++。
fp有一个叫Lazarus的开源rad工具，从界面到作用都是delphi的copy。
http://www.lazarus.freepascal.org/
这个工具还不完善，但要“delphi”式的思路开发应用类程序的效率，显然是不错的。

当然，这些东西的开发效率全都不如java，过时了。

不要小看Wx，Wx自身封装了面向操作系统所需要的大部分功能，包括网络、键盘/鼠标/游戏杆处理、散列表等数据结构、压缩文件处理等功能，大致上应该和GTK+（glib+gdk+gtk）差不多。Krkr自身并不是一个AVG引擎，而是一个泛用的多媒体创作工具，所以界面方面还是有一定要求的。

TJS的脚本引擎我们已经抽出来，并在gcc下编译通过了（打包成了一个静态库libgcc.a，Win32-MinGW和Debian GNU/Linux 4下都确定可用了）。而且，我们利用这个脚本引擎做了一个简单的解释器，过一段时间也许会放出来。

gcc是包含了C、C++、Fortran等各种编译器的整个GNU Compiler Collection，这些编译器属于同一个项目，使用同一个后端和不同的前端，在类似的机制下工作。FreePascal在Unix下就不要想超过gcc了，更何况大部分工具和库基本都是C原生的（包括操作系统内核本身）。
Windows下反正大家都是封闭的，发展自己的吧看看能不能发展好。Lazarus完备性稳定性都还远着了，先超过C+GTK+Glade或者Qt Designer+Qt+C++还有Wx再说吧，C/C++跨平台的RAD工具又不是没有……

OO的语言一定好么？面向对象开发并不总能增大开发速度，关键是在需要的情况下适度使用，过分抽象会成为万恶之源的。前一段调试使用了多层抽象+STL的程序时候那恐怖的感觉我可还没忘掉。

至于Java……在电脑上和在手机上的界面API完全是两回事吧……而且Java那个Swing的GUI反应速度也是慢得可以的。我觉得Java不适合大型游戏，除非拐弯去掉用DirectX、OpenGL一类的东西（但是用虚拟机处理底层操作……效率恐怕还是有限）。

至于gjc么…我倒是很奇怪那个垃圾收集机制还有Class机制都是怎么实现的，即使不用虚拟机，开一个线程一直监视内存的话效率影响也相当大的…
嘛……Sun的Java也GPL了，这两者之间的竞争会向什么方向发展也许会很有趣。不过对我目前的需求来说，Java和C#都属于那种又慢又烂又烦人的垃圾= =暂时不予考虑……

Krkr3对Krkr2完全不兼容，KAG4也对KAG3完全不兼容。如果要和现有体系兼容，就不用开发这么久了。TJS2是现成的XD
Krkr3将采用下一代的TJS语言，代号Risse。现在W.Dee本人主要的工作就在Risse的开发上。Krkr3应该会进一步提高泛用性和性能，并加入跨平台支持。

Krkr的开发是以W.Dee为领导的，但是还有数个开发者参与开发，其中渡边刚等人应该说起到的作用和W.Dee本人差不多，此外TYPE-MOON的kiyobee也在贡献者之列。

顺便说一句，Wx不止有C++支持，Python、Perl和.net也都存在的。