Google Gets Quake II Running In HTML5 258
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."
OMGLOLWTF (Score:1, Insightful)
This is really cool and awesome, but why would I wan't to run this on my browser?
Re:OMGLOLWTF (Score:5, Insightful)
Because you can.
Innovation (Score:1, Insightful)
we were honestly a bit surprised when we saw it pushing over 30 frames per second on our laptops
Holy shit! Quake II hasn't seem frame rates like that since the 486! No matter how fast computers get programmers will always find a way to slow down their programs.
HTML5 (Score:1, Insightful)
Capable of further dragging us down as we fall into ever more inefficient programming paradigms.
Lovely.
Re:Demostration of what? (Score:3, Insightful)
Proof of Concept (Score:5, Insightful)
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.
How about OpenQuartz? (Score:4, Insightful)
No you can't. QuakeLive requires a "browser plugin" which defeats the whole point of playing in a browser. You don't get any of the advantages, like sandboxing, cross-platform, or no installation required.
This article is about running Quake in a browser, which is pretty dang cool, if not really practical. Also, it's not really about Quake or FPS so much as HTML5.
Urban Terror was a good suggestion. They probably could have gotten permission to distribute it if they asked. I would have suggested OpenQuartz, which is GPL. It's only half a level, but that's plenty for a demo.
Re:Die Flash games! (Score:3, Insightful)
Simply isn't going to happen until someone writes a development environment on par with Flash's, which doesn't seem to be happening any time soon. Chicken and egg problem. There's no interest in moving off Flash until the tools are there and nobody wants to write tools until there's interest in them.
Re:Proof of Concept (Score:5, Insightful)
So does this mean the folks whining about "flash is needed for cheap space invader games" can go away now?
Re:Javascript is becoming an assembly language (Score:1, Insightful)
If "ha ha your outlandish prediction will never come true" is what you are trying to say, I'm not sure how you got that from my post. I described the problem with rich web application development as I see it from my own experience, and the way I would love to see the web evolve in order to fix it. It's a dream, as I said. There are definitely a lot of other ways this could go.
One possibility is that Adobe adds a ton of new capabilities to Flash and either (1) Adobe's SDK is good enough by itself and everyone writes for Flex/Actionscript directly, or (2) the same thing I described above happens with developers compiling to Actionscript as the world's new assembly language. In either case, Adobe continues to rule the world. It could happen. I'd much rather not have them as a middle-man in the space I'm working in, but it would be better than today's status quo.
What other possibilities are left? Rich web content being a passing fad and everyone moving on to something else? The games industry would love for this one to be the case, but they don't believe it. For evidence, ask EA who they just bought or who they're buying next.
In the short term, obviously nothing changes. More than 80% of my users are on IE7 and IE8, and that's probably not going to budge until the next major release of Windows. So, again, this is a dream. But damn, it would be nice to have it come true sooner rather than later.
Re:OMGLOLWTF (Score:3, Insightful)
Javascript is, as the name implies, a scripting language.
At the time, that distinction was relevant. It isn't anymore.
it's easy to hack something together, but as the size of the project grows, that same feature makes it harder and harder to keep the whole thing from collapsing into a rats nest lined with spaghetti.
Here we go...
You can write COBOL in any language, and you can write good code in any language. If you don't have the discipline for Javascript, you could always write a preprocessor that forces it on you, but I think you'll find that knowledgeable programmers using it on real projects don't tend to have these problems.
The awful fact is that most programmers are mediocre and need handholding from the language to produce good or even okay code.
Another fact is that this same handholding slows down good programmers until you only have mediocrity everywhere. I don't think it even succeeds in making bad programmers mediocre, as TheDailyWTF will confirm.
A good programmer in a good language can easily outperform ten bad-to-mediocre programmers in a crippled language.
Languages like Javascript or Python allow - even encourage - sloppiness, since that facilitates writing quick and dirty scripts,
or Ruby, I would guess. Yet the Ruby community seems to enforce readable, well-architected code, along with readable unit tests (specs) for every change. Say what you will about the effectiveness of testing, it sure as hell isn't sloppy, or a "quick and dirty" solution.
Do I use languages like that when I need a quick hack? Sure! That's because they're good languages, so a quick hack is going to be easier to develop in Python or Ruby than it is in C. But you can write quick hacks in C, Java, or anything else, and you can also write solid code in Python, Ruby, and even Javascript.
It doesn't exactly help that scripting languages tend to catch most errors at runtime rather than compile time,
It doesn't hurt as much as you might imagine when you have full test coverage. In fact, given full test coverage, runtime errors are compile-time errors, meaning fewer runtime errors slipping by than you'd have with a program written in a stricter language but with fewer tests.
mostly because they like to pretend that variables are untyped
That's not pretending. In languages like Javascript, the variables are. It's the objects that are typed.
yet fail if you try to do something the object doesn't support.
Duh. What did you expect?
Here's a hint: Even in Java, there are many cases where something will fail at runtime when you try to do something the object doesn't support, faster than you can say NullPointerException. Or take the standard libraries -- fail-fast iterators, plenty of stuff not designed to work well with concurrent access from multiple threads...
You seem to be assuming that we all write crazy code where no one knows what type of object we're dealing with. In practice, it's not that far off from anonymous subclasses in Java, and it's significantly faster to write, read, and reason about when we don't have to write LongClassName<OtherLongClassName<OtherReallyLongClassName>> foo = new LongClassName<OtherLongClassName<OtherReallyLongClassName>>();
Ever tried to wrap your head around Java Generics, or C++ templates, or .NET... I'm guessing generics? It starts out innocently enough, but it eventually leads to serious issues, some even cropping up at runtime, plenty leaving you scratching your head trying to figure out how to describe exactly what kind of type makes sense here, what kind of inheritance relationship, etc...
That whole nightmare goes away when you can simply declare a variable with 'var' and let the system figure it out.