> Or just make global object with boo's. I am actually finding this much more comfortable then if I'd have to scan trough globals and locals.

>

Well, I must admit I do that as well. lol. In large projects its no good to use global variables. There are too many of them and no way to organize them. But I would like to use local variables. They are a bit more meaningful than saying set TempObject.TempBoolean to false

I must have around 600 global variables. With a good naming system, they are manageable.

Belated, but I wanted to say congrats on a great launch on iOS.

Keep it up!

I can't reproduce this in the latest Chrome version. Even switching between all the layouts very quickly for some time, memory usage in task manager is stable.

If it reproduces only in NW.js, it's probably because the version most people use is well over a year old now, so it might be a bug in the Chromium engine that was fixed some time ago. We have an NW.js update to 0.13.0-alpha5 in the works so hopefully that will make a difference.

Thanks, I'm still on Chrome 40 for the browser and only tested up to NW12.

Hopefully 0.13.0 alpha5 for C2 comes soon!

— NW 10.5

I'm looking forward to the new NW13 alpha 5 that Ashley is saying it's coming in the next C2 beta...

Because it seems we're destined to be stuck with NW10.5 forever.

Does Airscape still have random micro-stutters?

i only work in 64bits, never used the 32 version.

The only reason I've stuck with the 32 bit version so far is because Google messed up with Chromium vsync, so I've been using NW 10.5 which doesn't have a good 64 bit support. Now that I've found 10.5 has a memory leak, I've been using NW 12 to test. 32 bit is smoother than 64 bit version, I don't know why, but 64 bit janks quite badly after a short period of play. The 64 bit also uses more CPU than 32 bit version. :/

So either way currently it's unplayable after a short session, 32 bit suffers memory leak, 64 bit janks..

Hopefully NW 13 Alpha 5 fixes the Jank at least, so can use the 64 bit export.

Interestingly, 64 bit NW.Js does not seem to be affected, it caps out at around 1.4GB for me, unlike the 32bit NW.Js. The only downside is the 64 bit NW janks badly after awhile, micro-stutter... but no constantly increasing memory use or crashes.

Using NW12 64 bit now for a few hours already, will need to test more.

— - please file a bug report if there is too much memory use - the point of layout-by-layout loading is to keep the memory use down, so we want to make sure that is working.

I already dug more info on the issue, it's NW and Chromium related. Its a widely reported problem. I did not observe this behavior with IE or Safari.

This is why it sucks to have no explicit control over asset loading and unloading. Chromium does all the GC and its broken. Most people don't notice the issues because their projects are quite small, so the constant memory leak takes awhile to build up. Potentially many hours before its noticeable (stutter then crash).

But games tend to be much bigger than app, lots more assets, bigger games will reach the instability point much sooner, so play session is limited to an hour.

Quite difficult to tell people who buy your PC game, it has to be restarted every hour.

ps. Also, IE and especially Edge is an amazing fast browser nowadays. No vsync issues, butter smooth. NO memory leak issues, very stable. Can we please get a IE/Edge wrapper? :p I am so sick and tired of Chromium and all its constant plaguing issues leading to games that stutter even on powerful hardware, bloated memory use on mobiles and now memory leak on PC.

Update:

https://github.com/nwjs/nw.js/issues/3722

https://github.com/nwjs/nw.js/issues/2614

Apparently a well known problem in the NW.JS community. O_o

Still not fixed since forever. Jesus, we just can't get a break... bloody Google broke vsync for ages and then this. Forget about making large games, even for PC. gg

https://github.com/nwjs/nw.js/issues?ut ... emory+leak

What this means is that bigger C2 games can only be played in short sessions. After awhile the memory leak grows unstable, the first symptom is stutter in gameplay, that gets worse and worse. The smaller the game, the longer the play session, but all games suffer this problem.

This is literally C2-breaking for any export reliant on Chromium. The problem is worse for bigger games as the play session before issues arise can be ~1 hour.

Problem Description

This was posted awhile ago, it's still present and a problem for bigger games with lots of assets.

certain-memory-does-not-get-released-in-texture-allocation_t112725

The reason I am posting this again is because it is a major problem that still has not been resolved for over a year.

Attach a Capx

More info in above thread

Description of Capx

More info in the above thread

Steps to Reproduce Bug

• Make an empty layout with a few 2048 x 2048 empty sprites.
• Repeat with a few of such layouts.
• Switch between them.

Observed Result

Layout transitions increase the cache memory used in Chromium/NW.js, repeatedly rising until game stutters or system crash. Observe the nw.exe or chrome.exe using more and more memory.

