By Craig Buckler

JavaScript Doom

By Craig Buckler

Please forgive the blatant link-baiting title. JavaScript is fine. The world’s most-used programming language has a secure future — especially now id Software’s Doom has been converted to run in a browser!

If you’ve been overcome by euphoria, stop reading further and click the link:

The game is available from Mozilla’s Demo Studio; a resource which showcases HTML5, CSS3, and JavaScript technologies in Firefox and other browsers.

note: Where’s it gone?

The minute this post appeared, Mozilla pulled the Doom demo. I’m not sure why and it may only be temporary — I suspect it was overloading their servers. A video of JavaScript Doom can be viewed on YouTube while we’re waiting for it to return.

I’m conscious that SitePoint attracts readers who are far younger than me. If you’ve never heard of Doom, it’s a first-person shooting game which was released for the PC in 1993. While it wasn’t the first FPS — id Software’s Wolfenstein 3D can claim that crown — Doom revolutionized the genre. It’s pioneering 3D graphics, multi-player gaming, and graphic chainsaw-wielding violence was the inspiration for many of today’s blockbuster titles.

By modern standards, Doom is showing its age. It has antiquated blocky VGA graphics, 2D maps (walkways cannot pass over another) and limited control (no jumping or vertical aiming). But the game play remains astounding and Doom has been converted for a range of consoles and handheld devices. Now it’s been ported to JavaScript and can be played in a browser without plug-ins.

Unfortunately, JavaScript Doom is agonizingly slow in Chrome and won’t run in IE. Some versions of Safari are reported to work, but that wasn’t my experience in version 5.0.5. However, it works well on Firefox 4 and Opera; a mid-range PC should achieve 20-30 frames per second — probably better than the old 486 I used to play Doom back in 1993! There are a few graphical glitches but it’s playable.

Amazingly, the game was compiled from C to JavaScript using Emscripten and Clang then optimized with Google’s Closure Compiler. Video output is rendered on a standard HTML5 canvas element. Sound is handled using Mozilla’s non-standard Audio Data API but the effects are so nasty you won’t want them! If you’re interested, the source can be downloaded although the JavaScript is minified and unreadable.

If You Think That’s Impressive…

Fabrice Bellard has developed an x86 PC emulator in JavaScript. For fun.

It runs in all the latest browsers so he installed the 2.6.20 Linux kernel and released browser-based emulator. Yes, it’s running Linux in a web page.

The demo is limited to terminal output rendered in an HTML table but the implications are astonishing. My only concern is that someone will add X11, install a browser and recursively implode the web!

Have you seen any other great examples of cutting-edge JavaScript?

  • mahen23
    • adorn


      • DaVince

        Well, it is now. :(

  • Whaaa! Mozilla has just removed the link? I hope it’s temporary – a lot of people are linking to it. I’ll try and find a mirror…

  • Immysl

    Yes the link’s broken.

  • fidel karsto

    > […] The demo is limited to terminal output rendered in an HTML table but the implications are astonishing. My only concern is that someone will add X11, install a browser and recursively implode the web!
    You could also think of that: In the future a website could deliver it’s own rendering engine, like Apple does with Webkit on OS X already. No more cross browser problems – all you have to do is implement a javascript library that takes care of the rendering stuff and transposes it to the browser you are using. Sounds pretty neat to me – a centralized rendering engine – though it’s definitely still a long way to go. ;-)

    • Many web pages are already a larger file size than the browser which renders them, so why not!

  • Metasansana

    I’m sorry but this post has just been way too mouth watering. I’ve seen people create mock terminals in the browser already but if that project is developed further to the point where its an actual virtual pc that runs on the client side well wow…..

  • IT Mitică

    I see.

    You’re expecting a JS VM.

    I don’t think JS, in its current state, is able to attract me, as a developer, enough to make it a tool of choice for me.

    Right now it’s a tool of no choice rather, because I can’t successfully program the client side in another language.

    Unless the language and frameworks and libraries like jQuery evolve enough, it will be replaced at one point by something else.

    I personally believe the future to be in integration.

    A standard video and audio is on the way, with HTML5. SVG is pretty much on hand.

    I wish for something along the lines of a standard Flash/Silverlight/Air. W/o the need for a plug-in. Google may be on something on this one.

    • Karl

      Check out the Sencha and Ext frameworks for an idea of what can really be achieved with JS…

      • IT Mitică

        Thanks for the info.

        The Ext framework I knew of, the Sencha one is new to me. It appears to be Ext related?

        Anyway, there are problem I, as a programmer, see with in JS code. No matter how fast the JS engines are, the language is still showing its caveats.

        There are even implementations for JS as a server-side, old and new, like Jaxer.

        There were enthusiast predicting “Server-side JavaScript Will Be as Common as PHP”, still, since there are many choices on server-side, it never really took off.

        I suspect this will be the case too when we’ll have multiple choices for client-side also.

    • DaVince

      So SVG, HTML5 audio and video with a HTML5-extended JS API?

      • IT Mitică

        I was hinting towards a different client-side technology, other than JS. Or at least towards a scenario where I can choose between two or more client-side languages.

        Also, what can be done on client-side with JS in terms of games, for example, I believe Flash/Silverlight/Air are better suited for. Though nowadays there are JS options for those too.

        My biggest wishes are:
        – a better JS language: something like Ruby.
        – more scripting languages, beside JS, on client-side, and I don’t mean Java applets.

  • Daquan Wright

    Amazing…..the web browser is just progressing like crazy.

    I imagine something like this would put a huge strain on a server though, and probably cause memory consumption to flow out the walls of the browser. Absorbing memory and restrains on the server-side are big walls to heavy apps like games in my opinion (at least anything other than simple games).

    • DaVince

      Aren’t you confusing client-side with server-side? For the server, the strain is no bigger than downloading the files the game needs, after which everything is run on the client side. It’s like a Flash game in that respect.

Get the latest in Front-end, once a week, for free.