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

  • Tinimations are you using one layout for all your levels? if you start the layout and delete a bunch of objects that you potentially never use, maybe they should be on a dummy layout.. that way you never load anything except what you are using..

    everything in the Layout view is loaded into memory and never released on a given layout. It's only released when you go to a new layout.

  • When I make an empty canvas and boot up the game, something is seriously wrong when the memory use is 1.5 gb.

    what do mean by empty canvas? do mean a brand new project with nothing in it? or your game template with nothing happening?

  • Try Construct 3

    Develop games in your browser. Powerful, performant & highly capable.

    Try Now Construct 3 users don't see these ads
  • jobel An empty layout in the game without any art, sound or events. One of NW.js processes uses minimal ram here, but there's always one process (which I guess is cache) uses roughly 1.5 gb even in an empty layout.

  • An empty layout in the game without any art, sound or events. One of NW.js processes uses minimal ram here, but there's always one process (which I guess is cache) uses roughly 1.5 gb even in an empty layout.

    There's two nw.exe process, the smaller one is your current game/layout.

    There's a second process of nw.exe that loads all your assets as they appear in your layouts. It acts as a cache I think. The more layouts you change, or more sprites you call in, the bigger the cache becomes. Once it maxes out (loaded everything available in your game), it doesn't grow.

    I'm not sure what would happen if there's not enough system ram for the cache to grow since my PCs have 12-16GB ram and my game tops out around 700mb. If yours top out at 4GB for the full game, I don't think you need to worry for PC/MAC as most low end systems have 4-8GB memory.

    If I had to guess what happens when you don't have enough memory for caching, it would load from your disk, causing major stutters as big sprites with animations are called in.

    Maybe Ashley can verify or explain the inner workings of this process.

  • 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

    EDIT: oh I see, an empty layout in *your* game....and you load that first when checking? what do you have for globals? do you use any global layers? or global objects?

  • 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 ?

Jump to:
Active Users
There are 2 visitors browsing this topic (0 users and 2 guests)