[Feature Request] It's Time To Polish NW.js Exporting

Quick Introduction:

Some of you might already know me as the annoying "critical" guy from my previous complaints about some of C2's mechanics.

The Reason Behind This Post:

I believe that the majority of C2 developers that export their games to desktop already know

or currently have to deal with the following problem: Extremely long exporting times.

Especially users with an AMD CPU seem to suffer from this issue, based on comparisons on my end.

Reproduction + Cause Of The Problem:

From my previous tests with exporting a fairly large game with NWjs, I could clearly identify the "packaging" as

the cause for the long exporting times.

Possible Solution:

I'm not an expert and just have some minor background information about the whole exporting process.

However my guess would be that packaging for each platform, might not be the best method to export NWjs games.

Based on this conclusion my suggestion would be to "polish" the exporting window and add additional options

to separately export your project. (Windows [32/64 bit] | Linux [32/64 bit] | OSX [64 bit])

Some Last Words:

We all know that you are a busy man Ashley and we surely appreciate that you didn't abandon C2 and still provide us

with monthly maintenance updates. If there are any problems that are stopping you from adding this suggestion,

feel free to inform us about them. I hope you understand that quickly exporting with NWjs is an important feature

for the most of us because plugins such as Greenworks or MadSpy 's Steam4C2, only fully function that way.

The package.nw files are the same in each export folder and do not take up any extra resource to be compiled (beyond the small time taken to copy/paste the NWjs folders from the NWjsForC2 folder...).

Have you tried exporting and not selecting image compression and script minify?

To make the export almost instant (ie like preview) then we would need an option to prevent sprite sheet creation for the export - but then your tests would not produce representative performance results because of their lack of use of sprite sheets.

The package.nw files are the same in each export folder and do not take up any extra resource to be compiled (beyond the small time taken to copy/paste the NWjs folders from the NWjsForC2 folder...).

Have you tried exporting and not selecting image compression and script minify?

To make the export almost instant (ie like preview) then we would need an option to prevent sprite sheet creation for the export - but then your tests would not produce representative performance results because of their lack of use of sprite sheets.

I never minify scripts because it tends to break custom plugins. I also use the default for image compression (PNG 32).

Despite the fact that the spritesheeting takes a while, I can confirm that the packaging is the cause of the problem on my end.

Even my laptop exports faster than my PC at this point, which seems to be caused by the AMD CPU.

Anyway, I wouldn't like to consider issues on my end as an excuse for not having this feature.

Image count has a huge impact on preview and export times

Probably won't see any improvement here until C3

Don't buy anything from AMD

Stencyl's preview/export times are significantly longer. I am quite alright with C2's after learning this.

S'all I got.

I would like to see NW.js build options though. I don't care if 4 different builds take the same amount of time to process; it's really annoying having to delete a bunch of them and rename folders every single time.

>Image count has a huge impact on preview and export times

>Probably won't see any improvement here until C3

>Don't buy anything from AMD ...

Yeah, this is the first and last AMD product that I'll ever buy, at least my heating costs are at an all time low (I'm not even joking about this ).

Nobody knows what will happen with C3 and if we will see any major improvements.

Judging by the current information we got, it doesn't look well for the exporting side of things.

Anyway, I don't want this topic to turn into a discussion about C3 and it's possible features.

Nobody knows what will happen with C3 and if we will see any major improvements.

Judging by the current information we got, it doesn't look well for the exporting side of things.

Anyway, I don't want this topic to turn into a discussion about C3 and it's possible features.

Ashley confirmed in-editor spritesheeting for C3, which should boost preview & export times considerably.

It's kinda hard not to mention C3 when it comes to new features and even improvements to existing features. C2's all light maintenance and bug fixes now.

Also I made a very similar thread a long time ago. Ashley's response was just this.

>

> Nobody knows what will happen with C3 and if we will see any major improvements.

> Judging by the current information we got, it doesn't look well for the exporting side of things.