This problem DOES NOT occur in IE.

Expected Result

No memory leak.

Affected Browsers

• Chrome: YES
• FireFox: N/A
• Internet Explorer: NO

Operating System and Service Pack

Win 7 64 SP1

Construct 2 Version ID

216

Sorry for posting in the closed topics,

I was about to submit a bug report, but searched first and this is the same bug.

I see this is an old bug and this behavior is exactly what I've seen in my game, and what I was talking about a few days ago.

Every layout transition, the nw.exe process keeps growing larger and larger (~3-4MB), beyond all the assets of game so there's some kind of duplication in memory going on for recent used/destroyed assets. Basically that process never reduces in memory use, only grows larger over time.

After around 1 hour of play, the process gets to around 1.5GB of memory and the game starts to stutter. A close and relaunch resolves the issue.

Tested on both Chrome, NW10.5 and NW12.

If people's games are large enough, after multiple layout transitions, it could blow up to beyond the 32 bit OS limit of ~3.4GB memory (the rest out of 4GB, reserved for OS) and the game crashes as Tinimations has encountered with Klang.

I suspect it is Chromium not releasing its cache as it should, under normal operations, it will release the cache once system ram limits are approached but it may not be functional for NW.JS/C2 usage.

Edit: Just tested in IE (Win 7 64 Enterprise). This behavior does NOT happen. The iexplorer.exe process caps out around 600MB, but it drops down lower based on the layout. It does not exhibit the ever rising memory usage issue. Destroying images will reduce the memory usage of the process according to the asset size. Thus, whatever is the problem is between C2 and NW.JS/Chromium.

Ashley

For my games, it has not crashed in my experience and its not a memory leak, I can increase the size of the "cache" nw.exe process just by adding more dummy un-used large sprites to an assets layout (never called). If its a 2048 x 2048 sprite, the cache increase by 16MB so I know its actually loading all the asset from disk into cache.

This is problematic under 2 scenario:

1. Very large games, can indeed overwhelm the 32bit OS restriction on 4GB total memory and crash. Klang's dev have reported this, so the game will only work on 64 bit OS. It's not that his layout is that big or complex, the game layout itself doesn't use much but all the assets (big game, high fidelity assets) in cache uses a lot of memory. This was due to the expectation that C2 has functional layout-by-layout memory management (which it does) but we didn't know about Chromium caching everything up to a few weeks ago.

2. Android does this with Crosswalk, I've seen this behavior myself. Games have a very large memory footprint if there's lots of assets due to shared vram & system ram, so there's assets of the current layout in system ram, there's assets in vram, then there's assets being held in cache by chromium, all in the same system ram pool. It does end up crashing quite soon due to these devices using so much memory for background tasks, when we have well designed layouts to fit <200mb. This means bigger games with lots of smaller layouts is still a no-go. I haven't tested on Safari & iOS to see if it behaves like Chromium, but I suspect not since I never saw such skyrocketing memory use of my own games on iOS as compared to Android.

I know this isn't on your end, it's a Chromium/NW.js thing, but other devs should know to avoid making that huge epic game thinking its gonna be okay as long as they get clever on layout management.

Another reason why I hate Android:

Also all the crap devices that have so many weird hardware configs that can't run your app well? "1 Star cos it crashes".

> Also I've learned about how NW export games load all the layouts into memory and never free any of it

>

That's not true, layout-by-layout loading frees images when you change layouts, so it only ever has one layout loaded.

This may be true for Construct 2, but the wrappers do NOT behave that way.

NW.js for example has a memory cache nw.exe alongside the main nw.exe, it stores any recently accessed asset into that cache and never lets them go until the entire process is ended (exit game).

This means if the game has 900MB of images/sprites in memory format, that cache will be ~900MB, even on a minimal main title screen layout.

So while you change layout and C2 behaves correctly (dumping the current stuff from memory), Chromium (NW and Chrome) does not. Try it and you will see. Just make a blank layout, throw a lot of 2048 x 2048 single color sprites onto a layout that you never call (Assets Layout) while loading a blank layout at the start. You'll see the processes I am referring to, with one bloated up by however many ~16MB 2048 x 2048 textures you added.

I know Chromium also behave this way on Android Chrome and Crosswalk, so bigger games will eventually eat up a lot of memory on the cache process.

C2 clearing seem to affect GPU VRAM, so layout changes flushes that out correctly, but it doesn't affect the way Chromium handles cache (loading asset from disk to system memory). This is from monitoring GPU vram with Afterburner and different layout transitions. GPU VRAM is behaving correctly but system ram is never released.