corlenbelspar's Forum Posts

  • Apparently it was the max-height setting in the layout files being set to some ridiculous numbers like 40000 tiles and there's no way to change that unless you go into the files themselves with something like Notepad++. So I used regex find and replace to set the max-height to 14 rather than 40000 because none of my tilemaps ever are anything but 14 tiles high. Now the memory usage is 200mb. Maybe in the future you should consider making Construct 3 alter the max-width and max-height settings on the tilemaps to whatever size the tilemaps actually are?

  • That's only 1,792 tiles so it shouldn't be an issue.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads
  • My project doesn't use a tilemap that big. I made the tilemap to exaggerate the issue so you could actually notice it. None of my tilemaps exceed 2048x224 pixels.

  • And all the layouts have multiple tilemaps, but none of them exceed 2048x224 pixels.

  • No I meant I pasted a set of two tiles by two tiles. The tiles are 16x16px.

  • Here's the information you requested VS the debugger's memory use. I tried experimenting and it seems the last few layouts I made increase the memory usage by 500mb purely by existing whether I have them open or not. I then tried to make a giant 25600X22400 tilemap object with one tile repeated through the whole tilemap object with the fill tool and then a 2x2 set of tiles repeated and the memory usage shot up like crazy. I'll try to make a bare bones C3P file that demonstrates this and report it, but I still don't even know if this is actual underlying cause or just a symptom of something I'm doing.

    EDIT: Well the image I tried to insert didn't even show, so here I edited it just to link to the image in my Drive.

    https://drive.google.com/open?id=1JK6x-0qp-675uioZTUm5iJpkNCABC22a

  • I don't want to post my entire C3P file for the whole world to see and possibly steal because my game has a minorly significant following at this point. I don't know how to recreate the issue with a minimal C3P file. I guess I'll just hope for the best that this gets fixed purely by chance or take my business elsewhere.

  • Ashley can I give you my C3P file so you can figure out why it's using three million terabytes of RAM for such a simple game where it has an out of memory error when I try to do anything, despite it's the 64bit version, and tell me if I just messed up or if there's a legit memory leak in C3?

  • If you run in to a bug or issue in Construct 3, please post it to the GitHub issue tracker here:

    https://github.com/Scirra/Construct-3-bugs

    You must follow the bug report guidelines or your issue will be closed without investigation.

    I don't know if it's a bug or if I'm just doing something wrong.

  • It's Construct 3's editor itself that is using up this memory and causing this issue.

  • I'm up to 3gb memory usage in the NWjs version of C3 and when I try to save my project, it just crashes after freezing for a bit. My game is an NES style game, so I don't get why my project takes 3gb of memory.

  • Currently enabling worker and running a preview slows down the preview loading considerably where it takes about 15 seconds to start, as opposed to loading within a second or two when worker is disabled.

    I've noticed big performance increases by using worker, so my question was is the drawn out preview loading time going to be fixed in a future release of C3?

    EDIT: It seems the AJAX plugin is still causing issues with worker. I deleted it and then the preview started up like it should.

  • I was wondering if there was a way I can grab the color values of a pixel in an object and use them in something like the rgbex expression.

  • You do not have permission to view this post

  • I did what you did but created drawing canvases instead and pasted the object in question into it and it worked exactly how I was shooting for. Thanks for the example to point me in the right direction.