This looks great, but I'd like to see these features:

* Shadows that aren't completely black

* Coloured lights

* 'Textured' lights (like in Mark of the Ninja)

* Light Cones

Get those working, and this'll be perfect. I wouldn't mind also being able to detect whether an object is 'lit' or covered by a shadow, for stuff like stealth games.

Well, looking at the engine itself, it's a "tile-based" engine, but the number of objects on-screen that need to be checked at any one time isn't much. The player object has a set of 16 sensors (which are required for operations that overlap offset isn't appropriate for). It's not that many, but I'm still seeing the number of collision checks in the realm of nearly 2 million per second, which is kinda insane.

Besides, I did a re-examination of the debug results, and it provided an eye-opener. The events that take up the most CPU are the movement routines, which totals around 35% CPU use out of 45%, and considering it's a basic test level and it's still causing a lot of slowdown, that's not good at all. I think the way the engine itself is set up is incredibly inefficient, which is surprising, considering it's a port of a similar engine from Classic, which ran fine.

In short, I suspect that I'll need to find another implementation if I want to do a Sonic engine... Or just have someone write up a javascript behaviour. XD

From what I can tell, the 'every 0.1 seconds' method mostly breaks the engine completely. To be more specific, the engine is a pure event-based Sonic-style platform engine, and the collision checks are for a set of collision 'sensors' checking for overlapping with terrain objects. The engine itself uses a lot of functions for collision checking. The engine itself is about a year old, but it still works fine, aside from being seriously unoptimized to hell and back.

So, yeah, using the 'every x seconds' condition doesn't work, and the other tips aren't really applicable here, which is why I was mainly asking for a distance-based method, since it would massively cut down the number of objects that would need to be checked at one time.

Nobody said making a Sonic engine was easy :p but thanks for the tips.

Okay, that's some very impressive stuff. You plan on sharing the code for it? Because this would be very handy to have available.

I went and revisited an old engine I was once working on but abandoned because it was ridiculously slow, and what I found via the debugger was, that, as I suspected originally, the number of collision checks were though the roof (due to the engine's need for multiple detectors).

Now, the question is, are there any methods for cutting that down to size? I was thinking of using a distance check to determine if a solid object is close enough to the player to actually be worth checking, because there's no point trying to check for a collision with an object that's ten-thousand pixels away or something, but I can't quite figure out how to do that.

Of course, the logistics of this whole thing are going to be interesting, to say the least. I'm assuming that testing a C2-made Wii U would require a dev kit, which, unfortunately, can be somewhat expensive, though I imagine there might be ways around that, considering the type of stuff we're working with. Actually providing dev kit functionality to normal Wii Us runs the risk of exposing exploits for hackers, which Nintendo does not want, though I am personally a supporter of the homebrew scene.

Still, I really do hope we'll be able to test C2 games without having to get a dev kit just to do it.

It is interesting to look at. I know an XML-based system would admittedly be somewhat trickier to implement, but it's still based on a single image, but rather than in a uniform grid, the characters are packed together and split via information retrieved from the XML. I'd honestly say that using a format generated by, say, ShoeBox, for example, would be easier to fit within a power of two image without actually needing to fiddle with fitting all the characters into a suitably sized grid.

I'd really like to be able to use something like this without needing to go to all the trouble of assembling it into a grid manually:

<img src="http://opengameart.org/sites/default/files/boxy_bold_font_4_0.png" border="0">

Have you tried the tool here?

http://www.scirra.com/forum/sprite-font-generator_topic72160_page1.html

Also it seems like the only benefit from using what you suggested is those pre-made fonts. That's fine and all, but don't you loose the ability to edit them graphically?

I haven't used that tool yet, but it's not really what I want either.

And no, you don't really lose that ability to edit them, all you really need to do is throw the modified bitmap font image into ShoeBox to create a new .fnt/.xml file. Not exactly rocket science.

Honestly, I'm gonna have to put this out here: the sprite font plugin as it is, quite honestly, quite tedious to work with in order to get the bitmap font set up in the first place. It mainly has to do with how the sprite font files are formatted.

Nobody makes sprite fonts in a uniform grid. No-one at all. And quite frankly, there's a good reason they don't. There are already standard formats for bitmap/sprite fonts, one notable one being Angelcode's Bitmap Font Generator format, .fnt, which is supported by multiple notable engines already, and it can also be generated in an XML format. ShoeBox can also generate bitmap font files for fonts hand-made in image programs, as well, and can also generate it in XML.

And then there's some bitmap fonts out there that use the format used by the Bitmap Font Writer.

I really do think sprite fonts are great, but the problem is, the way the plugin is set up right now just makes it far too tedious to actually set up a sprite font properly, especially with the knowledge that there are far easier methods of achieving the same result.

I posted this before, but basically you are looking for a shader that does shadow casting.

http://greweb.me/2012/05/illuminated-js-2d-lights-and-shadows-rendering-engine-for-html5-applications/

This guy has a head start on it.

Okay, Illuminated.js looks amazing. Considering it's an open-source plugin, I imagine all Ashley would have to do is integrate it into how Construct 2 does things. If he doesn't already know about it, he should.

Looking back on this thread, I've been playing Mark of the Ninja lately, and what strikes me is how it uses dynamic lighting. Finding examples is pretty easy, google images has plenty. The lighting itself is somewhat cone-based and has a 'textured' look, but it can be 'blocked' by solid objects, like the lighting from Construct Classic.

Remember how the light object and the shadow behaviour from Construct Classic worked? I've already stated how I think they could be greatly expanded upon in concept in Construct 2, but I also think Using polygon-based lighting instead of cell-based is a reasonable compromise. Since sprites in Construct 2 already use polygons for collisions, it would probably be far less computationally expensive and much easier to do than cell-based lighting.

I know I like to keep bringing up Starbound, but this is incredibly cool stuff:

<img src="http://www.abload.de/img/starsrourw.gif" border="0">

<img src="http://i.minus.com/dpYoU9h0gaF98/Starbound%20Day%20Cycle.gif" border="0">

<img src="http://i.minus.com/dtzx3VUL8rfnu/Starbound%20Lighting%201.gif" border="0">

<img src="http://i.minus.com/djWrYgW05S0kL/Starbound%20Lighting%202.gif" border="0">

And you don't really need cell-by-cell lighting to replicate the same results (aside from the way the light 'penetrates' into the ground, but still).

Now, the thing is with such lighting solutions, good luck trying to make them work with just events. I think it would be a good idea for an official or unofficial plugin to be developed for polygon-based lighting, with as many options as possible for what developers want with lighting in their games, whether it be pitch-black darkness in absence of light, or just low light for stuff like stealth-based games.

I'd also like stuff like specifying image points for the 'origin' of the light itself, like a light attached to a gun, for example (as shown in Mark of the Ninja), and also being able to adjust the angle of the light without changing the angle of the object itself (those last two suggestions I also want to see applied to the Line of Sight behaviour).

So, yeah. Polygon or grid-based, I don't mind as long as it works well, I just want a good lighting solution, dangit.

Games with multiple save slots typically display certain stats in that particular save slot, such as time played, character level, level/location, progress percentage, among other things.

Thing is, I'm not sure how to actually do that with the save system, if at all. Is it possible, and if so, how?