Slashdot Mirror
Google Gets Quake II Running In HTML5
Dr Herbert West writes "A trio of Google engineers have ported id Software's gib-filled first-person shooter Quake II to browsers — you know, for kicks — as a way to show just what HTML5-compatible web browsers are capable of. According to the developers, 'We started with the existing Jake2 Java port of the Quake II engine, then used the Google Web Toolkit (along with WebGL, WebSockets, and a lot of refactoring) to cross-compile it into JavaScript.' More details are available on one developer's blog, and installation instructions have been posted as well."
wan't
I think that's the popular contraction of "wang" and "not." Am I correct? If so, your sentence doesn't make sense.
Whale
Because you can.
From the project FAQ:
We are as yet unable to provide a public demo link. The Quake II code is GPL licensed, but the demo resources (textures, models, sounds, et al) are not, so we cannot simply upload them to a server. We are pursuing legitimate avenues to do so, though -- stay tuned.
I saw this running a couple of months ago when I visited Google London. The guy who wrote it said it ran in Chrome with no plugins, so I'd imagine that you'd just go to the page and view it, although you'd need to grab the resources from a real Q2 install or demo. It's a nice tech demo, but on his modern multi-core machine it ran about as fast as Quake 2 ran on my old P166. It's one of those hacks that is cool because it's deeply wrong, not something that is in any way sensible.
I am TheRaven on Soylent News
The purpose of something like this is to push the boundaries of what can be done in web development as a means of determining where it falls short, and what needs to be done to allow efficient practical applications in the future.
The Java version of Jake2 runs at around the same speed as the native C version (sometimes a little slower, sometimes a little faster):
http://download.java.net/javadesktop/plugin2/jake2/
Mod me down, my New Earth Global Warmingist friends!
Also, it presently needs a dev version of chrome started with a command line parameter that disables some sandboxing features.
Um, dude? I know this certifies me as Gamer Grandpa, but you were unlikely to see a solid 30 fps in Quake II with the software renderer on less than a Pentium 166. Behold the miracles of the (many, many) layers of browser abstraction in action. Or perhaps inaction...
It may be hard to understand the significance of this if you are not immersed in the hell that is web front-end engineering. Javascript in isolation is not as bad a language as people make it out to be, but supporting common browsers and fixing all bugs as you're writing it is terrible. It is an incredibly hostile development environment.
The dream, from a developer's perspective, is this: In 3-5 years (this is the dream part given how fast the web changes), Javascript is an assembly language. You don't write it unless you really need to dig down to the "bare metal" of the browser itself. You compile to it from your language of choice. Your compiler spits out Javascript and any HTML/CSS containers required to skin your app and allow it to render in the browser. Your application can be linked to and run directly in the browser with no Flash, no Unity3d, no JavaFX, no plugins or installation required.
That no plugins are required is incredibly significant from the perspective of a company trying to distribute a product to as many people as they can, as cheaply as they can. Losing 20% of potential users because you required an installation of them is unacceptable--this increases your marketing costs by at least 25% and dampens the spread of your application via word of mouth, email, Facebook sharing, or whatever viral channels you happen to be using. This is why new 3D browser plugins are not succeeding. Unless it's Flash, no one has the plugin you need and you can't get them to install it reliably enough.
As someone who is frequently made miserable by having to support stupid browser oddities, I would kill to be able to write an application in Python, C#, or Java and know that I can compile to a package supported by >90% of people on the web. Yes, running complex stuff in Javascript is slow. But as seen in Chrome and Firefox, it's getting faster. Much like writing in assembly versus higher-level languages, writing Javascript directly will always be faster than compiling from another language. But at what cost to your time and sanity?
In 2010, my real options for rich content on the web are (1) Javascript/Browser Support Hell and (2) write a Flash application instead. That #1 is so miserable is one of many reasons for Flash's continuing success. The dream shown by this demo and others is that we will get a real Option 3.
I don't see how WebGL is a Flash replacement, given that Flash is a 2D platform. JavaScript + Canvas or SVG gives you the 2D stuff, without WebGL. WebGL is aimed squarely at things that Flash can't do.
I am TheRaven on Soylent News
WebGL and other libraries
WebGL isn't a library, it's a binding. It does bind to native OpenGL (if the browser supports that), and while it may not be strictly HTML5, it is in line with the HTML5 goals -- to make the browser itself the platform, without relying on plugins.
If this was an HTML5 demonstration, it would be using PNGs, SVG, and CSS to create the game
Fair enough, though that would be much slower.
Wow, almost as impressive as using activex rendering DirectX content that we first saw in the freaking 1990s.
Yes, because ActiveX is a nice, cross-platform standard with multiple open source implementations... Oh wait.
Read that again until it sinks in, by the way.
Cross-platform -- WebGL runs on Windows, Linux, and OS X, at the very least, and likely on the iPhone. Your attempt to pretend this is a Google-vs-the-world thing falls flat.
Standard -- WebGL is managed by Khronos, who maintains OpenGL itself -- the working group includes Apple, Google, Mozilla, and Opera.
Multiple open-source implementations -- Firefox and Chromium both support it in some dev build or other. That also means Gecko and Webkit, which means dozens of other browsers.
WebGL embedded in a browser or used as a plug-in is NOT the browser's rendering engine doing the work.
So what?
And for what it's worth, it is useful that it ends up on a Canvas. Unless I'm mistaken, that means it is composited with the rest of the document, meaning you could (for example) draw your HUD using standard HTML and only use the GL for the 3D. Please explain why this is a bad thing.
Don't thank God, thank a doctor!