幻想森林

 找回密码
 立即注册
搜索
热搜: 活动 交友 discuz
查看: 8473|回复: 24

[推荐]delphi for php

[复制链接]

136

主题

1751

帖子

548

积分

版主

Rank: 7Rank: 7Rank: 7

积分
548
发表于 2007-4-11 00:33:54 | 显示全部楼层 |阅读模式
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。
え~え~お!!!
回复

使用道具 举报

18

主题

428

帖子

5260

积分

⑦老手

在美工荒中挣扎的全能

积分
5260
QQ
发表于 2007-4-11 01:24:08 | 显示全部楼层
= =之前CodeGear把垃圾邮件发到我邮箱来了……XD
还是不怎么喜欢Borland的东西……总觉得非常没有通用性和标准性……又不稳定……

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

使用道具 举报

136

主题

1751

帖子

548

积分

版主

Rank: 7Rank: 7Rank: 7

积分
548
 楼主| 发表于 2007-4-11 10:09:00 | 显示全部楼层
拿来做游戏时,肯定是要用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 。如果有不稳定的问题,他们应该不会这么狂热吧。我觉得,不稳定多半是用了第三方的库吧。
え~え~お!!!
回复 支持 反对

使用道具 举报

18

主题

428

帖子

5260

积分

⑦老手

在美工荒中挣扎的全能

积分
5260
QQ
发表于 2007-4-11 11:44:50 | 显示全部楼层
开发的成品还好……不知道为什么开发工具自身非常不稳定……
基本上我用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作为基础框架。
回复 支持 反对

使用道具 举报

136

主题

1751

帖子

548

积分

版主

Rank: 7Rank: 7Rank: 7

积分
548
 楼主| 发表于 2007-4-11 12:11:58 | 显示全部楼层
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直接运行根本不会成为一个问题。
え~え~お!!!
回复 支持 反对

使用道具 举报

18

主题

428

帖子

5260

积分

⑦老手

在美工荒中挣扎的全能

积分
5260
QQ
发表于 2007-4-11 15:05:02 | 显示全部楼层
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挂给用户就好了。
回复 支持 反对

使用道具 举报

136

主题

1751

帖子

548

积分

版主

Rank: 7Rank: 7Rank: 7

积分
548
 楼主| 发表于 2007-4-11 16:08:20 | 显示全部楼层
原来是这样。
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加速么?
え~え~お!!!
回复 支持 反对

使用道具 举报

18

主题

428

帖子

5260

积分

⑦老手

在美工荒中挣扎的全能

积分
5260
QQ
发表于 2007-4-12 12:23:29 | 显示全部楼层
我觉得所谓的可移植性,并不只是现在支持平台的数量,也包括了对其它平台的移植难度,和对可能出现的新架构的支持能力。

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最大可能成为瓶颈的我觉得应该是那个虚拟机架构……
回复 支持 反对

使用道具 举报

136

主题

1751

帖子

548

积分

版主

Rank: 7Rank: 7Rank: 7

积分
548
 楼主| 发表于 2007-4-12 16:01:09 | 显示全部楼层
这大概就是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 ... ello=1&sumcol=1
对了,是这个,这个是内存使用量,我给记错成所有指标了。

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

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

当然,这些东西的开发效率全都不如java,过时了。
え~え~お!!!
回复 支持 反对

使用道具 举报

18

主题

428

帖子

5260

积分

⑦老手

在美工荒中挣扎的全能

积分
5260
QQ
发表于 2007-4-12 17:58:35 | 显示全部楼层
不要小看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也都存在的。
回复 支持 反对

使用道具 举报

您需要登录后才可以回帖 登录 | 立即注册

本版积分规则

Archiver|手机版|小黑屋|幻想森林

GMT+8, 2024-3-28 21:00 , Processed in 0.027516 second(s), 21 queries .

Powered by Discuz! X3.4

© 2001-2017 Comsenz Inc.

快速回复 返回顶部 返回列表