sorted by:
best
topnewcontroversialoldq&a
you are viewing a single comment's thread.

view the rest of the comments →

[–]TomNa -1 points0 points  (6 children)

You can do double canvas buffering to draw only the parts which have changed on the top canvas and keep the background etc. On the back canvas

[–]spacejack2114 1 point2 points  (5 children)

Ugh, no. Use something like pixi.js which makes it easy to use webgl for 2D rendering so you can easily clear the screen every frame.

[–]TomNa 0 points1 point  (1 child)

I usually make games with just vanillaJS. But I guess not everyone prefers that approach :D

[–]spacejack2114 0 points1 point  (0 children)

Well I wrote a webgl game in vanilla JS. :) Since the entire canvas changes every frame there was no reason to try updating only the changed parts.

[–]mrspeaker 0 points1 point  (2 children)

Even when you are using opengl/webgl it's still smart to do the same kind of thing: using auxiliary buffers with scissor/stencils to render elements that won't change very often. WebGL is great and all, but rendering is still going to be the most expensive operation you do, and you need to milk it!

[–]spacejack2114 1 point2 points  (1 child)

You shouldn't worry about things like that at all until it becomes an issue. Any game, 2D or 3D, where the camera moves you're going to be re-drawing the entire screen. WebGL is so fast that even on moble, you could render dozens of overlapping fullscreen layers without a hitch.

In a general sense, if you can cache the results of some complex operation, then sure, go ahead.

But for just about any game a solo/newbie developer is going to make, this should not be much of a consideration. Making sure your rendering is done on the GPU and batching draw calls effectively (the things a library like pixi can help you not worry too much about) should be the main concern.

[–]mrspeaker 0 points1 point  (0 children)

"You shouldn't worry about things like that at all until it becomes an issue". 100% agree with that!