Doom Ported To the Web 248
kripkenstein writes "Ever since Id Software released the Doom source code under the GPL, it's been ported to platform after platform. Now, you can play Doom compiled to JavaScript on the web, using standard web technologies like Canvas and without any plugins. If your browser has trouble running it, here's a screencast."
The translation was accomplished using Emscripten, a Javascript backend for LLVM. As per the GPL, full source code is available. Pretty neat.
Not bad (Score:2)
8 fps, and that's on an older work laptop without a fancy graphics card and loaded with lots of crap in the background.
Re: (Score:2)
Mybe ripping Joe Jackson in the background slows things down.
Re:Not bad (Score:5, Informative)
Video card hardly makes any difference, browser does. 35 fps full-screen on Firefox 7.0a1, 34 on Firefox 4.0, slideshow on Firefox 3.5. This is on a cheap-ass 2.8Ghz Phenom II. It uses no OpenGL, about any graphics card can handle shoving such bitmaps around. It's single-threaded, too, so what you're ripping on your other cores doesn't matter.
However, without such basic controls as strafe, this demo is not playable. No mouse input hurts but DOS versions had unusable mouse anyway so it's just a throwback to the old times. I estimate I've clocked around 4000 hours those days so I'd cope :p Heck, even comma/dot might be acceptable if they don't want to allow redefining keys, although I'd really prefer a sane setup like Z/X=strafe, alt=fire, shift=run (assuming no autorun like in the original).
Re: (Score:2)
Re: (Score:2)
Wolf3D didn't have dedicated keys for strafe (only Alt-direction), Doom had both dedicated and alt, bound to comma and dot by default. Since it is vital to be able to turn all the time, you can't afford to use alt strafe in a fight. It's only for abusing the double-strafe bug.
Re:Not bad (Score:4, Informative)
However, without such basic controls as strafe, this demo is not playable.
Actually strafe works, hold down alt.
Re: (Score:2)
However, without such basic controls as strafe, this demo is not playable. No mouse input hurts but DOS versions had unusable mouse anyway so it's just a throwback to the old times. I estimate I've clocked around 4000 hours those days so I'd cope :p Heck, even comma/dot might be acceptable if they don't want to allow redefining keys, although I'd really prefer a sane setup like Z/X=strafe, alt=fire, shift=run (assuming no autorun like in the original).
Alt=fire? You must have some strange, deformed hands. Clearly Ctrl should be fire.
The rest is okay.
Re: (Score:2)
Graphics card doesn't make a difference because it presumably doesn't use WebGL. Browser makes a huge difference because Firefox 4+ has typed arrays, whereas Firefox 3.5 doesn't.
Re: (Score:2)
For me, everything works at ~35fps on latest Safari on OS X. Strafe, running, jumping, automap, door opening, etc. Only thing that doesn't work is sound. Make sure you focus the canvas (just click on it).
Re: (Score:2)
Re:Not bad... (Score:2)
Now on the other hand, the Flash port of Doom runs noticeably better and only uses about 25% CPU when running full screen at 1920x1200 on my Mac.
Re: (Score:3)
The HUGE fps difference is because of accelerated video via DirectX as you must be on Vista or Windows 7 correct?
Cthulhu forbid, no!
Your cheap-ass card can do wonders with Direct2D which is what Firefox 4 for Windows renders compared to 3.6.
Comparing with nouveau, the speed decrease is small, roughly consistent with that on programs which don't do hardware rendering at all. I even doubt Firefox actually uses any hardware acceleration there.
This is why it sucks on Linux.
The same hardware, a Windows 7 partition (sad to break its 4 months non-uptime): 24 fps on FF4, XP: 27 fps. So no, not quite "sucks".
Re: (Score:2)
Re:Not bad (Score:4, Funny)
1.4fps on my N900! IN YOUR FACE!
(Protip for N900 users: Use Firefox Mobile, if you try with MicroB it will just consume all your memory)
Re: (Score:2)
You didn't dump your stock like a hot venom-filled potato the moment Microsoft bought them? I can't feel any pity for you...
Re: (Score:2)
Oh sorry, not "bought," but "partnered"...but you can understand how I could make that mixup...
Re: (Score:2)
What's next on your list? Adding RIM to your portfolio?
Re: (Score:2)
Re: (Score:2)
I got 8 FPS on a rather well-dressed machine.
JavaScript is nobody's first choice for code.
Re: (Score:2)
Re: (Score:2)
8 fps? Your phone is awesome then, I'm getting only 2.8 fps on mine. Oh, wait, you meant a regular computer?
(2.8 fps in the start room of EP 1, in busy rooms it gets down to ~1.1 fps. And the sound, well, let's skip it.)
Re: (Score:2)
8 FPS? Are you using IE? I was getting 30-40 FPS on a crappy years-old work laptop using Opera. The CPU was chugging and made all of the fans turn on, and some textures were flickering, but it ran smoothly the entire time. The menu was only running at about 5-6 FPS though.
Re: (Score:2)
Your poor fps is almost certainly browser choice. Try a cutting edge release and see if you don't pick up a 5x improvement.
Re: (Score:2)
Probably this. I don't control the SW load on this box, so it's a rev or two behind on Firefox.
Re: (Score:2)
45fps on an almost 4 year old MacBook Pro with Core 2 Duo 2.4GHz.
I'm not quite sure that Doom used 170MB of memory, which JS alone is using in the tab.
Re: (Score:2)
Since Doom ran in 4 MB, why 170MB? I expect some overhead, but not 166MB overhead :p
Re: (Score:2)
Yeah, that's a bit of a jump from the 4MB it required in 1994 :)
Re: (Score:2)
Opera: 8fps
Firefox: 4fps
Chrome: unresponsive
Mind you, these results were just for viewing the static slides of the introduction. The game refused to play, giving a perpetual message loop saying "Demo is from a different game version!". Clicking on the "NEW GAME" menu item had no discernible effect.
Re: (Score:2)
You are doing it wrong, it's not GZDoom.
You just use the keyboard to pick stuff. Use the arrow keys to move, enter (control?) to accept, space to open doors, control to fire.
Re: (Score:2)
You are doing it wrong, it's not GZDoom.
You just use the keyboard to pick stuff. Use the arrow keys to move, enter (control?) to accept, space to open doors, control to fire.
Thanks for the tip on keyboard use (wow, I'm not exactly a youngster and still only tried the mouse). I got 33-35fps in Opera 11.11 while running around shooting things. Of course, the game resolution sucks a little bit and looked small on my display, but it was actually sort-of playable on ancient hardware.
Laptop: 8 year-old 1.6GHz Pentium M, with 1GB RAM and 1920x1200 Radeon 9600, running Lubuntu 10.04 LTS.
Cool (Score:2)
34FPS on average. The only problem is the sound quality is really bad. Like, really, really bad.
Re: (Score:2)
Same here. And the canvas occasionally loses the focus, causing the browser to fal back to its regular behavior (e.g.space=scroll).
But it's still an impressive demonstration.
Progress (Score:5, Insightful)
So instead of a 40MHz 486 and 8MiB of EDO RAM, we now require at least a 2,5GHz dual core with 1GiB of DDR3 SDRAM to accomplish the same thing on a web page.
Re: (Score:2)
Not as cool as GWT Quake (Score:3)
Re:Not as cool as GWT Quake (Score:5, Informative)
While this is impressive, it has been done before (and better): GWT Quake [youtube.com]
I think that Quake demo is awesome! I'd just like to mention though that this Doom demo is very different from a technical standpoint, and I think both are interesting:
Re: (Score:2)
Depends on how you define "cool" - this is very different from what GWT Quake did. GWT quake is port of Quake 2. This was created by recompiling the Doom source. Granted, Doom didn't originally use SDL, but I suspect it is much closer to the original source than what GWT Quake was. The ability to take unmodified C/C++ and compile it to Javascript is fundamentally amazing.
Take a look at their how-to [mozilla.org]
Sound is abysmal (Score:3)
Re:Sound is abysmal (Score:5, Interesting)
So... no music, and the sound effects are like a half second delayed from the action, AND they sound really REALLY bad.
I agree, the sound is terrible, sorry about that. I don't know much about how sound stuff works, that is the best I could do in a few hours of hacking something together with the Audio Data API.
Come on, you could do this with flash 2 years ago (Score:2, Interesting)
Here's the link: http://www.newgrounds.com/portal/view/470460, plus: it does run with a higher framerate.
Re: (Score:3)
Re: (Score:2)
So will WebGL.
Ughhhhhh (Score:3)
I mean, it's a cool accomplishment in terms of implementation and all, but...
Ughhhhhhhhhh.
Re: (Score:3)
Step 2 (Score:2)
This proves the old adage (Score:3, Insightful)
"Just because you can, doesn't mean you should"
Re: (Score:2)
Re:This proves the old adage (Score:5, Informative)
Re: (Score:3)
I'll be honest with you. We're just throwing science at the wall here to see what sticks.
Re: (Score:2)
I'm pretty sure saying this about a Doom or Quake port means you instantly have to hand in your geek card.
I just turned 40, so I am officially in old man mode.
This is why Plug-ins are a great option. (Score:2)
Never the less, a cool show and they can say they've done it, but thankfully this isn't our only only option.
A re-write in JS would have been MUCH faster. (Score:2)
This is one of those, "Just because you can, doesn't mean you should" kind of things.
Seriously, many Doom sourceports are doing it wrong, including this one. The thing is, Doom used fixed point math to simulate floating point -- now our on-chip float calculations are way faster than the code required to emulate them (that Doom uses).
Additionally: JS does not have any numbers except 64 bit floats! Bitwise math works on the lower 32 bits of the 52 bits of precision that the floats have available, and r
Re: (Score:2)
ARM machines are not so great at floating point, so that might not be true outside of desktops.
Re: (Score:2)
My only question is (Score:2)
isn't this part of the standard stress test suite? (Score:2)
Strangely, nobody bothers to port MS Bob anywhere...
Dungeon Crawl Nettiles (Score:2)
I am a raging fan of Doom (which I keep playing via source ports to this date), and this is a great experiment, however...the sound is abysmal, and I am too used to modern controls to go back to arrow keys :P
The FPS was OK for me, 20-30, but the sounds....sounded like...flatulence and a 2yo kid with very deep voice being recorded right next to the microphone.
Doom is not terribly complex by modern standards, but the browser struggles to get it moving (probably because of video rendering, not sure if webGL ca
version of java matter? (Score:2)
System 1 - RHEL5 8 cpu 48g RAM - Java(TM) Plug-in 1.6.0_20 - 7-8fps
System 2 - WinXP 1 C2D cpu, 4g RAM - Java(TM) Platform SE 6 U22 - 35-45fps
System 2 wins. Graphics card unimportant as this isn't a 3D accellerated application. Not sure why the discrepancy is what it is, but whatever.
Sound does suck.
Re: (Score:2)
This doesn't use Java, it uses Javascript and parts of HTML 5 (canvas, audio, etc).
Re: (Score:2)
Re: (Score:2)
It's javascript not java, so your browser version matters, something with a JIT compiler from the last 6 months will probably be able to display it at 30+fps (except Chrome, it doesn't render at all in either current or beta).
Ahh, gotcha. Yea my RHEL5 system is running Firefox 3, my WinXP box is running Firefox 4.
Re: (Score:3)
Amazing... Over a decade and a half and even tech-heads still get this wrong.
I did a "RESTful webservices in java" course the other day and the instructor felt it necessary to point out that JavaScript was not Java despite the fact that you had to have years of Java experience to even register for the course.
Re: (Score:2, Insightful)
It seems pretty damn impressive that web browsers are as powerful as an entire computer with the specs required to play Doom back in the day. And it's reporting about 35 FPS, too (FF 4.0.1 with a 1.8 GHz dual-core processor and 1 GB of RAM, for what that's worth).
Considering that DOOM ran at, what, 60 FPS on a 486 SX 33Mhz with the DOOM graphics quality set to high and at the largest screen size it supported, it's not really that impressive.
Re: (Score:2)
Hmm... the 386-40 with coprocessor wasn't much slower (~20%) than the 486SX-33 and it only got about 15-20 FPS.
Re: (Score:2)
A DX2-66 might have gotten 60FPS on a PCI or VLB videocard. I highly doubt a SX (no co-processor) could do it, since that kind of machine probably had an ISA videocard.
Re: (Score:2)
A DX2-66 might have gotten 60FPS on a PCI or VLB videocard. I highly doubt a SX (no co-processor) could do it, since that kind of machine probably had an ISA videocard.
You're probably right.
This was 18 years ago, you can't expect me to remember everything about it. :P
Re: (Score:2)
Re:Is it just me... (Score:5, Informative)
No. My 486SX-25 would run Doom at 20-some FPS (mainly dependent on how many monsters were within visual/acting range), and after an upgrade to a DX2-50 Overdrive it would usually be 30-something -- and the original DOS executable had a hard limit of 35 FPS.
Don't forget this is running as interpreted code in what amounts to a virtual machine.
Re: (Score:2)
The code is not interpreted, not on any sane recent browser at least.. After a few seconds it's all JIT-compiled.
Re: (Score:2)
OK, bytecode, but still quite a bit slower than native.
Re: (Score:2)
Yeah but it's 18 years later and we're using processors that are literally thousands of times faster than the original ones. In light of that, I think it's a rather pathetic achievement.
Re:Is it just me... (Score:5, Informative)
No, it's not bytecode. Most (all) modern JS engines actually JIT-compile to native code.
It's still slower than C version simply because native code doesn't mean fast - if it has to do dynamic dispatch over method names, for example (because the compiler couldn't infer types deep enough), it's still slower than a direct or virtual call.
Re: (Score:3)
Couldn't agree more. Javascript is like early RISC chips. People joked that RISC meant 'relegate impossible stuff to the compiler'. We've since figured out how to handle RISC instruction sets well, but Javascript compilers are at the same early stage it seems. Javascript is an "impossible" language to compile into fast code. It requires significant advances in JIT type inference, whole program profile-guided optimization, etc. The theory for all that has been mostly worked out long ago, it's just a matter o
No, It's Not Just You, It's Just Developers (Score:2)
It seems pretty damn impressive that web browsers are as powerful as an entire computer ...
I think it has more to do with the power/stability/impressiveness of the JavaScript engines and implementations of standardized ECMAScript specifications. I had submitted a story about Fabrice Bellard [slashdot.org] emulating a very basic (even primitive) computer and then running Linux in it [bellard.org]. But that got rejected.
Developers are slowly coming full circle and using JavaScript a client side application. As the performance cost of emulation and virtualization are outweighed by better machines and as HTML5 become mor
Re: (Score:2)
Re: (Score:3, Informative)
Javascript is fine. It's the 'running inside a browser' that kills performance by 99%, and makes this an impressive feat. If the Javascript engine was ripped out of Firefox 4 or Chrome, and given a decent graphics & sound API, it would have respectable performance (nowhere near C or C++, of course). When you're writing a graphics heavy app in a browser, though, it's like playing a song on a dot matrix printer. The fact it exists at all is the amazing thing.
Re: (Score:2)
What I actually like better is this Java C64 emulator [jac64.com] - {G}
Uridium [jac64.com]!
Pug
Re: (Score:2)
Re: (Score:3)
I think it's actually depressing that web browser implementations are so poor that they can eat up the entirety of the significantly more than 50X improvement in processing power that has happened in the intervening time.
Re: (Score:2)
I really doubt that Javascript itself is the bottleneck on this one. Much more likely to be the browser's ability to draw quickly.
Re: (Score:3)
Re:Wow (Score:5, Informative)
If you want real graphics performance out of a browser, you should be using WebGL (assuming Flash is not an option). WebGL lets you execute OpenGL code on the video card of the machine, which will be a ton faster than Canvas.
You have to remember that Canvas is just an image rendering platform. From my understand of Canvas in Firefox, it actually renders every frame as a PNG and displays it to the screen. There is no GPU acceleration. That's what WebGL is fore.
Re: (Score:3)
Re: (Score:2)
It's one thing to generate a png for every frame you render and writing straight to (one of) the buffer(s) of the video card as they previously did.
The only thing it points out (as far as JavaScript is concerned) is that they need a better way to render the canvas.
Comment removed (Score:4, Informative)
Re: (Score:2)
Your understanding is incorrect. Firefox's canvas implementation has nothing to do with PNGs. And on Windows Vista/7, and also Linux/X on some systems, the 2D canvas API makes heavy use of the GPU.
Re: (Score:2)
Why not provide a strongly typed extension to javascript? Javascript would get a lost faster.
I'm all for Javascript getting lost faster.
What's needed is a strong sandbox for each browser instantiation to run binaries in, whether those be native or pre-compiled bytecode for a state machine. Not fettering developers to using a specific language that is interpreted or compiled from source.
Java applets were a good idea, but was hampered by the sandbox being a pixel-boxed applet, not the browser, and also by being proprietary and single-language.
Re: (Score:2)
Not binaries, then we are again stuck with x86. I own many devices that are not x86 and even some workstations.
Re: (Score:2)
That's why he said "precompiled bytecode".
Re: (Score:2)
LLVM bytecode, maybe? It's independent from both the source language and final platform.
Re: (Score:2)
One nifty thing that Google is doing is "portable NaCl" [google.com] - basically, they're using LLVM intermediate form for distribution, which is then compiled to native code by the browser, and validated/sandboxed by existing NaCl facilities. That's way better than JS - you get a really low-level instruction format that lets you implement practically any language efficiently, without losing portability.
Re: (Score:2)
Re: (Score:2)
People won't realize that until it stops doing stuff like this.
Re: (Score:2)
JS VMs are far from state of the art compared to, say, Java VMs. They're working on it, though...
Re:Wow (Score:4, Informative)
This demo is rendering to an HTML5 *canvas* as a virtualized framebuffer in an interpreted language with no hardware support whatsoever. Are you *seriously* trying to use this as a complaint against Javascript? I remember back when "demo" just meant "write a cool app to show off"...
Of course it's not the way someone would build a real app in Javascript, but it's an excellent demo to help people understand what the platform can do and how it might be improved. And for those of us who understand all of the tools that went into it, it's just pretty damn cool.
A couple weeks ago a story was posted about a demo that booted a real 2.6 Linux kernel image with ramdisk entirely in Javascript: JSLinux [bellard.org].
That takes a whole 6 seconds to boot to a bash prompt *in Javascript* on my machine. SO SLOOOW, Javascript sucks!!! ;)
Re: (Score:2)
Yea, most of the rest of us have upgraded our computers since the time Doom originally came out.
Don't be too hard on the poor fellow, he's probably having a hard time finding a shop which sells the correct vacuum tubes.
Re: (Score:2)
It's also available for PalmOS (ZdoomZ)
Re: (Score:2)
No Commodore 64.
Not enough memory for the code, obscenely crappy video hardware, and even if you could it would likely take up to a half minute to render a horrendously colour glitched frame.
Or NES.
The snes port required a 21mhz superfx chip inside the cartridge that did all of the 3d transforms etc and had it's own ram on cart, it basically dma'd rendered tiles to the video processor (snes could do 256 colour suiting original content just fine). Also the machine had 128k of ram no chance in hell on a nes
Or Sega Genesis? That last one is a surprise since the Amiga version should be able to run on the Genesis with some simple modification.
Amiga had far better vide
Re: (Score:3)
Firefox 4.x gets around 30fps, so I guess the answer is yes.
Re: (Score:2)
Get a better browser. 30fps on FF4 on a single-core 1.6GHz.