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. :-)
Why Canvas is not an obvious choice for web games
11–20 of 25 posts
Re: Why Canvas is not an obvious choice for web games
#12I'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.
Re: Why Canvas is not an obvious choice for web games
#13I'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.
Re: Why Canvas is not an obvious choice for web games
#14Re: Why Canvas is not an obvious choice for web games
#15Earlier quoted context omitted.
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.
Re: Why Canvas is not an obvious choice for web games
#16I 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) abstractio…
>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.)
Re: Why Canvas is not an obvious choice for web games
#17I'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.
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.
Re: Why Canvas is not an obvious choice for web games
#18I'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.
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 shooter…
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.
Re: Why Canvas is not an obvious choice for web games
#19So is UO or a good, top down perspective rpg coming to canvas soon? Which have been announced?
Re: Why Canvas is not an obvious choice for web games
#20I 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) abstractio…
> 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: