Not currently. You'd have to 'prerender' the blur in another program like photoshop and import it.

I'm not sure. I think it would probably need to be coded into the program itself, but you could post in the plugin development forum asking if it's possible, or wait for an answer here from someone more knowledgeable than I about plugin development.

Even if C2 gets the ability to run logic and render faster than the screen refresh though, it won't be as fast as construct classic, because C++ is far faster than javascript. Also C2 currently lacks a profiler with a high-resolution timer.

I should explain - the timer in the profiler can work, far, far faster than the framerate in much smaller bits of time than 0.2 ms. However, I'm not quite sure how to set something like this up properly because in unlimited mode, the graphics card is probably going to be the bottleneck and the cpu might end up waiting for it to draw to the screen, as there's no way to decouple running the logic from rendering.

Contruct 2 currently can't work above 60fps. That means, at best, you're going to be working in about 17ms 'steps' per frame regardless of the accuracy of the input with the keyboard.

I would recommend construct classic for this task. It has an 'unlimited' mode where the exe runs as fast as possible. My computer is nowhere near top of the line and it gets about 4,000 fps using this method with a blank .cap, and I seem to recall someone mentioning getting over 10,000 fps. If you keep the content and code simple and keep all unnecessary code deactivated, hopefully it would be fast enough for you.

Construct classic also has a very high precision timer in its 'profiler' plugin. Use that and the unlimited mode together to get high precision data.

Keep in mind though that the larger the window, the more pixels the graphics card will need to redraw. Keep the window small and deactivate as much code as possible to keep the fps high.

At 5,000 fps, you're getting a precision of about 0.2 ms per step, which I hope would be adequate. If you want faster than that, you're probably going to have to use something else like raw C++.

Post the link to the page you're referring to.

Whoa, have you really made an android exporter, or do you mean 'if' you made one?

If you HAVE made one, how does it work? Does it generate native android apps or is it a HTML5 wrapper the same way phonegap and appmobi are? And are you going to release it to the community? :D

It might seem that simple, but it really isn't that simple for a variety of reasons.

The EXE wrapper.

Lucid, if you recall, there used to be a major memory leak in CC every time the parameters window of the event wizard appeared - it had to do with drawing the icons in the window at the bottom where you can get the expressions from. The more icons there, the more memory it would leak, and eventually that would result in the IDE getting screwed up, and a 'not enough memory' window that appears that, at least on my machine, was a different visual style than the rest of the IDE (it might have been when I was using XP though, I can't remember what it looks like on my new comp). It's the same effect.

Also, huge image files isn't the problem - those drastically increase preview time, which is why I load them at runtime. I think the problem has more to do with huge numbers of completely different objects in a layout (different objects with different animation frames, not clones), possibly a result of drawing the icons in the objects bar, as the bug seems to hit quicker for me when editing animations in layouts with tons of objects. If I switch to editing animations in a layout with less objects, it seems to take longer to happen. I think it also requires actual editing and saving of the edits to the animations rather than just opening and closing the animation window. I'm not entirely sure it's that though, but that's what it seems to be.

I should have tested the various browsers - that seems to only happen in chrome. I guess it's a chrome bug then.

Yeah, I used the same .capx, removed the physics and 60 fps at browser window 1920x1080 (game window 640x480). Add physics to one object, 18 fps. Resize the browser window with physics to 640x480, 60 fps again. Weird. :/

I noticed the size of the browser window seems to be slamming the framerate when physics is involved, even if the game is not set to fullscreen and there's one physics object in the layout. If the game window is 640x480 and the browser window is the same size, it's smooth. If the game window is 640x480 and the browser window is 1920x1080, the framerate is significantly lower. This seems to happen with both the old and new physics (it didn't affect the test I did). Does this happen for anyone else?