Ok, here's a little bug:

Say we have a sprite with an origin point and in the other animation frames this origin point has a different location.

If the animation plays, all is well, but if it doesn't and we set the frame then the origin of the first frame is used.

Actually while testing this turned out to be even closer to that than may seem - if the animation is stopped at the start of the layout then this problem shows itself. If the animation gets a chance to play and then gets stopped there's no problem.

So the bug may actually concern initializing animation frames if they haven't been played yet.

Anyhow, here's a capx - pay attention to the origin point in frames 1 and 2.

Thanks to Kyat for checking this with me.

I use 5-Random(11) for cases like this.

And if you try the same in, say, Paint?

I'm using PS and Paint.net and it work just fine. I suspect Gimp doesn't play nice with the standard Windows image copy/paste format.

You can paste into the image editor - so, you must have a sprite, double-click it and then paste into the editor window.

Very nice graphically, but I have to agree that the controls are a bit messy. Yann is currently building a gravity-based thing as well and in his case the screen nicely rotates around the player, which makes navigation MUCH easier.

Not sure how that would work with moving the boxes and such, though.

Not sure what you do for the values here - whether it's distance based or such, but for me doing a pre-calculated array of the light circle gave some pretty crazy performance gains.

Hey, this is pretty cool and the performance is quite good (steady 60 fps or so). I was just making a raytracer of sorts in CC, this looks super-similar, although I slightly cheated with the shadow part, just doing some distance-based point checks.

Whoops! My bad. I wish CC and C2 sections were colour coded or something.

Anyhow - modern browsers support font loading and such - perhaps an option for C2?

Search here for Resource Plugin which allows temporarily installing a font for the game to use.

Thanks. I have also updated it with the ability to set the opacity - so that it doesn't have to be completely transparent. Performance seems to be about the same, so I'm leaving it under the same name.

As far as I could tell an effect like this isn't represented here so I went ahead and just tore apart some existing effects by Shviller and Rojohound (thanks, guys) and reassembled them into this.

Basically what it does is: You pick a RGB colour and that colour becomes transparent.

Before:

<img src="http://i244.photobucket.com/albums/gg36/some9000/cd6dfc98.png" border="0">

Settings:

<img src="http://i244.photobucket.com/albums/gg36/some9000/1ed90ca0.png" border="0">

After:

<img src="http://i244.photobucket.com/albums/gg36/some9000/c50dc82e.png" border="0">

Really simple. Now WHY would you need this? In my case it helps with doing canvas capturing and then overlaying it on top of other things with transparency.

Grab it here.

Note: Some colours won't show as transparent in the editor, but all seems to work alright at runtime. Enjoy.

Sorry to bump my own last post, but I did a little optimization and the whole thing is now about 15-17 times faster (heh). For smaller things realtime raytraced light is fairly viable. It's still the same example, same keys and all that.

I'm fairly sure there's more to be squeezed out, but for now you get the latest example. Touch a light to start. It also doesn't render unless necessary now, so don't get too excited by the thousands of fps it shows while idle.