This is very cool -- I love that we're seeing more and more open source work on making web game engines that are not Flash. Stuff like Angry Birds and Cut the Rope were very cool, and it's good to see more frameworks and libraries for taking some of the effort out of it and making it more mass-market.
One thing that excites me especially is that a simple game creation engine in the browser might be a great chance to excite kids about programming with a very low barrier to entry.
Performance has been my focus on this work, I use a lot a cache canvas to not redraws gradient and path things but just copy caches. But i'm stuck on Canvas and requestAnimationFrame performances. Let's hope it will continue to improve, otherwise I could try to use WebGL but it will not be supported by every browsers for today.
Do you use a lot of sampling in the lights? I reach good fps on my macbook pro, especially on Chrome (but also on my home computer under Linux).
I hope we can use it with less sampling and less compute() calls for our games :)
eah I think the default scene use too much samples, like 51 for the right light.
Now my technique of combining shadow samples together is probably not the most efficient, I draw them with source-over and an alpha which is also a wrong hacky current implementation... but maybe using the CanvasData would be less efficient (technically I need to make the average of shadow samples' grayscales) - well we never know, I haven't tried yet ;)
I would be happy to have any contribution in the library :)
I feel you. I'm doing 2d game in html5 (I have 2 rendering engines - pure canvas, and webgl). Webgl works great, but works on small percentage of browsers, canvas version runs with ~ 45 FPS in 1280x960 on my 2 core celeron 2Ghz. And the main problem is just fill rate - I have background, and scrolling terrain, so I need to clear whole window every frame, and less than 50 (64x64 pixel) sprites at one time on screen. That's already too much for canvas to redraw at 60 FPS.
Are you currently prerendering to a separate canvas? Drawing it to a different (hidden) canvas, grabbing the image data, and just pushing that to the actual canvas might be a bit performance boost.
I've just tested. The fastest I get (37% time in drawing according to chrome profile, and ~45 fps) is when I draw everything moving to one, visible canvas, that I clear at the start of each frame, and everything static (background) is on another canvas, that isn't changed when it's not needed.
When I draw everything moving to off screen canvas, and then drawImage this off screen canvas into visible canvas, I get 48% of time in draw function, and ~35 fps.
It is indeed faster to draw everything to off screen canvas, than to on screen one (when I commented out copying off screen canvas to on screen canvas, and left only drawing sprites and tiles to off screen canvas - I got steady 60 fps, but obviously nothing is visible then :)). And copying whole canvas to the visible one is still slower, than drawing the sprites and tiles on the visible canvas in the first place.
Are you redrawing every time to the invisible canvas, or are you saving the data, and just pushing that to the screen? I'm not entirely sure if this is plausible for you situation, but take the event of a game like mario. The ground on the bottom can be drawn one time grabbing each tile from a tile sheet, and then you can save that bitmap data, so you cut out having to 'pick out' each tile, and just push that data to the screen. Any chance you have an example of what you're doing for your sprite\tile layer? I believe it can be a bit fast this way, but we may just not be on the same page.
I have 4096x4096 tiles 64x64 pixels each. I can't draw that to off screen canvas at once. I only draw tiles that are visible, and terain is mostly empty (some platform in the air), than I don't draw anything obviously.
My fastest code:
for (var y=y1; y>=y0; --y) {
var resultY = (0.5+
(level.topLeft.y - camera.position.y + camera.screen.height / 2 +
level.cellHeight + y * level.cellHeight-level.cellHeight)
)|0; // fast clip to int
for (var x=x1; x>=x0; --x) {
var tileImageNo = level.layers[z].cells.valueAt([x, y])-1;
if (tileImageNo==null || tileImageNo<=0) {
//nothing to do
} else {
ctxOnScreenCanvas.drawImage(
tiles[tileImageNo],
(0.5+
(level.topLeft.x - camera.position.x + camera.screen.width / 2 +
level.cellWidth + x * level.cellWidth- level.cellWidth)
)|0, // fast clip to int
resultY
);
}
}
}
I've also tried drawing to OffScreenCanvas in the loop, and then drawing that canvas to screen, but it was slower.
I could try drawing to off screen canvas only when player moves out off current off screen canvas, but that will trade small delay each turn into big delay every N turns, and that's even worse. But I'll try that.
Gotcha, my suggestion, might require too much change to be worthwhile, but won't hurt to say it. Here is the assumptions I am working off of:
- You have a background layer, lets just say it's a blue background
- A middle layer, lets say clouds that move as you move to the right
- And a tile layer, which draws the sprites, and the tiles of the maps
For the tile layer, we can break it down into two separate groups, animated sprites, and static sprites.
The static sprites, can be drawn to the offscreen canvas, and you get the imageData from that one time, and then push that data to the screen there after. Then the animated sprites will just be drawn to the on screen canvas every time. http://imgur.com/n6RFF The stuff that should be drawn to the offscreen canvas, then grab the image data has gray around it, and the animated sprites are in the green.
So for drawing the tiles of the map we only have to loop through the tile data, one time, and after that if the imgData remains valid (a separate flag) we can just push that imgData to the screen.
This would also allow drawing section of the screens on the offscreen canvas in chunks, and storing that draw to just be pushed to the screen at appropriate times.
I don't know if I explained it very well, I could probably through together a crappy little demo if you'd like.
also read this about imageData caching and explanations of the different opts. loop unrolling helps a bit, forget the typed array stuff for now, it wont work anywhere for some time.
I have 3 canvas elements, bottom with static backgroud, middle with scrolling terrain, and upper with sprites. I clear the whole middle canvas each frame, and only redraw parts of the other canvas elements.
But I don't use hidden canvases, just .drawImage each visible tile of terrain into the middle canvas each frame. I'll try to draw to hidden canvas, and see the difference, thanks for suggestion.
Huh. I've never worked with canvas, but is it possible that moving the middle canvas itself would be faster than clearing and redrawing it every frame? Like you have two canvases side by side in a div with overflow hidden, move both canvases each frame, and when one of them is totally off screen, move it to the other side and draw new terrain. Or are you hoping to avoid animating the canvases themselves?
I'll need not 2, but 4 canvas elements, each at least [width/2+1, height/2+1]. I'll try this, and let you know. Thanks for ideas, even if it seems a little strange.
they use multiple canvas layers. from working a lot with canvas lately, the fastest was to draw to canvas is not to draw to it :). if you have a scrolling bg that is static, you can just use a bg image sprite and scroll it via CSS/js. anything that can be done with a sprite should probably be done with one.
even for collisions etc, you're best off doing all the logic for your shapes and manipulating a DOM element (or even a mini-canvas) than re-rendering an entire huge canvas.
Mmh unfortunately requestAnimationFrame() seems to be very "greedy", it seems its strategy is to consume as much resource as possible (if the render() is not enough fast).
In most browsers, requestAnimationFrame tries for 60fps. That means that if your program blocks on the cpu for more than 1000/60 = 17ms while it's rendering a frame, you'll be at 100% usage
Nice. Looks like the lights are represented as single points, so even making it bigger still produces the "on/off" effect when moving objects in front of the light.
you are right, I ignore the light if its center is inside an object, it was before I implement these samples.
I should still fix it, maybe it's just by removing this check but I remember having some strange effects.
Have you considered MIT (or at least LGPL) instead of GPL licensing? Only other open source games or apps will be able to make use of this as-is. Of course that's certainly your right to do, just wanted to ask.
AFAIK, with GPL you are allow to use the library in a proprietary project but if you modify it, you must publish the library modification, not the whole project.
That's not correct (at least not according to my understanding). GPL license "attaches" itself to any project that uses it. So by including any GPL licensed library, you must also release the source code of the thing you are including it in. The LGPL allows you to use the library in a project and only commit back changes to the library but not open source the project you use it in. So if that's your intent (to just make sure that library-level changes are contributed back, but not to only restrict usage of the library to fully open-source projects), I would suggest going with LPGL (or, again, MIT, if you want people to be the most comfortable including your library in their projects). More info here:
Thanks for that, it was always unclear in my mind, now it's clear!
ok so I'll move it to LGPL soon then ;)
Yep, This is what I want for Illuminated.js.
I prefer to have benefits of the library modifications. It's a bit more restrictive coming from MIT (I used to use it for some projects) but it's not as restrictive as a "non-commercial only" license, so IMO it's quite ok, it's a minimum of thanks to the library.
So, if I have one light, and an object casting a shadow, and then another object inside the first's shadow, the area that is obscured by both objects is darker than one obscured by just a single, this is an inaccurate lighting model, and looks sorta ugly.
you are right! For sure it would be more efficient, and shaders are incredibly powerful.
I have considered that, but it wouldn't work everywhere today. So for now I have this implementation I will use for my web games ;)
Related to that is that objects overlapping create overlapping shadows. Which makes sense considering how your render engine seems to work.
Might I suggest instead of a solution in real time, how about a static deal that essentially generates a lightmap to overlay on top of the scene? I can think of several uses for that.
This was pretty cool, but I couldn't help being struck by how utterly poorly it performs, especially as soon as you add just a handful of objects and two light sources. Sure, it's written in JS, but JS has come a long way in terms of performance, and so have our computers.
This demonstration instantly makes me think of Blizzard's Diablo II from 2000, which features an identical effect during gameplay, with a seemingly infinite number of shadow-generating obstacles and as many light sources casting shadows as there are players on the screen, and it runs perfectly smooth even on a 500mhz P3.
One thing that excites me especially is that a simple game creation engine in the browser might be a great chance to excite kids about programming with a very low barrier to entry.