The state of WebGL and HTML 5 audio for creating JavaScript games
Posted on:July 22 2010
I created a small 3d WebGL game. It is pure HTML 5 (HTML with JavaScript) and runs in all WebGL enabled browsers, such as Chrome and Firefox: Start the game.
If you don't have a WebGL enabled browser, you can watch a video of the game here:
The game code is open if you want to learn how I did it. I even did the graphics, sounds and the music myself (so warning: Programmer Art and Music!). I basically created it from scratch using the 3d engine CopperLicht, the 3d editor CopperCube and even my HTML editor WebsitePainter, to test out if it was possible to create HTML 5 only 3d games already. The result is the following:
WebGL: good
WebGL, altough still not finished yet and only supported in most browsers if you enable it manually, works. It's quite stable and very fast. It's - like OpenGL - a bit too complicated to use it without a library since I doubt every web developer wants to learn writing shaders and 3d model importers, but if you use a free library such as copperLicht, everything is fine.
JavaScript: excellent
I was quite amazed by the speed of the JavaScript engines in todays modern browsers. Having implemented and worked with a number of dynamic languages already, I think it's even quite ok to wonder how they actually did this. :) So no problem here, game logic is totally ok to be written in JavaScript today. You only need some discipline, since JavaScript still doesn't support static typing, quite a problem once your project gets big.
HTML 5 audio: bad
The problem is HTML 5 audio: Praised by a lot of people on the interwebs, HTML 5 audio in its current state is not what you want for creating games. Currently, and only if looked at Opera, Firefox and Chrome, it is simply broken. It behaves differently accross all browsers and different types of encodings and file formats are supported accross browsers. Additionally, using it in a game via JavaScript, there is no way to have full control over you audio: Seeking is not possible, restarting an audio stream isn't possible, and the browsers will reload audio files from the HTTP server each time you play a sound if you try to work around this problem, ignoring the cache completely. Additionally, looping is completely broken in some browsers and goes from 'works sometimes', 'simply doesn't work' and even 'crashes the browser'.
So there is still work to do for the browser developers (and probably maybe also for the W3C regarding the JavaScript interface of HTML 5 audio compopnent), but there are workarounds (like flash), and you can already create nice working games.
If you don't have a WebGL enabled browser, you can watch a video of the game here:
The game code is open if you want to learn how I did it. I even did the graphics, sounds and the music myself (so warning: Programmer Art and Music!). I basically created it from scratch using the 3d engine CopperLicht, the 3d editor CopperCube and even my HTML editor WebsitePainter, to test out if it was possible to create HTML 5 only 3d games already. The result is the following:
WebGL: good
WebGL, altough still not finished yet and only supported in most browsers if you enable it manually, works. It's quite stable and very fast. It's - like OpenGL - a bit too complicated to use it without a library since I doubt every web developer wants to learn writing shaders and 3d model importers, but if you use a free library such as copperLicht, everything is fine.
JavaScript: excellent
I was quite amazed by the speed of the JavaScript engines in todays modern browsers. Having implemented and worked with a number of dynamic languages already, I think it's even quite ok to wonder how they actually did this. :) So no problem here, game logic is totally ok to be written in JavaScript today. You only need some discipline, since JavaScript still doesn't support static typing, quite a problem once your project gets big.
HTML 5 audio: bad
The problem is HTML 5 audio: Praised by a lot of people on the interwebs, HTML 5 audio in its current state is not what you want for creating games. Currently, and only if looked at Opera, Firefox and Chrome, it is simply broken. It behaves differently accross all browsers and different types of encodings and file formats are supported accross browsers. Additionally, using it in a game via JavaScript, there is no way to have full control over you audio: Seeking is not possible, restarting an audio stream isn't possible, and the browsers will reload audio files from the HTTP server each time you play a sound if you try to work around this problem, ignoring the cache completely. Additionally, looping is completely broken in some browsers and goes from 'works sometimes', 'simply doesn't work' and even 'crashes the browser'.
So there is still work to do for the browser developers (and probably maybe also for the W3C regarding the JavaScript interface of HTML 5 audio compopnent), but there are workarounds (like flash), and you can already create nice working games.
Comments:
Dennis
Quote2010-07-22 08:23:00
I enjoyed reading your blog ~ thanks for posting such cool content.
assausMog
Quote2010-07-22 09:30:00
Very nice work, I'm sorry that I don't have the latest version of Chromium to test it... xD. I will try later. Linux users require to install a WebGL implementation:
http://www.khronos.org/webgl/wiki/Getting_a_WebGL_Implementation
http://www.khronos.org/webgl/wiki/Getting_a_WebGL_Implementation
Daniel Molina We
Quote2010-07-22 15:01:00
would this: https://wiki.mozilla.org/Audio_Data_API help with the audio stuff?
(Basically you can create a typed array of samples then write them out, essentially replicating how you'd do audio in a C game engine)
(Basically you can create a typed array of samples then write them out, essentially replicating how you'd do audio in a C game engine)
Thomas Jones
Quote2010-07-22 16:51:00
If you find a bug in HTML5 audio in Firefox, file a bug at http://bugzilla.mozilla.org in the "Core" product, "Video/Audio" component. If the developers don't know about bugs, or don't know how often they're getting hit, they may not know to fix them!
Browsers are moving towards implementing support for WebM video, which includes Vorbis audio, so that should alleviate your format issues somewhat.
Browsers are moving towards implementing support for WebM video, which includes Vorbis audio, so that should alleviate your format issues somewhat.
Chris Pearce
Quote2010-07-22 22:45:00
Damn ... I wish I had more time so I could take a look into developing 3d web stuff, but (at the moment) I just can't :(
Brainsaw
Quote2010-07-23 07:15:00
Audio is coming.
http://www.w3.org/2005/Incubator/audio/
https://wiki.mozilla.org/Audio_Data_API
http://chromium.googlecode.com/svn/trunk/samples/audio/specification/specification.html#AudioContext-section
http://www.w3.org/2005/Incubator/audio/
https://wiki.mozilla.org/Audio_Data_API
http://chromium.googlecode.com/svn/trunk/samples/audio/specification/specification.html#AudioContext-section
F1LT3R
Quote2010-07-23 21:12:00
it was very interesting to read.
I want to quote your post in my blog. It can?
And you et an account on Twitter?
I want to quote your post in my blog. It can?
And you et an account on Twitter?
KremlinNews
Quote2010-07-24 13:02:00
sure
niko
Quote2010-07-24 14:30:00
> since JavaScript still doesn't support static typing,
> quite a problem once your project gets big.
Hey. I think this is quite a controversial statement. Lots of people believe it's true, but lots of people also believe it's false, so there's quite some debate about it.
As you know, although static typing does help to quickly spot and identify some kinds of errors, these types of errors are generally fairly trivial to identify even in a dynamic language. Meanwhile, dynamic languages tend to result in significantly less code, and allow designs that are more closely related to the problem domain, instead of around the abilities of the language, resulting in cleaner and more appropriate designs.
So that's why I say it's controversial - there are strong arguments on both sides. Because, historically, dynamic languages have been under-represented outside of academia, we have very few data points as yet.
In my personal experience, as the dynamic languages I work on get bigger and bigger, I have yet seen no tendency for this to undermine the stability or ease-of-understanding of the code. On the contrary, the projects I have worked on seem to be some of the best software projects I have seen. Whether this is cause or effect is hard to say, of course, but that is my personal experience, for what little that is worth.
Best regards,
Jonathan
> quite a problem once your project gets big.
Hey. I think this is quite a controversial statement. Lots of people believe it's true, but lots of people also believe it's false, so there's quite some debate about it.
As you know, although static typing does help to quickly spot and identify some kinds of errors, these types of errors are generally fairly trivial to identify even in a dynamic language. Meanwhile, dynamic languages tend to result in significantly less code, and allow designs that are more closely related to the problem domain, instead of around the abilities of the language, resulting in cleaner and more appropriate designs.
So that's why I say it's controversial - there are strong arguments on both sides. Because, historically, dynamic languages have been under-represented outside of academia, we have very few data points as yet.
In my personal experience, as the dynamic languages I work on get bigger and bigger, I have yet seen no tendency for this to undermine the stability or ease-of-understanding of the code. On the contrary, the projects I have worked on seem to be some of the best software projects I have seen. Whether this is cause or effect is hard to say, of course, but that is my personal experience, for what little that is worth.
Best regards,
Jonathan
Jonathan Hartley
Quote2010-07-30 10:27:00
Add comment:
|
|
Possible Codes
| Feature | Code |
| Link | [url] www.example.com [/url] |
| Bold | [b]bold text[/b] |
| Quote | [quote]quoted text[/quote] |
| Code | [code]source code[/code] |
Emoticons
 |  |  |  |  |  |  |  |
 |  |  |  |  |
You're right about the speed of JavaScript. It's surprisingly good.
I hope they'll put as much effort in HTML5 audio as they've put in WebGL. Would've been great if there was something like WebAL!