Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

In defense of

holovaty.com

Post reply on HN
Print view View original

31–40 of 64 posts

Re: In defense of <canvas>

#31

Post by warfangle »

babuskov wrote: post #7

Should you be using canvas directly? I'm currently writing my 3rd HTML based game, and I'm so tired of using jQuery and DOM directly, so I want to replace it with canvas. Game is a turn-based strategy, so performance is not an issue (there will be some animations, but rare). I looked at the canvas and then at a lot of 2D libraries that can speed the development and prevent me from reinventing the wheel. I'm overwhelm…

For my side/tinker/forever project, I've been using Three.js even though it's actually 2D (for now). Since you can set it to render orthographically, it might be useful (each sprite as a two-tri polygon).

Completely new to game development though, so this may be really really bad advice.

Re: In defense of <canvas>

#32

Post by babuskov »

city41 wrote: post #20
babuskov wrote: post #7

Should you be using canvas directly? I'm currently writing my 3rd HTML based game, and I'm so tired of using jQuery and DOM directly, so I want to replace it with canvas. Game is a turn-based strategy, so performance is not an issue (there will be some animations, but rare). I looked at the canvas and then at a lot of 2D libraries that can speed the development and prevent me from reinventing the wheel. I'm overwhelm…

I recommend checking out my Breakouts project, which is aimed at answering your question: http://city41.github.io/breakouts . It's the same idea as TodoMVC but for js game engines.

Thanks, I've already seen it. In fact, it was one of the factors that made me narrow the choice. Thank you for making it.

Do you have any plans to include CanvasEngine and/or Cocos2D in there as well?

Re: In defense of <canvas>

#33

Post by joehewitt »

My guess is that most people who hit a performance wall with canvas are using overly complex vector graphics and not caching bitmaps as often as they could. While things like OpenVG are on the horizon, vector drawing is still a CPU-bound activity most of the time, while bitmap blitting is all GPU. This is the case whether you're using canvas or a native graphics library.

Re: In defense of <canvas>

#34

Post by babuskov »

euroclydon wrote: post #17
babuskov wrote: post #7

Should you be using canvas directly? I'm currently writing my 3rd HTML based game, and I'm so tired of using jQuery and DOM directly, so I want to replace it with canvas. Game is a turn-based strategy, so performance is not an issue (there will be some animations, but rare). I looked at the canvas and then at a lot of 2D libraries that can speed the development and prevent me from reinventing the wheel. I'm overwhelm…

If you want a scene graph, have you evaluated fabric.js? It's a popular canvas library, providing mouse events, and import/export to SVG.

Looks interesting. Thanks.

Re: In defense of <canvas>

#36

Post by Jack000 »

the soundslice example might be a bit flawed. It's fast for a canvas app but not even close to "native magic" on my pc using chrome.

I feel like some sort of html luddite, but am I the only one who preferred flash/actionscript3 to canvas/javascript? I get that the web should be open, but beyond the idealism the flash drawing tools were much better. I feel that the criticisms currently levied against flash will come up again with html/js/canvas/svg as apps get more complex.

Re: In defense of <canvas>

#37

Post by adrianh »

Jack000 wrote: post #36

the soundslice example might be a bit flawed. It's fast for a canvas app but not even close to "native magic" on my pc using chrome. I feel like some sort of html luddite, but am I the only one who preferred flash/actionscript3 to canvas/javascript? I get that the web should be open, but beyond the idealism the flash drawing tools were much better. I feel that the criticisms currently levied against flash will come u…

Hey, thanks for the feedback! What were you doing with Soundslice when it felt slow -- were you zoomed out (such that there were a ton of annotations visible on the page)? Or was it just slow in general, even when it was zoomed in?

Re: In defense of <canvas>

#38

Post by city41 »

babuskov wrote: post #32
city41 wrote: post #20

Earlier quoted context omitted.

I recommend checking out my Breakouts project, which is aimed at answering your question: http://city41.github.io/breakouts . It's the same idea as TodoMVC but for js game engines.

Thanks, I've already seen it. In fact, it was one of the factors that made me narrow the choice. Thank you for making it. Do you have any plans to include CanvasEngine and/or Cocos2D in there as well?

Yeah, I'd like to add pretty much all engines. Currently I'm not dedicated any cycles to the project as we're in crunch mode getting our game done. But after that I plan to head back to it. First engines on my list are the various cocos2d variants.

Re: In defense of <canvas>

#39

Post by VMG »

simonsarris wrote: post #13

I've done a large amount of canvas work over the past years, especially work with improving canvas performance (one of the articles on my site is linked-to by this article). What follows is fairly self-promotional, but relevant to the topic if you're interested in canvas performance. I've been compiling canvas performance tips for two years now, and have a full-color (syntax highlighting and images) book coming out v…

Ha! Caught you not mentioning your blog posts while I was adding this comment to my "canvas performance" bookmark list and saw a familiar name.

http://simonsarris.com/blog/tag/performance

Re: In defense of <canvas>

#40

Post by kevingadd »

twistedpair wrote: post #22
leeoniya wrote: post #6

re: canvas stacking, check out http://kineticjs.com/

Funny how few canvas libs use stacking of interaction layers. Obviously the slowest part is redrawing quickly for a drag/hover operation. Only one charting example that I know of (CytoscapeWeb) drops the interaction elements to an otherwise empty canvas for the interaction to minimize the redraws needed, and then brings them back when done. Most just seem to render everything, all the time, in the same canvas element…

There are problems with stacking multiple canvas elements, of course - increased memory usage and significantly increased composition overhead to name two.
Post reply on HN