I usually do like this.

Here's a quick screen grab.

https://www.dropbox.com/s/5fohocc03ihwq ... .webm?dl=0

Just drag and drop the strip to your animation.

Yes it would be good if you could select multiple frames with ctrl, or shift, but if you're reimporting a strip you don't need to remove the old frames. When you import you can just click replace whole animation. All frames will be replaced for that animation.

It would be good if the animation bar had a right click option with "replace animation strip" or "replace animation files".

The only context menu options if you right click an animation now is. Duplicate, rename & preview. Clear animation option would also be good. Removing all the frames and setting first frame to blank. Some more context menu options would be good.

The sprite editor is not really a work of art in terms of usability and UX, and could use some love in future updates.

Nice feature that I like:

I'm mostly using single files, and for me it's really easy to just drag and drop multiple animation frames directly into the Animation bar, so only missing the option to clear the current animation first so it doesn't add the frames behind.

You know that C3 even detects if you're trying to drop a strip in to the animation editor? You get a dialoge that asks you if you want to replace the strip or inport files.

There's a lot of hidden gems in C3. But once you find them, and learn how to use it properly it's working fine.

I would probably go with any midrange android device. Maybe something around $200-250? For testing purposes it's good to have a device that's not too powerful, so you can see how the game would perform for users that doesn't have really good smart phones. If you can get your game running well on a midrange phone then you can be sure it runs well on more powerful devices as well. Maybe even a lower end phone can be good, depending on what market and what type of game you are doing.

I hate to be a little bit harsh, but people complaining about the cost of subscription I can't really understand. People who don't like browser based, I can get their point but I haven't seen any good cost/subscription arguments.

If you're a semi professional trying to earn money from your games and you're not even earning enough to cover the yearly fee of the development tool you use, you're probably doing something wrong. If your games aren't even bringing in 99 per year, how do you ever expect to pay for any staff costs in the future, or marketing, or anything else?

If you're a hobbyist. Game dev is relatively cheap hobby. Even a gym card usually cost more. Buy a musical instrument, and rent a place to practice with your band? Even the bus fare to sports practice few days a week probably cost more than 99 a year. Most hobby activities cost way more than game development. 99 a year is CHEAP, for a hobby.

If you're serious about what you do, and enjoy it. 99 a year is nothing.

One thing I do agree on though is that one reason for the Construct success have been plugins, and after C3 runtime is done, all focus should be on creating plugins, or making it easy for "non-coders" to make their own plugins/behaviours and effects and share them. Right now it feels like for such a massive community, only a handful of plugin devs are still hanging around and actively support their plugins.

I think it was mentioned in a previous blog post that there is a plan to have something like that. I would love to contribute with plugins and behaviours if I could make them using Event sheet type of way instead of coding.

Created this thread for discussing upcoming new runtime improvements. Thanks for a great blog posts detailing some of the improvements we can expect.

Here are some link to the Blog posts.

Announcing the Construct 3 runtime

New text features in the Construct 3 runtime

Behaviour improvements in the Construct 3 runtime

The architecture of the Construct 3 runtime

Once the construct 3 alpha goes live, feel free to use this thread to post benchmarks of your games comparing the C2 and C3 runtime. Improvements, Performance, things that brake and other findings. It would be nice to see some benefits of the new runtime in some actual projects.

Keep up the good work Scirra Team!

EDIT: Updated the post with all the latest blogpost.

ASHLEY. In the BBox example I linked earlier.

Doing something like this will make the same operation A LOT faster, as the behaviour LOS can shortlist just a few nearby instances very efficiently THEN check for BBox overlap.. It's just as fast as my own behaviour that checks BBOX. Without the LOS running before the BBox event check CPU usage is about 40%. With the LOS behaviour shortlisting first (with a range set to 70px) the CPU usage is about 5% for the same BBox event checks. That really shows the power and importance of efficient shortlisting.

Here's the link again to the BBOX test project updated with the LOS condition before the BBox events.

https://www.dropbox.com/s/slu77hbw2wjvg ... p.c3p?dl=1

Or maybe... how about a math behaviour or plugin, or something that's more flexible? Where you can pass multiple expressions to do faster per instance checks, than doing it with events?

Events are great but a bit slow when you want to do big batches and check a LOT of instances. So quick tools to narrow down selection is good. That's why I pretty much always use LOS behaviour for my distance checks, At least the ones that have to run every tick on large amount of instances. Once the LOS behaviour has narrowed down my selection to the few objects that I need, I then run regular events on those.

Shortlisting candidates needs to be quick. (This is where behaviours are very useful) So you don't need to run slow events on all the instances.

Ashley not a bad idea. BUT it would also be cool if there were more behaviours like LOS, and the one I made check bounding box overlap, "Is on screen" and other commonly used conditions to reduce candidates when picking. since behaviours are that more faster it would be good if the behaviour library grew a bit with more useful stuff that you don't really wanna do with high level events.

—,

