+1 On this. #1 could be fairly easy or very complex depending on ashley's code. Anyway it's a nice addition. Solo layer button is very helpful too. Best of all for me would be #3 . Purge unused objects. Things can get messy fast if you forget to remove object type every time. One thing is removing from scene other is from project. Maybe delete to remove from scene and shift+delete to remove from project entirelly;

Well pixel rounding will not help with that. It's about texture sampling. Zeus wants nearest neighbor, that is, no filtering. It's just a simple tweak on opengl.

A standard magic wand, specially for a pixel paint type of editor is easy to implement, i think it's not out of the world to add it to C2. The functionality is similar to 'Fill'. Of course if you need anything more fancy you better use something like Paint.NET , PS etc.

HTML5 made no promises. It's peoples expectations that are being hurt. For games i think HTML5 is more than powerful enough right now. For apps it still falls short. Though there's many talented people working on it. The critical thing about HTML5 is support. That's the thing.

Ashley : Would this be usable for C2 ?

I've discovered this thing called App.JS. It embeds Chromium inside a desktop shell via Chromium Embed Framework (CEF) and uses Node.JS . In short it's a 'make desktop apps with html5, css, js' framework. So in theory it could be faster than Awesomium since CEF is more lightweight. It supports webgl so i had to try to run C2 in it. I succeeded. More or less. It does indeed support webgl, and the particles example ran fine. But it caps at 30fps here on my machine. A good thing is that it starts much much faster than awesomium but uses more disk space. And uses less RAM. It could, be a replacement for Awesomium but further investigations are needed. The fact that it runs at half fps than awesomium intrigues me though. I had to remove this lines from c2runtime.js for it to run with webgl:

/*if (tempgl.getSupportedExtensions().toString() === "OES_texture_float,OES_standard_derivatives,WEBKIT_WEBGL_lose_context")

                         {

                            ??console.log('webgl not supported');

                            ??use_webgl = false;

                         }*/

So maybe there's no full suport for webgl yet...

Anyway here's the files if anyone wants to hack it too: Download

^ This. Perfect

OP idea is valid since you can't really "resize the sprite in Construct 2 itself". One thing is resizing the image to half the size. Other is rendering the image at half the size. The result can be the same, but the image is effecivelly resized in one , and stays the same size in the other case.

Waiting anxiously :)

I'd greatly like to see Lua scripting too. But that would, i believe, need a major code rewrite. I don't know . How MMF2 even supported scripting at all via plugins ? In the case of C2 i think the engine would have to be coded from the ground up with scripting in mind. The visual scripting would be just a 'frontend' for the script code...

An idea to add tile paint features on a non-tile based editor like C2 is something like:

1.

<img src="http://dl.dropbox.com/u/2472278/Images/1.PNG" border="0" />

2. Scene Editor

<img src="http://dl.dropbox.com/u/2472278/Images/2.PNG" border="0" />

3. When double click

<img src="http://dl.dropbox.com/u/2472278/Images/3.PNG" border="0" />

You get the idea. The brush icon is to emphasize that you paint the tiles. In the painting window of course there must be a tile pallete to pick the tiles just like tiled editor and similar.

There's several ways to implement that of course , and i believe it's compatible with current C2 workflow. One point that would have to be addressed with this system is collision. Maybe a grid based collision body.

I meant something like: If an event sheet is assigned to a specific object on scene the events will relate only to that instance, so single scope. If assigned to an object type, all objects of that type, bigger scope. If assigned to scene, then all objects from that scene, full scope and so on. Don't know if it could go more high level than scene scope... The idea is having total control of picking. Of course that can all be done with current system. It's just harder. It's only an idea that passed my mind, don't know if it would be viable to implement. It's like a picking top level filter.