> Anyway, I don't want this topic to turn into a discussion about C3 and it's possible features.

>

Ashley confirmed in-editor spritesheeting for C3, which should boost preview & export times considerably.

It's kinda hard not to mention C3 when it comes to new features and even improvements to existing features. C2's all light maintenance and bug fixes now.

Also I made a very similar thread a long time ago. Ashley's response was just this.

Where did he confirm that, was it inside a post on the forums? Please send me a link if possible, that sounds great.

Where did he confirm that, was it inside a post on the forums? Please send me a link if possible, that's sounds great.

In these threads Ashley talks about in-editor spritesheeting being a goal for C3, and it requiring architectural changes that won't happen in C2. This was all regarding preview times but it affects export as well.

I don't mean to speak for him nor say this is the ultimate solution to faster export times, but to my knowledge this will help a lot and is probably all we can expect for a while.

Just curious, how long does it take OP to export his game into nwjs?

It take me less than several minutes to export mine as reference and I have zero issues with the process.

I would like to see NW.js build options though. I don't care if 4 different builds take the same amount of time to process; it's really annoying having to delete a bunch of them and rename folders every single time.

Agreed. I +1 this request. Most of the time during development we don't need all the possible exports NW.js can do. If it could be customized that would be great. It's more of an annoyance on most computers to just delete the unnecessary files, but on a notebook with a 128/256GB SSD only, exporting big projects with NW.js can affect more seriously the remaining free space on the drive.

Just curious, how long does it take OP to export his game into nwjs?

It take me less than several minutes to export mine as reference and I have zero issues with the process.

On my PC and laptop the spritesheeting process takes about the same time: 15-20 minutes.

However after optimizing it and temporally removing all my Full-HD art it got reduced to: 5-10 minutes.

The Packaging mostly takes up to 30 minutes on my PC, and a lot less on my laptop.

Don't get me wrong, exporting time is still acceptable. It just gets annoying when I have to test

out events with Steam4C2 (I assume it would be the same with Greenworks), which don't work in preview.

In these threads Ashley talks about in-editor spritesheeting being a goal for C3, and it requiring architectural changes that won't happen in C2. This was all regarding preview times but it affects export as well. ...

Thanks, I either missed it or forgot about it.

Alright guys this is ridculous...

I thought for the sakes of testing Steam4C2 within the Linux & OSK builds, I should downgrade to NWjs v0.14.0.

Now to the ridiculous part, my packaging time got reduced to ~2 minutes.

So either the NWjs team did something terribly wrong in 0.16.0 or it is C2's fault.

I don't want to pass the blame to someone specific but one of them did something wrong for sure.

The NW.js exporters could indeed be a lot better. Adding the steam dlls and the txt to every one of the builds is annoying and time consuming when testing. I know Scirra can't just distribute the dlls but I'd love if I could point my steamworks folder to Construct 2, so it could get the dlls from there and use the in the exported games. Also the appid txt file.

The NW.js exporters could indeed be a lot better. Adding the steam dlls and the txt to every one of the builds is annoying and time consuming when testing. I know Scirra can't just distribute the dlls but I'd love if I could point my steamworks folder to Construct 2, so it could get the dlls from there and use the in the exported games. Also the appid txt file.

It would be nice if we could set up a folder in the export window for files like this and during packaging, C2 would copy it's content to the exported folder automatically.

> The NW.js exporters could indeed be a lot better. Adding the steam dlls and the txt to every one of the builds is annoying and time consuming when testing. I know Scirra can't just distribute the dlls but I'd love if I could point my steamworks folder to Construct 2, so it could get the dlls from there and use the in the exported games. Also the appid txt file.

>

It would be nice if we could set up a folder in the export window for files like this and during packaging, C2 would copy it's content to the exported folder automatically.

I thought you could it already by just dumping whatever you want in NWjsForC2 win32 folder or any folder inside.

Anytime you export the NWJS version, anything inside will be included in the final release.

Including the folder and files setup you made beforehand.