TheRealDannyyy Thank you for this, very helpful! Hopefully, will find it`s way into an official update too.

Out of interest how does memory management / garbage collection of video work? - is it like image files with automatic garbage collection on layout change or more like audio? Could we further save ram use by unloading video from ram after viewing?

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.

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.

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?

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?

Tinimations excellent news. Really Looking forward Klang. I've sent you a PM.

Thinking it through, limiting caching would cause problems with saving, so probably not the right way to go. There must be a better way to create an 'uninstaller' for Steam to direct it to the \users\ directory.

edit:

So a follow up, I've experimented. I've not had any luck with: --disk-cache-size=1 --media-cache-size=1 --incognito I'm Seeing no difference in cache size at all adding these.

But --user-data-dir='temp/' is making the cache either move... somewhere... or not creating the cache.

edit2:

--user-data-dir='temp/' moves the cache to the root folder of your game (wherever it's installed), in a folder named temp. This might work? As the whole game will be in one folder. But this might cause permission problems?

Hello, that's a panic inducing error message so close to launch!

We've got the same caching issue. Here are a couple of links that look like they might have possible solutions:

This is about chromes cache location & size: http://www.ghacks.net/2010/10/19/how-to ... -and-size/

This thread on nw.js covers growing cache problems. https://github.com/nwjs/nw.js/issues/4695

Looks like we should be able to set caching to preferences and fix this by adding to package.json

The example on the nw,js thread is : "chromium-args": "--user-data-dir='temp/' --disk-cache-size=1 --media-cache-size=1 --incognito"

This is definitely an issue that affects everyone creating Steam games using C2, so would love to hear a follow up on this.

We've seen exactly this flickering problem too. We rolled back to earlier version (pre 0.14.0) of nw.js to export our Gamescom build, and it worked fine. It seems to be a Chromium issue, not nw.js. Looks like it's this problem reported to Roger Wang (nw.js) here: https://github.com/nwjs/nw.js/issues/4947 and he's stated it's upstream (Chromium) and closed the report.

But finding the C2 Audio object might be causing it is really interesting and quite strange. — Can you make a bug report with example capx showing that the audio object is causing it?

We solved all our Mac export problems by following these steps:

Use Construct r216 for Mac export nw.js 0.10.5 "--file-descriptor-limit<10000>" and "--ignore-gpu-blacklist" arguments added to package.json No transparent PNGs in the game

in runtime.js after export (non minified)

replace:

img_.onerror = function (e)

{

img_.c2error = true;

anyImageHadError = true;

if (console && console.error)

console.error("Error loading image '" + img_.src + "': ", e);

};

if (this.isEjecta)

with:

img_.onerror = function (e)

{

if(img_.try===3){

img_.c2error = true;

anyImageHadError = true;

if (console && console.error)

console.error("Error loading image '" + img_.src + "': ", e);

} else {

img_.src='';

if(img_.try===undefined) img_.try=0;

setTimeout(function(){

img_.try++;

img_.src=src_;

},50);

}

};

if (this.isEjecta)

Read these threads for more info:

—

Thanks for info.

So currently to get a Mac build working semi-reliably we need:

Construct r216 nw.js 0.10.5 "--file-descriptor-limit<10000>" and "--ignore-gpu-blacklist" arguments added to package.json No transparent PNGs in the game

And even then it sometimes randomly decides to red bar and suffers from a memory leak.... Ouch.

This really needs to be solved.

Update.

Found this incredibly useful thread by Aurel : how-to-node-webkit-for-linux-and-mac-2015_t127201

Was able to download nw10.5 osx32 from there. (If 10.5 is the only working nw export for large projects on Macs a link on this page https://www.scirra.com/nwjs with a note would be useful.)

nw10.5 seems to work much better with "--file-descriptor-limit<10000>" and "--ignore-gpu-blacklist" arguments added to package.json.

Though game still fails to start around one in three times - Red bar.

This solution could work fixed-the-red-mac-loading-bar-for-my-game_t165327

But there is no runtime.js in the nw10.5 osx32 export as in the instructions. mapmerry could you share some more details on this. the only runtime.js file I can find is in the construct folder and that would need to be changed pre export.

I have looked though and added a pixel / switched invisible to any fully transparent PNGs in the game. Using 10.5 with arguments. It's better, but still often failing to start.