NW.js v0.12.0 (Chromium 41) 5th March, Discussion

Tinimations that can't be right. My entire game has 3 processes running and doesn't equal more than 300MB

32-bit NW 10.5

I use 32-bit NW 10.5 too. I would guess all of my assets if loaded would take around 700-800MB. That is what I get after playing awhile, the 2nd processes (biggest) reaches ~700MB.

That is what I get after playing awhile, the 2nd processes (biggest) reaches ~700MB.

oh I didn't play it at all, I just went to the game's menu and checked the mem... good to know that it grows though... doesn't sound like that's Tinimations problem since 1.5GB is happening on an empty layout...way beyond what we are seeing... there must be globals. Mem is only loaded with the current layout objects...

a separate and somewhat disturbing issue is why that second process grows? so NW forces this caching which negates any benefit the current "Layouts-only-load-into-memory-what-is-needed and frees it when going to a new layout" architecture?

> That is what I get after playing awhile, the 2nd processes (biggest) reaches ~700MB.

>

a separate and somewhat disturbing issue is why that second process grows? so NW forces this caching which negates any benefit the current "Layouts-only-load-into-memory-what-is-needed and frees it when going to a new layout" architecture?

Well the benefit would be quicker asset spawning on new layouts, rather than reading the file from disk, it reads it from the cache memory. RAM is about 20x faster than even SSDs (but despite that, memory access is still latency bound, around 1 frame's worth for random access).

I would think if there's insufficient memory for the cache, it would therefore load from disk. If its on a mechanical drive, there would be a very visible stutter. Or big animated sprites, even from SSD, would stutter.

It's a "good" behavior since it does not allow us explicit control over asset loading & unloading, so it stores it in the cache, as non-vital memory usage, if there's memory available.

— Oh that makes a lot of sense actually. But well the caching is a problem since I have experienced cases (mostly on windows 8) where the 32 bit version crashes due to the cache becoming too big. If one could set some kind of limit to it (Like clean itself completely after reaching 1gb or by command when returning to a certain layout like a dedicated loading screen) I would be fine with it. Currently though it works as a very effective way to restrict me from making the game I want to, even if the individual layouts ain't that big.

If manually making sure every asset needed for a layout is loaded in at any given time is all it takes to negate the need for the caching, it's a small price to pay considering the massive caching issue. It will make the game unable to run on a lot of machines, and there's stil stuttering when loading assets even from ram.

jobel Yes this was on booting up in an empty layout in Klang. Though I will also add this 1.5gb memory thing was in Firefox preview. I didn't test the empty layout case in node webkit. The growing cache problem however is still very much a NW problem.

Tinimations

Does it crash on 64 bit NW?

Last time I had a discussion with Ashley about explicit asset control, ie. loading/unloading on command to get fine-tune control over memory usage, he said he doesn't think its a good idea to give C2 users that power, because the potential there for people to "not know what they are doing" and mess it up real bad.

The current system works fine for most games, since we rarely have so much animated assets of high resolution to use ~4GB of memory (saturating 32bit). Your game is obviously an outlier.

It would be very useful to have explicit memory control regardless, more tools = good for power users.

— No the 64 bit version doesn't crash, but stuttering shows itself sooner. While I get Ashleys concern for beginners. It's essentially admitting that professionals or ambitious devs should never use C2...

The 4gb thing happened on Windows 8. Where on the computer I tested on used twice the amount of memory, which instantly crashed the 32 bit version. on NW 0.12 the cache appears to not grow much past 2gb (even the 32 bit version doesn't crash on this version), but the stuttering shows itself after roughly 50 minutes of play on avarage. Even on my gtx 970, 32gb and latest i7 CPU setup.

Tinimations yeah we're all in the same boat with larger scale games in C2... we just need to make compromises where ever we can to make it work. I think that mindset is best. It's our own fault or inexperience for not benchmark testing C2 in the first place. There's no excuse to only find limitations late in the dev process and be unsatisfied with them.

Live and learn is all you can do... will I make a game this large again in C2? probably not. Doesn't mean I won't use C2 for smaller stuff...

Is there anything you can think of (like outside the box) that would be kinda crazy but allow your game to perform better? like overall game resolution?-I know that's drastic.. but maybe there's something that can be done if you entertain off-the-wall thinking. Better that than release a game with serious hardware limitations...

Hmm interesting. I did some more tests on Windows 10 with the exact same build. And the memory caching is greatly reduced. Now the total memory use is closer to 1gb, where it previously was 2,5gb. Getting the feeling I'm barking at the wrong tree when whining at the construct forums...

I didn't play long enough to potentially trigger the stuttering, but from what I could tell it ran butter smooth.

Tinimations

Interesting why it behaves wildly different on Win 7/8 vs 10.. it's still Chromium underneath NW.

And yes, this isn't a C2 issue but Chromium, however, we still rely on it for our export.

NW.js v0.13.0-alpha5 is out, why not work on c2 ?

If you keep a track of Ashleys twitter, he has said the next beta includes a new NW.js.