Hacker News Reader

Comment by jiggy2011 | Hacker News Reader

jiggy2011

With HTML5 you also have to worry about the cross browser compatibility mess , which doesn't seem to work well as "rapid" development.

Not to mention that I think writing something like a scene graph in JS would make me rage.

View on HN

In my experience (5 HTML5 games), I haven't had many problems with cross browser compatibility. Chrome, FF, Safari and IE9 and work surprisingly consistently, at least with the methods I'm using... If I were to dig deeper into audio in my games, yeah I'd have to play with it a bit (though there are existing audio shims).

Either the browser supports canvas or not. It's not much more mess than that and definitely not as messy as making a normal website cross compatible.

Canvas mostly works across browsers but there are still variances and browser-specific edge cases you have to detect. Cross-browser audio is an absolute trainwreck, and APIs like gamepad, fullscreen, etc. are all very finicky as well and will require careful effort if you want to use them in each browser. Plus, each JavaScript runtime has things it likes/doesn't like so to get playable performance for a serious game in all the browsers you'll have to spend a while figuring out how to tune your JS for all of them (or writing browser-specific versions). This is made worse by the fact that some of the major browsers don't have usable profiling tools...

But sure, if all you want to do is draw some lines and bitmaps on the screen, no problem.

Agreed. HTML5 audio is definitely a complete mess, you need shims and fallbacks if you even want to consider using it... but for the present (e.g., on modern browsers+devices), canvas seems to be the winner in terms of write-once, run-anywhere for games and animations that look great and run smooth. And since it is an open standard, we can look for other devices (smart tv's, game consoles, car dashboards... okay perhaps that is dangerous) to support it in the not-so-distant future.

You think audio is a trainwreck? You haven't tried detecting key presses.

Canvas is not the only option. I'm currently developing a racing game where you can build your own race track in HTML5 with my colleagues for our final university project and we don't use canvas at all.

The whole game is built upon SVG, CSS3 (transform3d) and CoffeeScript and it works pretty fine, even on the iPad which is also the target platform. The limiting factor with this combination is the number of DOM elements. We are currently considering to render our racing tracks as a single image so we can remove the several SVG paths we currently use for this.

If you want to take a look you can find the source on GitHub[1] or play the game[2]. Currently only Chrome and iPad are supported. But that's only because we haven't added all vendor prefixes yet.

[1] https://github.com/stravid/slotcars [2] http://slotcars.herokuapp.com/

Also performance right now simply isn't up to par. I'm writing some apps right now that heavily utilize the canvas element, and I'm having to rewrite a large portion of it at the moment simply because I can't get more than 5 fps on one of the new ipads.

I think the biggest thing I learned to improve fps was drawing items to a canvas to use later in drawImage. Especially with svg, rather than draw the svg each time, on load I draw them all to 'subcanvases' and then pass that as the parameter for drawImage.

Really? I can get 25-30 fps on a canvas game on Safari for iPad 2 or 3.

This is exactly why the only place for applications is the desktop with native applications.

The gain in productivity wins hands down against the mess of having JavaScript+HTML+CSS working the same way across browsers and OS.

Reply on news.ycombinator.com