Is it better to draw each Background Layer onto different Canvases and then move them around or is it better to redraw them each frame ?
I have to draw them on canvases since my Game is tile based and the background gets build from tiles.
By definition, parallax is 2+ images moving at different speeds.
So the general efficiency rule of "Put like-speed animations on their own canvas" applies.
For example:
Your background may move once every 3 frames.
Your characters may move every frame.
Savings == 2 background draws every 3 frames (quite a good savings!)
Related
I created an animation screen in javascript which is running about 20 frames per second. (I can do it faster, but 20fps is fine and have one eye on battery consumption.)
However, it can rain or get dark in the game, so I want to put a blue or grey hue over the scene.
The obvious idea is to have another canvas with a higher z value with the blue/grey hue on it. I can have that offscreen or onscreen depending on when it rains or gets dark.
Unfortunately, this is not a great solution as I need to capture touch/mouse events on the original canvas. This means the rain/dark/hue canvas would block the original canvas from receiving those events.
So is there any fast way of doing this? Again I want to keep an eye on battery consumption and speed. (I do not want to access and modify the image data of each pixel of the original canvas each frame.)
Is having the rain/dark canvas showing permantently but with transparent, blue or grey drawn once every 10 or so minutes (the typical gap between night/rain events). This could then capture the mouse events and the lower canvas has mouse/touch events turned off.
The only thing I do not like about that is when it is a clear day I would constantly have the gpu calculating colours for the screen when looking through a totally transparent canvas. That does not seem great.
If you really need to use 2 canvas, you can use the pointer-events: none CSS property so the clicks events go through the "filter" canvas.(Click through div to underlying elements)
If you are using a canvas library, there most likely is a layer system so you don't have to manage it by yourself.
I am using KineticJS and wish to create a precise image hit region (ignore transparent pixels) for my sprites. I see how createImageHitRegion accomplishes this for images, but I don't see how to apply this to sprites. Said another way, while method createImageHitRegion is a method which accomplishes what I want for images, there appears no similar method for sprites. If I could create an image hit region on just one image of each of my sprite that could work for me, but a big rectangular region which encompasses the entire width and height of the image of the sprite can't work. Any ideas for a workaround? Perhaps I've missed something?
There's no easy way hit-test non-transparent pixels on sprites.
I can think of a couple of theoretical workarounds...
If you can draw a path outlining the pixels you want to hit.
The sprite object allows a custom drawHitFunc so you could use mySprite.afterFrame to redefine a custom hit area for each of your sprite images.
mySprite.afterFrame(0, function() {
mySprite.setDrawHitFunc(function(){
// draw the path you want used for frame#0
});
});
// repeat for all frames
If you can't draw a path outlining the pixels you want to hit.
Instead of using sprites, make your own sprites using individual images.
Do that by creating a series of images (including createImageHitRegion) and sequentially making one of those images visible so it appears to be playing a spritesheet.
I am experimenting with HTML5 Canvases in an attempt to create some animation. My ultimate goal is to be able to animate a box to a particular location at whim, for now im just animating it across the screen. When I move it across the screen I geta black trail left behind, how do I clear this "dirty" section without removing the background grid?
A jsFiddle of the code is here
Two solutions
Redraw the background on the top of animation before moving it to the new location. This so called dirty sprite technique - faster - more complex.
Redraw the whole canvas between frames
If drawing the background is a complex operation just hold a prepared background buffered in another canvas for speed.
You have to clear what you've drawn if you don't want it to be visible. I assume you don't want to clear entire canvas to avoid redrawing grid and spending CPU cycles. You'll have to do this differently.
Possible solutions:
have two same onscreen canvases one over the other. Draw grid on canvas below and don't clear it. Clear part of top canvas and redraw on it.
have one on-screen and one off-screen canvas. Draw grid on off-screen canvas. Each time you animate, clear whole on-screen canvas, copy prepared grid from other one, and draw what you need over it.
In recent trends I've seen people animating CSS sprites using JavaScript instead of using animated GIFs?
Ex:
http://www.google.com/doodles/eadweard-j-muybridges-182nd-birthday (in fact, Google used this technique in other Doodles too)
https://everyme.com/ ('me' logo)
and many more...
Is that all just to show or experiment with technology or are there any benefits out of it. I m interested in knowing the benefits, if there. The reason I m asking is that I couldn't figure out as in both cases we need to generate the intermediate frames (mostly using tweening technique).
Control
You have no control over animated GIFs. You can't start them, you can't stop them. They just animate as soon as they load.
With sprites, you can control the animation. You can start, stop and react to browser events, pan through the animation. For example, Google Doodles usually activate when you click on them.
A nifty GIF control system can be found in the 9gag. You can start them by appending them to the DOM, and stop them by removing them and swapping them with a pre-generated "first-frame view". But that's as far as GIFs go.
Independent Instances
When you load multiple instances of the same GIF, all these instances use the same image across the page and move at the same time. If you have a row of dancing unicorns GIFs, they'd be dancing at the same time. Synchronized dancing!
But with sprites, even if you are using the same images, the animation relies on the underlying script. So if one sprite is animated by one script and another by another script, both animations can run independently, and differently from one another.
This saves you from creating another GIF and it's easy to modify since you are only changing the script.
Ensuring smooth animation
Animated GIFs just animate while loading, and when the internet is slow, the animations freeze up until more of the image gets loaded.
In contrast, the advantage of sprites is you can pre-load them, ensure all images load beforehand. This makes sure that the resources used for that animation are already loaded prior to animation to make sure it animates as smooth as possible.
However, GIFs are still images. You can dynamically load them off the DOM and listen for a load event before you append them to the DOM.
Partial rendering
With PNG sprites, you can do "partials" in the animation, breaking an animation scene to parts. For example, when a character stands still, but the arms are waving. You don't need to animate the entire character, or the entire scene. You can place an element depicting the sprite of the character's body in a "freeze" state while the arms are a different element that is animating. This conserves space and size of the sprite sheet. A good example for this was the 2012 Mother's Day Doodle by Google.
In contrast, most of the time, every frame in a GIF animation is whole image, and animates whether or not anything in it moves. The more frames, the bigger the size of the GIF.
GIFs just don't scale
GIFs were meant for icons. The ratio of file size to image size don't scale up that well in GIFs as compared with PNG and JPG.
On top of Joseph the Dreamer's answer...
As far as I know, or atleast it used to be that, GIF files are NOT true colour, another reason to use a JPGs/PNGs as a css sprite.
I need to achieve something like this for my website: Flash Rain Effect
Is that possible to do in Javascript? I want it to be just as smooth as it is in Flash.
Another flash rain drop water effect
Yes, it's possible: http://www.lab4games.net/zz85/blog/2010/03/10/rain-water-ripples-with-html-canvas-javascript-jquery/
Smoothness is something relative, and you may not be able to have the same performance as hardware-accelerated Flash. With that said, more and more browsers are starting to incorporate native hardware acceleration (Direct2D and otherwise).
You should be able to do this using a combination of JavaScript and canvas elements (HTML5).
If you don't want to use the Canvas (or can't) you can do that by creating an image that looks like a rain drop, make it a PNG with alpha transparency so the non-drop parts of the rectangle don't show up. Then you create 200 or so IMGs programmatically and position them absolutely (and randomly) over your scene. Each one gets positioned, then turned visible for a few milliseconds, then turned invisible, then rinse and repeat.
For variety you can either make images of different sizes and shades so some seem in the background and some in the foreground, and vary those.