Why Canvas is not an obvious choice for web games | Hacker News Reader

Why Canvas is not an obvious choice for web games

paulbakaus.com

43 pointsbinomial23 comments

I'm with this guy. Canvas is great, but it's an element to include in your scene to render vector graphics, not a container for you to render your scene inside. Often you'll have dozens of them layered about the place, happily doing their thing and unaware of each other.

Use it right and it's a great tool. Try to use it as a panacea Flash replacement and you're in for a bunch of headache.

Apologies for going Meta, but the above downvote is the strangest one I've yet seen here.

I can't come up with a way to read my comment as inflamatory or "me too". The only thing I can guess is that it's a downvote for disagreement, but without any commentary I can't imagine why the downvoter would do so. It seems like the kind of thing one could easily refute with evidence, if one had evidence that it was incorrect.

It wasn't me this time, but I've unfortunately downvoted plenty of good comments when using an iPhone (or similar touch based device). The two arrows are simply too close together for people using capacitive touchscreens and/or with fine motor control issues. If it's only one downvote I'd always bear in mind the possibility that it's due to fat-fingers, not your comment.

I still don't understand why HN doesn't allow users the opportunity to change a vote on reflection.

I didn't downvote you, and I've spent enough time on reddit to stop questioning downvotes because they are too stochastic to spend braincell-seconds trying to interpret. But when I read your comment I immediately questioned why you would call canvas best suited for rendering vector graphics. If anything, VML/SVG via something like Raphael.js is best suited for that, because you can use graphics data exportable from a vector graphics editor like Illustrator, and manipulate the data in your page in a structured way--Raphael somewhat mitigates the painfulness of DOM operations.

I would say canvas is best suited for rendering/processing sprite or pixel-based graphics that does not need mouse interaction, if I had to pigeonhole it. Sure, I've used it via Flot to draw charts, and for purposes that were decidedly vector-ish, but I would never expect to be able to manipulate that stuff without complicated collision data and redraw logic. The API for drawing with the canvas pen is moderately featured but drawing imperatively and trying to act on <canvas>-mouse interaction just isn't scalable or maintainable.

I agree that it is a right tool for the job type of situation but I think there are many times when canvas is that tool for certain types of games. I understand the complexity of the Aves engine and what they are trying to do - but their performance needs are greater than most of the other games out there.

I think for simple tile-based games (pac man, mario bros, bejeweled) and casual 2d games (side scrolling shooters, puzzle games, angry birds) canvas is a really easy way to go.

Really? Why would you bother with Canvas at all if you were doing anything (non-rotating) sprite-based?

Canvas' main advantage is that it can render vector graphics. Beyond that it's useful for doing image rotation in a cross-platform way and for manipulating bitmaps. If your game doesn't require those things, I can't think of a reason you'd want to use it in favor of something the browser is so natively good at as laying out image-based scenes.

These days, I'm much more inclined to use 3d-accererated CSS Transforms and Transitions first, then fall back on CSS positioning, then finally Canvas/SVG as a last resort for the few things that can't be accomplished by CSS/HTML.

I think he is comparing apples to oranges here. Using HTMl as the "rendering device" works on a different (higher) level of abstraction. The additional layer of abstraction in HTML has already solved the complexity of doing efficient partial redraws based on changes to a subset of a scene graph. This isn't something that the canvas API was meant to handle. If one were to use a scene graph (or display list) abstraction on top of canvas, it would shield the application developer from this complexity just as well as the HTML does now. However, the HTML abstraction, although more general, is implemented in native code while a canvas based scene-graph would need to go through java-script, so it is at a disadvantage as to how far it can be optimized. Basically, what he needs is SVG. :-)

>Basically, what he needs is SVG. :-)

Yes. It's incredibly frustrating that we can't rely on embedding SVG in HTML. (Last I looked--about 2.5 years ago, admittedly--only Firefox could do it, and only with XHTML.)

Once IE 9 comes out, the majority of browsers will support inline SVG. Only Opera is currently an unknown:

http://caniuse.com/#cats=SVG,Summary&statuses=rec,pr,cr,...

Thanks!

You should check out http://raphaeljs.com/ , which basically unifies the SVG API in a cross-browser way. In IE, it translates everything to VML on the fly. You need to transcode your SVG to Raphael's JSON-based format, but it's not hard to do.

Thanks, I'll take a look next time I need it.

This depends on the type of the game, but a fellow developer is beta-testing a canvas based game http://esdao.com . It's works quite well, with the exception of Mobile Safari to my recollection which is supposed to perform better with the next iOS update.

no discredit to your developer friend, but the level of visual complexity that the OP refers to is far in advance the game you linked.

Here's a video of the Aves engine in action:

http://www.youtube.com/watch?v=Ol3qQ4CEUTo

As someone building an HTML/javascript-based animated game myself[1], I'm somewhat aware of the challenges involved and am frankly amazed that the OP has this level of performance coming from HTML/js on so many different game objects.

[1] http://littlecosm.com - a massively multiplayer twitter client!

For anyone wondering what happened to Dextrose (the company Bakaus founded to make the Aves HTML5 game engine), it was bought by Zynga back in May. He is now the CTO of Zynga Germany.

WebGL should fix this problem.

And don't worry about market penetration or adoption; one single hit game will drive the masses to the nightly builds and about:config.

Also, I wouldn't overlook Flash + PaperVision and its other 3D libraries. Alternative just showcased some glorious eye-candy at Adobe's Max 2010 convention:

http://blog.alternativaplatform.com/en/2010/10/26/adobe-demo...

Hard to believe that runs in a browser :-)

It doesn't. It runs in a plugin.

But a plugin with higher adoption than HTML5

True.

I have found that the performance you get with canvas as opposed to using a DOM based rendering varies greatly with the device and rendering engine that your code runs on (shouldnt be a suprise really).

For my game I have encapsulated redering to use webkitTransform and translate3d if hardware acceleration is present. Otherwise use canvas, or in the worst case (IE6-8), use DOM with left and top css attributes.

If your game, like mine, can use a form of dirty-rectangle, invalidation strategy to rendering, its possible to do 60fps rendering with low CPU usage on iOS and desktop browsers.

So is UO or a good, top down perspective rpg coming to canvas soon? Which have been announced?

Reply on news.ycombinator.com