Construct Games have very high RAM usage on Steam Deck

Discovered that turning off Pre-Load sounds in the Project Properties cuts 20% of RAM use. I also discovered that running the game on a Linux device doesn't have RAM issues. Only SteamDeck. And from what I can tell, the SteamDeck RAM use is doubling what its suppose to be.

Edit: I received a message from a Linux user explaining that it indeed does eat a lot of RAM. Read the comment below for further details.

Does it use that much memory on other platforms? If not, it's probably the Steam Deck using all that memory, not Construct, so it would be best to contact Valve for support.

A post was made on our Steam page that mentions this issue on their Linux. I've added a screenshot of what they wrote. It seems really interesting. Does this ring any bells for you?

Allocating virtual memory is not the same thing as actually using memory, so if the only thing we know is it allocates lots of virtual memory, that does not in itself mean there is any problem.

Here is a report from someone who uses Ubuntu 22.04.1 that the game uses over 6GB of RAM similar to SteamDeck when on the main menu before starting the game. That's when it jumps to 8GB. (Reminder that the game uses around 2GB of RAM in the menu and jumps to 4 while in-game on PC) This feels like it's confirming the idea that the RAM usage doubles for some reason.

-> Ubunto Specs <-

Unsure if giving the specs will help but I figured I would throw it in just in case. Do you think this is an NW.js issue?

Do you know exactly what type of measurement you're looking at when you say Linux is using lots of memory? Accounting for memory usage is actually a lot more complicated than you might think. For example in Task Manager, Windows splits memory usage in to the categories "In use", "In use (compressed)", "Modified", "Standby" and "Free", with further measurements for "committed", "paged pool", and "non-paged pool". The concept of "total memory use" depends on which of these categories you include. For example in Windows the "standby" category is used in the sense there is lots of potentially useful cached data and code stored in memory which can help optimize the use of the system; however if an application suddenly demanded lots more memory, it can generally just release all that memory and give it to the application. So it's not used in the sense it blocks other applications from allocating memory. On my system memory is 41% full if you count just "In use", but 92% full if you count both "In use" and "Standby"; only about 7% is actually categorised as "Free". So the measurements can be wildly different depending on what is being counted, and the meaning of the result is significantly different too: 92% in use might be a problem, but 92% in use and standby is not a problem, because 51% of that memory is still actually available to applications should they need it.

Ashley

Yeah I agree. I know it is not Constructs fault. I personally believe it's NWjs. I saw that you all are shifting focus towards Webview 2. I am hopeful that when you get it working/compatible with Steam that that will resolve a lot of issues that NWjs runs into.

I truly think you should take advantage of our situation because I believe what we have achieved with BioGun is something that I have not personaly seen with any other game made with Construct. A massive game that is comparable to Hollow Knight in terms of content and quality that was fully made in Construct 3 without the use of 3rd party plugins except for the Spriter plug-in. All running on the native exporting features of Construct 3. Not ported unlike the many other successful Construct games such as (Mighty Goose, The Last Penelope, CyberShadow). As of now it is clear to us that the best way to go about making games with Construct is to keep them small (due to browser memory limits which we are dealing with sadly. Engine crashes very often (out of memory error) because of how large the project is, and that there is a need to port Construct 3 games to another coding language due to the limitations of javascript. Temp file creation is also an unexpected issue with games made with Construct. Players have reported over 10gigs of temp files get created over a 20 hour total play session. As a C3 dev, we have no way to mitigate this issue that I am aware of unless you know of a way? There is also the issue of the games running on NWjs so devices with dual graphics card often offload NWjs games to the onboard card which creates a perception that the game is horribly optimized which isn't the case and sadly there isn't an option around this issue besides having to respond to the negative reviews or posts about it.

There are many other pressing issues I can go over but please don't take this post as an attack. I am here to inform you and the team of the many issues we've faced so that maybe in the future you and your team are able to find work arounds when they become available.

It has been an incredible experience making a game in Construct 3 as I truly believe its one of the better engines out their for onboarding someone new to making games and I absolutely adore the process of how you make games in C3. Keep up the hard work!