I read about square root being CPU costly before. After your comment I decided to compare (in C2):

When I disable either event #3 or #4 and run the project in debug mode, there is almost no difference between two methods.

With distance expression I'm getting 21-22 fps, and with squared values about 22-23 fps. CPU load is the same, around 97-100%.

Is the difference really that small or am I doing something wrong?

I'm pretty sure math is not the problem. I think loops in behaviours and such have a lot less overhead, that's why they are performing better. Every time you pick something you have to loop through every single instance, that's why I always start with booleans. Only 1 bit of information.

It would be interesting if someone could benchmark "is on screen" and a behavior doing the same thing. If i knew how to write plugins i would do it. There's no maths. Just checking XY positions of every instance in layout.

Under the hood I'm not exactly sure how the Events work, I just know that they are less efficient than behaviours doing the same thing, and that's especially noticeable when you have to do it on many instances. It can be a bit problematic to optimize math. :p I doubt 5+5+5+5 is faster than 5*4 for example...

They only thing I can control is reducing the amount of instances to "check", or do maths on, but in some cases there's no way around it. You have to check all, and that's when behaviours outperform events a lot.

Ashley

Here's an example c3p file with bundled addon.

https://www.dropbox.com/s/slu77hbw2wjvg ... p.c3p?dl=1

Events and behaviour basically do the same thing. Just checking BBox Overlap. Behaviour is soooo much faster than doing it with events. That's why I was wondering why this is the case, and if there is any improvements in the runtime that are making events faster as well?

<img src="{SMILIES_PATH}/icon_e_smile.gif" alt=":)" title="Smile"> Just curious because I would rather not wanna hire a plugin dev every time i need to do something simple as that just for performance improvements.

I love working with events. Just wished they were a bit faster.

Ashley

Thanks for the reply and the detailed explanation.

The reason i used the "picked" flag was that it could reduce the CPU time quite a bit, before running the distance comparison. If I remove it, it would check distance to instances that already have the opacity set to 20. With the picked flag I filter out those, so they don't have to be checked again. And when you're deselecting, you don't have to check every single instance in the layout. Only those that have their opacity set to 20... You can try disable the "picked" boolean in the first example and suddenly the whole distance checking operation uses almost twice as much CPU.

So by using booleans I can easily filter out how many that needs to be distance checked.

Using the first test with pick by comparison.

With the boolean I'm getting around 25% CPU usage, for the distance calculation.

Without the boolean I'm getting about 43% CPU usage , for the distance calculation.

Because I filtered out how many candidates that needs to be checked.

I'm trying to figure out ways to do do things as close to as effective as the LOS behaviour as possible only using events.

If the only reason LOS is so much faster is because the Collision cells, is that something that can be accessed by events in the future? Maybe a system condition or something similar? In the test project though, "Use Collision cells" is disabled for the LOS behaviour, and didn't make any difference if I enabled it or not. So that means math in behaviours are faster than events, or loops in behaviours are faster or maybe both?

How would one benchmark that?

I often tend to use very few behaviours/plugins as they are not as flexible as events. So that's why I'm curious if there is any measurable difference in loops and picking between the C2 and C3 runtime, and how one would go about to benchmark that?

Last year I payed a developer make a simple behaviour for me (As I don't know how to code) that only does one thing. Checking Bounding Box Overlap.

function intersectRect(r1, r2) {
  return !(r2.left > r1.right || 
           r2.right < r1.left || 
           r2.top > r1.bottom ||
           r2.bottom < r1.top);
}[/code:33yvx5ul]

I had to pay someone to do that, as it was not feasible to do that with events. It was just too heavy and CPU hungry doing the same thing with events.
So that's why I'm curious. If events can ever get up to par with behaviours, performance wise.

I'm following Ashley on twitter and especially the posts regarding the new C3 runtime, and from what I've heard it seems very promising with lots of performance improvements.

One thing that always been bothering me a bit, especially dealing with large instance count is the cost of picking. Sometimes just picking objects can be a pretty CPU intensive task if you're dealing with large layouts and and a large amount of instances, so i created this test project test different methods of picking, and how they perform.

https://www.dropbox.com/s/96e7y0njoqyqd ... e.c3p?dl=1

They all basically do the same thing. Picking objects within a radius and setting the opacity. and deselecting if they are outside the radius and setting the opacity back again.

This test demonstrates that there are good and bad ways to pick objects depending one what you're doing, and how many you need to pick.

Picking with LOS behaviour in this case was by far the fastest in most cases (I guess it's because loops in javascript are generally faster than events) So I'm just curious if the C3 runtime has any performance improvements when it comes to basic picking and loops using events.

Just out of curiosity.... Would be fun If Ashley could run the project using C3 runtime, and compare it with C2, to see if there's any improvements when it comes to picking and loops. <img src="{SMILIES_PATH}/icon_e_smile.gif" alt=":)" title="Smile">

Keep up the good work. Looking forward to try out the new runtime!