Use [TUBE].

It does if you double click the object in the layout, but not in the objects tab. I agree it would be nice if double clicking it in the objects tab would open the animation editor.

Node webkit.

If you're planning on using JavaScript for the game, I don't understand at all why you wouldn't want to use c2. You won't get any speed benefits because c2's runtime uses JavaScript as well, you'd have the same limitations c2 has, and you'd have to spend a lot of time learning the intricacies of working with JavaScript and its quirks, which c2 already does for you, and Ashley has put in a lot of effort to optimize it so it runs smoothly. It would be reinventing the wheel.

If you want to use JavaScript for something, just use the SDK and make a plugin.

You should also read scirra's blog about the advantages using c2 over coding your own game is straight js: https://www.scirra.com/blog/52/construct-2-vs-javascript

It's gotta be good enough for games or else why would Nintendo support it?

From the article:

"The Wii U console is powerful enough to smoothly run such applications as developed in this way without writing any specific programs."

No mention of webGL, though that doesn't mean they won't support it. They also mention some other aspects of the system are running using HTML5 and web technologies already.

Bartosh

and C2, and HTML5, just seem a LONG ways from being were I need it to be.

Out of curiosity, what is it about C2 and HTML5 that isn't where you want it to be? You said something about the speed and client side resources, what is it you want to do?

but I think i'm done with gamemakers

I think I'll just start strait coding my projects, its going to be hard to start all over again. but at least code never really goes obsolete.

I'm not sure of your experience level, but in case you're unaware, as I hear it conventional wisdom is most who try that route don't end up making games, they spend so long on the engine they don't even get to making the game itself (make first version of the engine, lots of it needs reworking, rework it, technology has improved and the engine needs to be updated again to look modern, rework again - years of work).

Even if working in C2 isn't quite the workflow you want, it would almost undoubtedly be easier to work with than rolling your own engine.

R2 is the newest version.

http://www.scirra.com/forum/topic48884.html

You can do a lot of that with the instance bank plugin. http://www.scirra.com/forum/topic62131.html

You can already do this with the move at angle action. Simply enter angle(self.x, self.y, targetx, targety) for the angle.

3 seconds per frame is 0.33 fps, Vs 3 fps. That's not 100% faster; it's 10x as fast; 900% faster

Did you make sure to set collisions to bounding box as well in both c2 and cc?

Lol whoops, no. I really screwed up that one in multiple ways. :P Let me try that again.

To get the math right and a more accurate percentage I ran a second test, being more careful this time: 730 instances of both sprite and sprite 2, no rotation, just collision checks, none overlapping, using bounding boxes (the test would be incomparable using full collision, because it would wary wildly depending on sprite size and number of collision polys):

CC 55fps, 0.0181s per frame

C2 17 fps, 0.0588s per frame

I think that results in C2 being about 31% the speed of CC there.

4fps VS 9fps is over twice the speed, over 100% faster.

Technically that was wavering into 5 fps, so I just made it to about 100% - I should have been more accurate, it was 4 a bit more often than 5.

More accurate version:

CC 53 fps, 0.0188 per frame

C2 21 fps, 00476 per frame

C2 being about 40% the speed of CC.

The first test creating instances, 1.2s/1.8s results in c2 being two thirds the speed.

So it seems the result is higher - CC seems to be about 1.5-3.2x faster.

Unless I screwed up again. :P

Also, more work CANNOT be done per frame at low fps, assuming rendering always finishes first; It just can't spit the logic out fast enough. Rendering finishes in a fraction of the time, and the cpu is just chugging, trying to finish calculating the event sheet.

Of course it can - that's the entire result reason why it's a low FPS in the first place. I'm asking it to do more work than It can manage in a 60th of a second. If a processor could manage 60 calculations per second, at 60 fps it could manage 1 per frame, at 1 fps it could manage 60 per frame. Therefore, more work is done per frame at 1 fps. Regardless if it is the CPU or GPU that cannot keep up, either one has to wait for the other (though the CPU works one step ahead since the gpu renders the previous frame concurrently). In these tests, the GPU was waiting on the CPU.

Interestingly, even seeing the result is back where I estimated originally before these tests, I don't feel like I care. I guess it's because c2's speed is sufficient for what I want to do, and device speed and browser optimizations are only going to improve.

While I wouldn't mind that extra speed, I guess the reason I feel this way is because I'm not sure I would use it. I can understand why others would want it though.

Agreed, fixing the stickies.

You can't currently. This is something I would really like too that CC had. You can mimic the effect with storing uids as variables.

Ashley - any chance of the pairer object from CC getting added to C2 eventually? It was a lot simpler than using variables.