acceptable memory usage?

0 favourites
  • 14 posts
From the Asset Store
Memory game, with 10 levels for you to have fun. Made in Construct3, template available for purchase.
  • What's an acceptable memory usage for a desktop game? I'm currently at around 35mb but i only have in around half the images the game will require.

    I can probably still do some optimising but i'd like to know a realistic figure to stick to.

    CPU is at about 8% and the game runs 60fps.

  • You would almost never need to worry about memory usage for desktop games, with WebGL in C2 being very good with memory management, I doubt you will ever have over 2GB of assets on screen.

    Most desktops have 4GB of ram, many have 8GB.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads
  • Ethan - Actually I believe it doesn't use your typical memory ram; it uses vram. Once you get to ~150mbs or so you will notice a small "stutter" on the start of the layout. I have a bit of a super computer so I haven't figured out what's considered too much, but you probably don't want to go any higher than the 100-150 mb range.

  • The entire game is stored (uncompressed?) in RAM, the current layout is also stored in VRAM (Video RAM of the graphic card). VRAM is usually much smaller than your computer's RAM, some people may have 4gb of VRAM others may have 512mb.

  • [quote:32sz2bxl]The entire game is stored (uncompressed?) in RAM

    1) Audio files are not supposed to be loaded into memory ahead of preload/play call

    2) Audio files can be read "by name", so - by design - the game has no way to figure out in advance which files it would need to load. It actually works flawlessly, as I produced a game with 300Mb+ audio assets loaded this way

    3) On a desktop game (NodeWebkit) the delay you might be experiencing upon startup, is caused by unpacking on the fly the contents of the zip file with game assets. Try unpacking the whole stuff to the app folder, delete package.nw, and compare the startup time - you'll be surprised

  • VRAM you wouldn't even need to worry, most dedicated GPUs now have 1GB and thats plenty for storing onscreen objects. Intergrated GPU like on Intel or AMD APUs use system ram for vram so thats even less of a concern.

    Go ahead and do your best.

  • <100mb memory usage will likely run on any desktop and even some high end mobiles.

    If you're over 250mb of memory usage, I'd say you're doing something wrong with the design of your game.

  • Ashley - all you need is one large image with an animation and you'r'e already there

  • ome6a1717 - that is exactly what you should not do. See Remember not to waste your memory

  • Ashley

    If you scroll to 1:00 or so, how would we do something like this, then? (and btw, this is an example from the game you referenced in the "remember not to waste your memory" blog)

  • ome6a1717 - definitely using Spriter, certainly not with frame-by-frame animations.

  • ome6a1717

    More specifically this is how they do it (UbiArt Framework):

    Subscribe to Construct videos now

    If you're interested in something similar for Construct 2, try Spriter since it has C2 integration.


  • Ashley


    Perfect. I will have to do some research. Thanks!

  • I ran into this problem recently myself.. had my project up to 750 MB. It builds up a complex, but static, image using really big (600x600) stacked layers, each with one sprite on it.

    What I did was instead of having every possible image be a different animation, and thus always be loaded into video memory, each part of the image had 1 frame that was loaded from the server (via Load Image from URL) when needed. I wrote a preloader (actually, a PHP script that generates a preloader, but I digress...) that I plugged into the index.html that Construct 2 generates when you export your project and now it still works just fine but only uses 35 MB of video memory.

    So.. the moral I guess is if you're using too much memory there's ways you can work around it. Most laptops and desktops won't really care until you get up over 500 MB. I haven't done anything for mobile yet but I know they have a lot less RAM in general.. you need to think about memory management from the beginning.

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