基于Alchemy移植到Flash上的Quake

貘良了 · 发表于 2009-11-28 17:58:53

基于Alchemy移植到Flash上的Quake

Alchemy自从在Labs.adobe.com公开给开发者之后，引起了非常多的游戏爱好者的兴趣。早就在MAX时候，Adobe曾经演示过一款基于Alchemy port到Flash上的FPS游戏Quake。现在，同样是Quake游戏，完整版出现在Flash上，除了性能更加优秀之外，模拟度也非常之高，还有就是也是同样基于Alchemy进行移植的。

http://www.silvergames.com/game/quake-flash/

不知道Alchemy是什么的话。我再贴点东西：
Adobe最近发布了 Alchemy beta版本，Alchemy 能够编译C/C++代码为AS3字节码(运行在AVM2上)能够运行在Flash或者Flex平台，并且Adobe宣传Alchemy能够为计算密集型任务提升性能(但是比原生C/C++慢)，去年Adobe曾经在芝加哥AdobeMAX2007大会上通过演示Quake(雷神之锤)游戏来验证。几个月后，Adobe又通过运行 Python解析器和任天堂模拟器做了演示证明。比较有趣的一点是Alchemy是在开源 LLVM 编译架构的基础上创建的。

简而言之,Alchemy 可以提升flash游戏的性能，另复杂的计算成为可能。

貘良了 · 发表于 2009-11-28 18:01:01

只要理解flash是基于虚拟机的，而Alchemy是绕开虚拟机的就行了。

自从2007年中推出了AS3支持了面向对象的开发方式之后, 可谓动作不断. 去年又将AVM2的核心虚拟机tamarin 捐赠给了ECMA4 , 又将FlexBuild2直接升级到FlexBuild3, 这不,在08年末,又蹦出一个 Adobe Alchemy, 这在战略上具有极为重要意义. 而FLASH 从一个简单的动画客户端,一跃升级成一个未来富媒体应用程序的平台. 从这一系列战略步骤,不难看出ADOBE想成为WEB乃至桌面开发霸主的野心! 微软你要小心了. 那么你可能要问了, 为什么Alchemy这么重要呢? 作为FLASH实践者, 效率问题是众所周知的. 因为, FLASH中运行的代码是 ACTIONSCRIPT, 它是一个脚本语言.而这个语言是运行在FLASH内部的AVM2虚拟机上的. 所以它的一些功能都需要经过, 语言解释成AVM2虚拟机字节码,然后AVM2运行字节码,最后由本地NATIVE语言,也就是本机2进制程序执行.虽然这解决了平台无关的问题,但是带来一个副作用,就是比较慢,这就是为什么FLASH上一直没有杀手级应用的主要原因. 从本质上来说, 这是一个构架上的问题. 而Alchemy 的出现,从构架上,改进了这个问题,你可以使用C/C++编写核心,快速的算法,让AS3进行调用, 达到加速的目标. 这在过去,你只能使用ADOVE提供给你的内置native 程序. 现在,你可以自己干这件事情了. 既解决了平台无关的问题,又解决了效率的问题,甚至可以利用FLASH本身几十亿现有的客户端的优势,解决了渠道问题.可以这样说, Alchemy 打开了一个前所未有的时代! 让我们看看 Alchemy 到底做什么. 从ADOBE的说明文档上可以看到, Alchemy 是一个运行在低层的虚拟机 (Low Level Virtual Machine) ,他运行在AVM2之下. 那你又要问了.既然有了一个虚拟AVM2了,为什么还要一个LLVM? 其实, LLVM 将C/C++代码进行编译,并且生成RISC-LIKE指令的字节码, 存储在缓冲区之中, 在FLASH运行开始的时候, 实时翻译成机器相关的本地代码. 需要调用的时候是调用翻译之后的2进制本地代码.以此来提高整体速度.这就是LLVM的关键技术, 而运行时译 (Runtime-Compile) 这种技术有点像 .NET . 而这种LLVM和AVM2的区别是, AVM2实时解释运行脚本代码,LLVM 预编译本地运行.可以这样认为 AVM2 是 JAVA虚拟机, LLVM是 .NET虚拟机.他们在构架上处于不同的层次,满足不同需求对速度的要求. 当生成编译完成后,字节码需要保存在一个缓冲区之内. 由于在框架之内需要和AVM2兼容,所以这个缓冲区,将以 AVM2能识别的BYTEARRAY 形式保存在内存之中. 并且, alchemy自动生成一个 AS3的接口文件,以方便AS3程序进行调用. 值得注意的是, 所有C/C++编译之后的数据,都以 SWC 函数库的形式生成, 用户可以在自己的工程里 IMPORT.经过使用后发现,由 Alchemy 生成的SWC文件是比较大, 比 C/C++源文件大的多.即使一个只有几十来行的纯C 功能,生成SWC后都会有100多KB. 参考ADOBE的文档上说, 编译C/C++的代码,会将C/C++所需要的所有库,比如C标准库统统放到一个SWC里去,并且严格遵循POSIX标准. (可移植操作系统接口) 由于这种机制的存在, 我们甚至可以在C/C++里嵌入线程的支持, 来运行同步或者异步的功能. 从而弥补了FLASH是单线程这一不足! 这将是一件美妙的事情! 而本人认为,由于C/C++代码是公用一个C标准库的,所以只要SWC中的功能越多,那么从空间效率上就越是划算. 并且在目前的宽带之下,多个100来KB问题不是太大. 当然,安全问题,也是alchemy的重头戏, 我们知道, FLASH 对安全问题是有一套非常严格的措施的,比如访问本地资源后,就不能访问远程资源,访问这个域的资源后,就不能访问其他域的资源.如果你要访问,就要在另外一个域上安装一个沙箱(SecurityBox)文件,才能顺利访问. 而alchemy将C/C++带入FLASH之中,而C/C++ 是否能坏了这个规矩,让应用程序出轨呢? 答案当然是否定的,一旦这个程序被调用之后,其C/C++程序被严格的运行在一LLVM上,LLVM作为一个代理机构,向上,提供了对C/C++的平台支持,比如独立的内存空间,独立的堆栈空间,独立的线程管理机构,等等. 向下将2进制程序输送到本机CPU进行执行. 所以安全问题上是非常到位的, 所以对C/C++来说,只要LLVM环境没有提供的,它将永远访问不到. Adobe已经对 alchemy 进行了比较深度的优化,并且我相信以后将继续下去.就从用户来说,由于有了alchemy 的出现,一些对速度要求较高的算法,都可以使用C/C++来代替. 由于接口上都是AS3的接口,所以移植现有的程序将会非常轻松.比如目前游戏开发中广泛使用的那个BitmapData.CopyPixel 如果用C纯代码进行改写,那么速度将提高几十倍之多. 总结. Alchemy 的出现,开启了一个全新的时代, 未来你将会发现网业上不再是简单画面,而是充满动态的不同的效果,给于用户全新的体验.随着LLVM提供的功能加多,比如将显卡硬件的功能作为一个抽象接口提供给C/C++调用,那么将来UNREAL3出现在网页上,你千万不要惊奇.甚至WOW出现在网页上,你也不要惊奇. 因为新时代的门已经打开!

		自动登录	找回密码
密码			立即注册