Thanks for the great and detailed wrap-up of the plugin TheRealDannyyy!

BTW: here's a short test of sound unloading I made with TheRealDannyyy 's tool (so you could see how much memory it can save):

Ashley I saw you said:

I'll try and get audio unloading in the next build...

That's awesome. I know you can handle this yourself, still if you find the snippets from AudioPlus plugin useful you're obviously free to put them in the official plugin. I've used a lot of official code anyway.

One additional thing. Because of unloading features, the common approach will be now to not preload all sounds and startup but load them selectively. Therefore I was planning to add On sound preloaded condition. But as you're planning to add it to the official one, I'll pass with this one. Still it would be great if you could implement such condition to the plugin so C2 devs could make nice visual preloaders.

Thanks

EDIT - Updated YT URL above, now it has much better quality.

We have a cool guy called AndreasR here who answered your question before you even asked. That's how cool he is

You must be very careful when working with version control and C2. I don't think there is any automated way to combine two projects which vary so much (unless you understand C2 XML perfectly and write your own merge script). So I'm afraid you have to do it manually.

Next time remember to work on the same project/repo from the start. When you start work, always make an update from repo before you open C2. Commit when you're done. But that's not all. You have to avoid working on the same parts of the project at the same time. There are situations where SVN/GIT merges the code without any issues but new code will be corrupted for C2. Changing object name, adding behaviors etc.

The source image is not a part of the project. Once you load it into your project, C2 makes a copy of that source image. Resizing it with the built-in image editor will update the image (in project, not the source) so also will affect the download size and memory usage.

If you would for instance resize the source file (in external editor), nothing would happen in the project itself.

Note that resizing the sprite object won't have such effect as this will resize only the object, not the image.

It is not an issue for most of games, however there are some games like OP's game that are heavily dependend on the big amount of sounds which are unique per layout. In such case the good approach would be to preload only common sounds at start of the project and then preload those unique sounds at the beginning of the particular layout. Once the layout (stage) is over and those sounds are no longer needed, their buffer should be released.

And so I've added several actions to unload/release sounds:

All I'm doing here is just dropping a reference in audioBuffers array. It obviously doesn't work instantly as it's impossible to call the Garbage Collector manually in JS, but it is good enough as GC comes soon during next layout gameplay. In the end the game consumes much less memory with this approach and C2 is no longer limited to light sound dependent games.

Just disabling sounds preload on start is not enough as during the game more and more sounds get loaded into the memory anyway what in the end has the same effect - memory limit reached.

As mentioned earlier, we are still testing those features but it looks promising. TheRealDannyyy will write a bit more about it soon. I really hope you Ashley will have few minutes to take a look at the code and consider adding those features to the official Audio plugin as maintaining both plugins which are in 90% the same from the code perspective is pointless and it will be easier/less confusing for C2 users.

I personally can recommend Borys (

.@StaticCloud it would be the best if you could join us on Armaldio's C2 Discord server (https://discord.gg/YfMsC5D). We are online there most of the time so it would be more comfortable to talk with real time chat software there.

Indeed TheRealDannyyy suggested recently to create audio unloading (memory releasing) features as (as he mentioned already) Audios in C2 can eat up a lot of RAM and bring problems. The plugin is in alpha testing, but it seems to work well already. Your project would be a great test case for us. So please join the Discord and ping me (Toby R) or TheRealDannyyy there to talk further. Thanks.

Could you not accomplish the same thing with, say, a blank dictionary? Am I missing something?

As I mentioned in my recent post:

It’s all about the approach. You can use nearly any other plugin and achieve the same result. I just made this one to have an empty plugin so to not load unnecessary data to the memory and have a separate plugin with unique icon to make it visually distinct.

So yes, you can use a blank dictionary as well. Wouldn't be that elegant (IMO) as using this empty plugin, but you can achieve the same results.

I took a quick read, I see a difference is... just for sorting?

No it's not just for sorting.

It is better to use Globals plugin approach instead of native global variables because:

• it has the same features as native globals (and more!)
• it has boolean type variables (not possible with native globals)
• it doesn’t pollute the variables listing
• it doesn’t pollute the event sheets
• it is possible to group variables (not possible with native globals)

Up to that this approach is better semantic-wise and code architecture wise. You may know that modern languages like C# or JAVA do not allow globals at all (for a reason), instead they offer public static variables encapsulated within the class namespace (so basically the same solution as with Globals plugin. You can read a bit more about that in my recent post (if you haven't yet - also linked to the first post here).

Going further, sticking to good practices (following good code architecture and semantics) lets you keep your code clean and intuitive which then implicates in better project maintanability and so on... It's a whole big chain.

What are difference between this plugin globals and c2 globals?

I explained that in my article: Globals – Construct 2 plugin – alternative for native global variables

Alright so I asked the NWjs team for clarification via Twitter (as they reply pretty quick on tweets) and they replied:

No idea when and where was it announced... but it seems that the fix is indeed implemented in 0.19.1 (haven't tested on my end yet)

Let me explain.

The video recording issue was related to the flickering issue. It was reported to the Chromium team and fixed with Chromium 56.

The point is that there is no NW.js version based on Chromium 56 yet and that's why we still have to use --disable-direct-composition as a workaround.

I assume that the roundup states How To: Workaround Recording Issues & Canvas Flickering (NW.js v0.14.0rc1 - v0.19.0) just because in the time TheRealDannyyy wrote it, 0.19.0 was the latest version and we were all expecting new version to have Chromium 56 implemented. In other words it should be "... (NW.js v0.14.0rc1 - v0.19.2)" for today as Chromium 56 is still not there yet.

Interesting is that below it's written:

[quote:303zztnc](Fixed for all NW.js versions starting from 0.19.1, use the workaround only in NW.js versions from 0.14.0rc1 to 0.19.0!)

Latest NWjs still uses Chromium 55

Was it somehow fixes with 0.19.1 and I missed it or was it written due to expectation that the next version will have it fixed TheRealDannyyy?