interesting 32bit nw.js v0.19.2 crashing issue

Hi all,

We've hit an issue where latest nw.js v0.19.2 (Chromium 55) 32bit builds crash immediately as they boot up, but 64bit exports work perfectly.

This is not a huge issue with over 88% of Steam users now using 64bit OS, we are not against only releasing the 64bit version as we never see problems with that build. But it seems strange...

We're nearing the end of work on a BIG game made in C2 but as far as I understand assets are only loaded in for each layout, so having a huge number of assets shouldn't be the cause of hitting 32bit ram limits, should it?

Any thoughts on what could be causing this?

The game works fine when previewing through Chrome & Edge via C2 and Win64 bit export. Previewing nw.js via C2 (32bit version) and trying the 32bit export both crash immediately on start up.

Ashley is it possible to have the option to switch to a 64bit nw.js preview in C2?

I'd recommend filing a bug report if you think the problem is C2 or NW.js and not just your game running out of memory. But without a .capx or more information all I can do is wildly guess. I'd guess that your game is running out of memory. That's pretty common.

Hi all,

We've hit an issue where latest nw.js v0.19.2 (Chromium 55) 32bit builds crash immediately as they boot up, but 64bit exports work perfectly.

...

Do you have a lot of sounds in your game? Keep in mind that sounds will remain loaded into RAM regardless of the layout to layout un/loading.

(The community already worked out a plugin to unload audio from memory but it's currently in an experimental state, that's why we keep it private for now.)

Is it possible to have the option to switch to a 64bit nw.js preview in C2?

For the preview you could do a sneaky workaround by renaming the folders temporally, just don't forget to rename the folders back again when you do the exporting.

Ashley I haven't made a bug report, as you're right, it's a memory issue, it's the only thing that makes sense with 64-bit running perfectly and 32-bit crashing on start up.

TD is a VERY audio heavy game. Hours of audio, soundtrack and voice overs. So TheRealDannyyy is 100% spot on. (Thank you!) If I delete everything in the sound folder the 32-bit previews and exports work like a dream. No crashing.

Sounds remaining in RAM is the issue here.

Knowing this explains a lot. I mistakenly thought that audio was loaded per layout like graphic files. TheRealDannyyy Where can we join you in testing this plugin? We may be in a position to help with this fix, if needed.

Ashley is this an issue that could be addressed in a C2 update? Would a bug report help here? Reproducing should simply be a case of making a new project, filling the sounds folder with hours of audio files and attempting to run any 32-bit preview or export. If that would help, and this is considered a bug, I'm happy to throw a .capx like that together, let me know.

Any obvious workarounds or simple fixes I'm overlooking?

Do you have "preload sounds" enabled? Does it work better if you turn that off?

Knowing this explains a lot. I mistakenly thought that audio was loaded per layout like graphic files. TheRealDannyyy Where can we join you in testing this plugin? We may be in a position to help with this fix, if needed.

It's on the way, we just add some smaller things like unloading audio by name and optimize the code here and there.

I'll notify you using a tag here when we share the experimental plugin to public. (Probably going to create a topic on Sunday.)

There are currently some issues with the delay between event execution and the garbage collector, a lot of technical things but we'll try to explain it in a more simple fashion inside the topic. We also hope that Ashley will check it out and maybe put the unloading features inside the official audio plugin, if he's alright with how we handle things.

Big shoutout to — for taking care of creating this amazing plugin!

Do you have "preload sounds" enabled? Does it work better if you turn that off?

This is a great solution to at least get the game running but it won't stop the game from reaching the memory limit and crash as a result.

I believe memory issues with audio also were the reason why Klang only works on 64bit systems. (Not sure if he's found a workaround for it but I think it's still 64bit only.)

Anyway, I think it's time to address this major flaw of the audio engine and try to find a more effective workaround.

.@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.

Ashley and TheRealDannyyy Thank you for your thoughts and help. Really appreciated.

— I'll definitely log into the Discord server next week to say hi and happy to use TD as a test case for the new plug in. Thanks for all your hard work adding these features to C2!

Would be great to find a solution to this, hopefully unloading audio from memory will also make it into a future official plug in, as even in a 64-bit build it seems unnecessary to waste so much ram on audio that is only played once.

Turning off preloading sounds should help it start up (if it's enabled), but can indeed still crash if the game ultimately ends up loading every sound. However the main reason I asked was because the answer would help prove if it really is audio memory or something else. I've not seen this confirmed though - is it enabled?

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.

Ashley Tested and to confirm:

Turning off preload sound lets the 32-bit version of the game boot up perfectly. But crashes after 2 to 3 hours of gameplay.

Turning on preload sound makes the 32-bit version crash as soon as it starts up.

64-bit builds work either way.

Thanks, that confirms it's to do with audio memory management. I must point out turning the "preload sounds" option means you are explicitly telling C2 to load and decompress all sounds in to memory on startup, which if you use a lot of sounds, can be a very great deal. But the fact it doesn't release any and still ultimately crashes is a problem. I'll try and get audio unloading in the next build...

Thanks, that confirms it's to do with audio memory management. I must point out turning the "preload sounds" option means you are explicitly telling C2 to load and decompress all sounds in to memory on startup, which if you use a lot of sounds, can be a very great deal. But the fact it doesn't release any and still ultimately crashes is a problem. I'll try and get audio unloading in the next build...

We're about to release our version of the unloading audio feature, this could maybe make things easier on your end.

However nothing stops you from doing everything by yourself, looking forward to it either way.

Well here it is StaticCloud, I hope it fits your needs.

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

It would be awesome to see it as an official feature. TheRealDannyyy thank you for your hard work as well.