Hacker News new | past | comments | ask | show | jobs | submit login
HTML5/WebGL source port of Quake (github.com)
69 points by aw3c2 on Feb 16, 2013 | hide | past | web | favorite | 48 comments



So you can write on the checklist of things html5.5 or 6 or whatever needs:

* Local config storage (doable in cookies or localstorage)

* Local save storage (probably too big to fit in 5MB of localstorage)

* Mouselook (mouse buttons work fine). I think you can already do this though, I know you can at least track cursor position and you can implement mouselook off that.

* Mousewheel in firefox, at least, wasn't rebindable.

* I see problems in fullscreen browser games that take every single browser button and override it, so you would probably want a "you can't rebind this key" key. If there isn't already one.


MouseloOk != MouseloCk

Tracking view position from mouse coordinates has always been possible, but handling mouse focus and coordinate wrapping is necessary for games with mouse look. The really tricky bit is that there are security implications in much the same way as full screen mode.

See here for details on Pointer Lock: http://www.chromium.org/developers/design-documents/mouse-lo...


Configs, saves and demos are already stored in localStorage.


If we are able to play games which required a fairly decent PC 15 years ago in a web browser today, imagine where we will be in another 15 years time.


It's a start. Browsers were not getting any faster before because no one was pushing their boundaries, but nowadays it's a different story. I think we can expect browsers to get a helluva lot faster within the next 3-4 years, specially when it comes to canvas processing and rendering.


15 years ago you needed a fairly decent DOS PC. This works on every major OS out of the gate.


... if you have a fairly decent browser installed


> ... imagine where we will be in another 15 years time.

We'll be 15 years behind the PCs of 15 years from now[1].

[1] Unless something changes drastically in the web stack.


But, does that matter?

Do we need all the power a PC provides natively to make great games?


> Do we need all the power a PC provides natively to make great games?

I think the market has declared this to be a definitive "yes". Users don't want to waste their hardware dollars so that you can spend them on inefficient solutions.

When your competition takes advantage of the hardware, and you don't, then your application (or game) falls behind in the marketplace.

There's the argument that users are willing to have lesser performance ... for lesser cost. This is true, but quite different from your code performing more poorly than your competition's on the same hardware.


the function of computing power -> game quality is logarithmic, not linear. The 15 years behind of 15 years from now is a considerably smaller gap than the 15 years behind of now.


This one is crashing osx for me, but the GWT team did a similar JS port for quake 2 back in 2010, playable here: http://crystalin.dyndns.org:8080/GwtQuake.html .


Crashing your browser (which browser?) or actually crashing the entire OS. Both are worrying from a security perspective, but the latter is very worrying.


Oops, I meant to say crashing on osx, the browser is chrome 24


To update, it looks like both the gwt quake to and the OP's quake crash safari and chrome on osx, but work great in firefox. The quake 1 demo actually runs noticeably quicker than the gwt one for me. This is a great showcase for what's possible for js games.


That worked very well. With mouse support it would be great.

Also, quite scary how well you remember the maps, 15 years later.


I've always thought about how well we learn lore and geography inside games we love (for example, I know where everything is within several different lands of Hyrule), and yet it's very hard to get students to really learn actual Earth geography. Perhaps some aspects of this kind of teaching should move into a gaming environment in schools.


"and don't kill the server please?" if only ppl were that nice. Quaddicted will be quaked soon!


Quaddicted.com admin here. Should be fine since it is just static content. You might saturate the 100mbit/s but the server itself should be fine.


Challenged accepted!

Just kidding. :)


Nice! awesome work Sprint :)


Playable version here : http://www.quaddicted.com/stuff/WebQuake/Client/WebQuake.htm

Although the controls are really weird, right click goes forward, I can't aim with the mouse...


These are IIRC the original controls. You could enable mouselook by using the console, but it is not implemented in this port.


The port intentionally does not support mouse control because that is full of vendor-prefixes. See the bottom of the page.


I still don't understand his logic for this: Element fullscreen is not going to be added because there's already browser-wide F11 fullscreen.

If pointer-lock only works in element-fullscreen in Firefox (on which he develops) then what other choice is there ? Nobody plays shooters with the keyboard since wolf3d, and the BananaBread demo does pointer-lock precisely via element-fullscreen.


Chrome supports mouse lock without fullscreen since v21. However, I get illegal invocation error.


I added mouse support for Chrome.


It's "Aw, snap!"'ing my chrome 24 on osx 10.8 :(


Working great on a macbook-pro with Windows 8. :-P


Same for me.


Really impressive. What are peoples thoughts on games moving more and more to browsers?


I think it's an interesting question of time. Quake I came out june 1996; so, html5 is almost* capable of doing a 16 year old game. This... is interesting from a data point perspective.

There is an open question as to how html5 now compares to native some years ago since that's how (for gaming) it should be judged. I believe we will reach a limit point and in the long term, maybe the browser-related inefficiencies will just be marginal to the end user experience.

* mouse look is really what is missing.


The programmer behind this is 17 years old. Hand ported as well, not emscripten.


15 *

16 on March 15


great , did not work on my machine though , but great project.


Best. Thing. Ever.

Running smooth in Chrome Canary.


Wow, audio is a bit slow for me in Safari but great tech demo. I still love that game!


On Mac OS X on Chrome it does not work, on Firefox it works but blinks...


In Chrome on Mac and Linux, sound crashes the tab often. Play with ?-nosound or on Windows. The loading image is also not displayed in Chrome (unlike Firefox).


Anybody getting mouse support working?


I added it today only for Chrome.


very slow in rendering


works fine for me which browser are you using ?


am using firefox


There's your problem!


awesome work.

Running smoothly on Linux, tested on Firefox and Chrome.


Yup, runs good on Ubuntu, used Chrome. Pretty cool stuff.


amazing work




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: