Slashdot videos: Now with more Slashdot!

View

Discuss

Share

We've improved Slashdot's video section; now you can view our video interviews, product close-ups and site visits with all the usual Slashdot options to comment, share, etc. No more walled garden! It's a work in progress -- we hope you'll check it out (Learn more about the recent updates).

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.

Well, a better plan would actually be porting ioquake3, and including the latest speex and OpenAL 3d positioned VOIP. But I'm sure you could down sample the openarena stuff quite easily to a q2 format if you weren't willing to instead bolster the engine.

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 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.

That graph compares "original C code" to a Java version using jogl. Does the original C version of Quake use OpenGL or software rendering? If they are comparing software-rendered C to OpenGL accelerated Java, that's a silly comparison. Or am I mistaken about the original C version?

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.

The only HTML5 here is the final rendering is occuring in an HTML5 Canvas. This is NOT HTML5 and this is not truly running the game in a browser as you suggest as it is relying on WebGL and other libraries to produce a final render to the HTML5 Canvas.

If this was an HTML5 demonstration, it would be using PNGs, SVG, and CSS to create the game not just rendering to a square HTML5 canvas element.

On Windows Vista or Windows7, I could write code in a couple of minutes using

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.

The thing that is killing my old iBook G4 are the bloody Flash games that my wife wants to run on it. The thing is still perfectly capable of doing most stuff but Flash is such a resource hog and the OS X version of Flash so poorly optimised, especially since they released Flash 10 for Mac which made the PPC performance much worse. I'm tempted to get an iPad but the lack of Flash would upset her indoors but I think lack of Flash is a bonus. Anyway, if all these Flash game writers started porting over to

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.

Well the lack of tools is certainly a gap in the market that some party could cash in on right now with a pretty big payoff long-run.

This makes it look like GWT is becoming a candidate. Also based on some of the assertions made recently by Adobe in the vein of "we're in the creative tools business, not the technologies business" I think they may jump on board the HTML5 train soon as well.

The thing that is killing my old iBook G4 are the bloody Flash games that my wife wants to run on it. The thing is still perfectly capable of doing most stuff but Flash is such a resource hog and the OS X version of Flash so poorly optimised, especially since they released Flash 10 for Mac which made the PPC performance much worse. I'm tempted to get an iPad but the lack of Flash would upset her indoors but I think lack of Flash is a bonus. Anyway, if all these Flash game writers started porting over to HTM

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.

This is exactly how ZK Framework and GWT work, you just write you programs in Java and they generate Javascript for you while taking into account browsers incompatiblities and indeed I believe it's the future if Web development.

I agree that Javascript is quickly becoming an assembly language. GWT (the tooling Google used to get Quake running in Javascript) is exactly that. Java code is compiled to "native" Javascript.

Although, what you say about browser oddities is largely irrelevant with the usage of toolkits like jQuery, Prototype, Dojo, etc. Instead of targeting the Javascript DOM API, you target your toolkit's API. The DOM API is the part that differs between browsers, except for a few very rare cases. Targeting a toolkit

Indeed. I am all for the idea of separating further in the browser: design, code, and data, but moving that way should be moving away from JS as the de facto language of the web, not increasing reliance on a poorly applied language. JS is not well designed for its purpose as the programming language of the web, and certainly not implemented in a standard way. Don't get me wrong, I have grown to love JavaScript, it is very nice to code in if you are rigorous with what subset of it you use, and especially

I don't know why some knee-jerks tagged this article as "Java". It's not running on Java. It uses JavaScript. It doesn't use Flash either. It's pure browser code.

Also read this part of the developers' blog post:

What this means for the Web

For years, people have assumed the browser was a poor platform for this kind of thing, and that you'd need something like Flash, Silverlight, JavaFX, or native code. While it is true that you should not expect the browser to rival triple-A titles like Far Cry or Call of Du

Personally, I'd much rather have had a good, efficient, open-source plugin for interactive multimedia, based on open standards.

Yes, it's nice that we can emulate that with existing web standards, but, really, why has nobody actually built a good platform specifically tailored for the things we're now using JavaScript, HTML, and HTTP for? Java was close, but too bulky. Flash was great, but proprietary. AJAX is open, but horrible from a techn

And this, my friends, is why something like the iPad is going to take off... big time.

Google is really pushing this "browser as a platform" concept to the limit. Now imagine a "GooglePad" or a "ChomePad" or something which does nothing but browse the web. You click on a link and within seconds you're gaming at 60fps. Control-scheme aside, I think this concept will be succesful.

Has anyone invoked this meme yet? I don't see it. It's relevant in this case because we really are seeing stuff that used to be native code done in the browser. If there's not a C->Javascript translator already then soon there will be. Google's native client can run compiled code. It's starting to look like we can expect a Linux kernel running in a web browser in the next few years. Not obviously that useful but would be cool and you can bet that people will find things to use it for...

For now, you may have a point...but eventually, full games will be natively coded to be browser-based without any extra plugins.

I sincerely doubt it. Javascript is, as the name implies, a scripting language. It has the same problem as with other scripting languages: 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.

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

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.

Not really. A nice chunk of the.NET platform isn't implemented yet in Mono (unimplemented exceptions) and a sizeable part of that will never be implemented due to manpower and patent reasons. In addition, Microsoft's.NET platform is not open source and Mono is not the same thing (see last sentence).

I think Mono is a good thing but it's not even close to supporting the type of WORA support that Java enjoys today. Write Once, Debug Everywhere used to b

If ORACLE tries to tie Java to their database as you suggest it would kill Java. Java is one of their more valuable properties, it was probably THE reason to buy Sun. ORACLE is not stupid they won't do that.

To much of the Java ecosystem is on IBM iron and talking to DB2. ORACLE would much rather have thriving Java community then pick up a tiny number of database sales.

They have them for primitive types, actually, and had for ages - java.lang.Integer for int etc.

Since Java, unlike.NET, doesn't have user-defined value types, they didn't need to come up with an extensible scheme to derive a nullable type from any random value type. And for a fixed set of primitive types, it's easier to just hardcode the reference type wrappers.

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...

I had a friend who played quite a lot of Quake on a DX2 with (IIRC 8MB RAM, may have been 12 or 16 though, but I think it was 8). It ran at about 15fps - playable for him, at least. Caveat: he unloaded almost everything (custom "Quake only" cmd.com and the like) and ran the game in the "postage stamp" size "window". It was hilarious to watch: he would sit about 3" from the screen.

He could have gotten away with 8 MB of RAM cheerfully. The engine's minimum running environment was really around 6 MB, though at that point it dropped sound effects and the textures started getting really blurry... Upgrading to 24 MB RAM was easily one of the better things I did in 1997.

Quake was listed as officially unsupported on anything less than a Pentium, and they recommended that it be run on a Pentium 75. That was the only way to be sure that the infamous Pentium FDIV bug didn't rear its misshapen head. It's hard to believe Quake would be in high school by now if it were a person.

Duke3D definitely ran faster - on a system meeting Quake's minimum specifications you could get away with running in 640x480, or other lower resolutions if your graphics card supported VESA 2.0 and were

Ach, I hate responding to myself, but the FDIV bug wasn't isolated to Socket 4 (60/66 MHz) Pentiums like I'd thought. It apparently persisted all the way up to some Socket 5 120 MHz models, before being truly fixed. Back to the show.