Share

Welcome to Q3FL

Update (10/31/2011): Mouse lock is on its way to Flash, yay!

Update (10/09/2011): Following some changes in Stage3D's API since the release of Flash 11 on 10/03/2011, the game was not working anymore. That's fixed! :D

Known issues:

Similar projects in HTML5:

Thanks again to id Software for their great games, and thanks to iq¹² for hosting that page.



Original post (03/03/2011):

Q3FL is an experimental port of Quake 3 for Flash. This port is powered and exists thanks to Molehill, the Flash 3D API released on 02/27/2011.

To make it work you will need to install the Flash Player Incubator which is like a public beta of the new Flash Player Flash Player 11.

The goal here is not to give an accurate and playable port of Quake 3 online, but to show what Flash is now capable of. I don't have time to put the finishing touches on Q3FL, and the Flash Player Incubator still lacks some features like a real mouse capture system, which will hopefully be available in the final release. As for now, if you want to play Quake 3 online, I advise you to try Quake Live, it's free.

Enjoy !

About that Quake 3 port

Q3FL is an experimental port of Quake 3 for Flash. This port is powered and exists thanks to Molehill, the Flash 3D API released on 02/27/2011. To make it work you need to install the Flash Player Incubator which is like a public beta of the new Flash Player.

Being part of the Molehill prerelease program, I started to look at the Quake port made by Michael Rennie a couple of years ago thanks to Alchemy. The first port was based on the original version of Quake, which includes a software rasterizer. So I took this code and adapted it to port GLQuake, the version using OpenGL.

Basically in the original port the idea was just to leave John Carmack’s engine do its job in C and then copy the resulting frame buffer from the Alchemy memory to a displayed Bitmap. However for GLQuake the approach was different because we have to replace all OpenGL calls by Molehill equivalents.

During one frame there can be at least ten thousand GL calls and there is a problem with that because we can’t directly access the Molehill API from C code, and there is a huge function-call overhead between C code and Flash objects.

Consequently I had to transform every OpenGL call into pseudo instructions stored in memory, then finally flush everything in a single call. But that wasn’t enough because it’s still too heavy for each glBegin/glEnd to do a vertex/index buffer upload and then draw. The solution is to check and draw only when a state changes, like when there is a call to glOrtho, glBind, glBlendFunc.

In the end it was working but that’s clearly not a good benchmark for Molehill because there are too many things in GLQuake tied with the legacy software engine. For example lightmapping and animated textures are rebuilt in software, that could be done with a pixel shader with Molehill. Moreover mesh animations and shadows are calculated in software as well. In GLQuake the hardware is just used for the final rendering, so that port isn’t really taking advantage of Molehill.

From there I looked if it was feasible to make a quick port of Quake 3, which was not possible before since Quake 3 unlike its predecessors does not include a software rasterizer. And this has actually not been very long (a hundred of hours) since the id Tech 3’s code is very similar to the id Tech 2’s one. You can download the sources of Q3FL here.

Obviously the performances are not that good, but that’s not Flash’s fault. First as I just said the id Tech 3 is similar to the id Tech 2, and in this sense much of the problems I mentioned for GLQuake found themselves in Quake 3, especially the fact that he does not use vertex or pixel shaders.

Besides as you know (or not) the id Tech 3 embed a virtual machine interpreting all the gameplay and AI subroutines in a language called QuakeC with bytecode compiled from pure C using LCC and QVM. The source code contains three versions of that virtual machine : a JIT compiler for x86, a JIT compiler for PPC, and a pure interpreted version. Of course I didn’t make a JIT compiler for the AVM2, so nearly 50% of each frame time is spent interpreting the QuakeC code. Imagine a virtual machine within a virtual machine :)

The goal here is not to give an accurate and playable port of Quake 3 online, but to show what Flash is now capable of. I don't have time to put the finishing touches on Q3FL (let me know if you have an idea why bots always look up), and the Flash Player Incubator still lacks some features like a real mouse capture system, which will hopefully be available in the final release. As for now, if you still want to play Quake 3 online, I advise you to try Quake Live, it's free.

Finally you can already find other demos using more in-depth capabilities of this new version of Flash Player, which is very promising.

About Flash and Molehill

Few people realize how Molehill is about to be a revolution in the browser-based gaming industry. Currently the majority of video games playable in a web browser are in 2D. I think there are two main reasons for that : Flash did not support 3D hardware acceleration until now, and alternative technologies have not enough ubiquity to be seriously considered by developers.

Among the alternative technologies to make real-time 3D rendering in a web browser you find Shockwave for which there is a wide choice of games, Virtools perhaps a little more oriented toward professional market, or Unity which is certainly the most successful technology currently. It is also possible to use hardware acceleration with more common technologies such as Silverlight or Java with JOGL. Finally others choose to develop their own technology, which is the case for Quake Live for example. However, all suffer the same problem : a low penetration rate.

People have confidence in Flash because the term “Flash game” came into common parlance, and because everyone thinks that YouTube cannot run without Flash (even if there is an HTML 5 version), but when it comes to installing the Silverlight plugin this is another story... In practice the penetration of Flash 10 is now above 97% throughout the world. This means that if you develop a site or a Flash game, you can be sure that at least 97% of people on the planet will see your site the same way they use Internet Explorer, Firefox, Chrome, or Opera and even on their Android phone !! Can you say the same thing if you develop a site in HTML 5 ?

The only alternative seriously conceivable in medium term if we take into account the ubiquity is certainly WebGL as more and more browsers implement it and that its presence is transparent to the user. However WebGL suffers the same flaws as all standardized technologies under the name HTML 5 : first we’ve been talking about it for years (the design of Canvas 3D began in 2006) but the specifications are still not completed, and secondly as for all other “standards” nothing says that a program based on WebGL work the same way between two browsers.

Actually I understand that we use HTML to make static websites or forms rather quickly. But when it comes to making a more complex website, a game, or web application, I do not understand how a developer can seriously be considering doing this in Java Script seeing all the problems it poses : clarity of language, existence of a standard API fully documented, cross-browser compatibility, performance across browsers... In comparison Action Script 3, Flash’s programming language, is overall similar to Java Script except it is cleaner because typed and more strict.

Furthermore the AVM2, virtual machine in Flash, has truly remarkable performances. The first port of Quake done using Alchemy sought to highlight those performances. Note that a program written in C/C++ and compiled for the AVM2 through Alchemy, or even coded in AS3 but well optimized, it can actually have as announced on Adobe’s website performance just 2 to 10 times lower than the same program compiled to native code. To convince yourself I invite you to test this first port of Quake. It is still far from the performance of the Java virtual machine, but I'd be very surprised if Google’s V8 or Opera’s Carakan were able to do so.

Besides for those who think that Flash drains the battery of cellphones, I invite you to play Doom. This is certainly the state of the art in term of Java Script based on HTML 5. Look how long your cellphone lasts on this game compared to a similar game in Flash, I think it's equivalent. Sure navigating a Flash site consumes more than remaining on a static HTML page, but there are no free lunches, having quality content is resource intensive. Seriously you think your PC consumes as much electricity when you play Minesweeper as when you play Crysis ? Think again...

Nevertheless 2011 will be a revolutionary year for browser-based video games, and this revolution will be due to Molehill. There is a huge market to take, so get to your keyboards !

Final note

Anything related to Quake 3 is the property of id Software. If I use something belonging to you on this page, please let me know.

Contact

Please fill out the form below and click the submit button. Don't forget to include your e-mail address. I'll try to answer you as soon as possible.

From:

Subject:

Message: