I got a program called FreeRAM and it seems to do excellent in removing that excess RAM. It could be a temporary solution, I guess.

I probably shouldn't be clogging up this thread with my problems, though.

EDIT: I just managed to get the error anyway trying to start the game now, so I am majorly confused. Is it VRAM? It's definitely a Construct prompt at this point.

I do indeed have thousands of events, and then add conditions to that. It doesn't matter the amount of open tabs.

My game (it's The Iconoclasts, if it matters) isn't one that can rely on reusable code all the time as it constantly adds new aspects, bosses are really intricate, no two events are the same and there are many active cutscenes, which will create many, many events. The project scale wouldn't be overshooting anything if this leak didn't happen, and it's basically the final hurdle I think I can expect before Construct is near perfect for this game.

I haven't counted all the events in the game, but just the sheet which has all the cutscene scripting has 1400 or so. Parts of the game could probably be scripted with external files, but hardly enough. I already have some cutscene scripting external, within the dialog files I keep.

I just hope someone will get around to it at some point, somehow. I wish I could recoup anyone who did, too. :(

Actually, I just tried removing all sprites from the project and saving, and it still adds 30-40 megabytes.

But then I removed all event sheets (leaving three tied to layouts) and it only adds about 3 megabytes.

So yeah, I was wrong. This seems to be completely due to your event count. I take it what happens is I open, for example, my sprite layout, making it load all sprites as well as the events. When I close it it empties out the RAm for sprites but not the events. When I save it somehow re-adds the events to RAM and doesn't take it away.

It's curious though, since it still adds 30-40 megabytes when I removed all sprites, because that makes almost all conditions disappear! So to me it just seems to hate event counts?

EDIT: Just made an empty CAP with nothing but 7500 "Always" events and it leaks 8 megabytes every save.

Okay, here are some numbers, though they are very random:

• I have 8GB RAM, 4069 VRAM. My game is very big at this point indeed. But I also have 8GBs of RAM so it's not a matter of adding even 8 more because the error occurs often enough for it still to happen a couple times a day, maybe.

• Saving adds 30-40 megabytes to the used RAM.

• Previewing adds 2-5 megabytes.

• Just opening a layout that "stores" a lot of sprites randomly adds 10-50 megabytes. When closed removes only some of that.

• Opening some event sheets will leave about 1 megabyte after having closed it again.

Basically everything I do will leak memory, saving being the most consistently bad culprit. I'm still convinced this concerns the loading and reloading of sprites, as Arima seems to think too. Opening an event sheet might just load some, opening a layout would load all in the layout again, and saving would go through everything in the .CAP. Compiling turns out to be the most lenient because of when Ashley added Construct remembering if you compiled the same game already (without art changes).

During gameplay I basically have all art loaded because it's all small pixel art, and it has never loaded more than 40Mb into VRAM at once.

The latest version of Construct doesn't change any of this. As Arima points out, there has been memory issues with sprite loading before. I remember I would spread sprites across layouts to not load too many every time I opened the expression editor back then.

I hope this can shed some light on it... I really want this alleviated. :(

EDIT: And no, the error prompt says nothing other than "Out of memory".

EDIT 2: All of these examples add more memory than it ends up leaking as you do it. Like, while saving the RAM use shoots up quite far, then leaks about 60% of that.

In my experience, these are the factors:

• Mainly it seems to amass from compiling. After a while I will get an "Out of memory" message and the game can't start. It also messes up Construct visually and functionally. I may not be able to save. Can also crash Construct instantly.

• The same can happen from working with animations. As I alter frames and go back to the animation editor to pick a new one it can eventually create the same visual errors, but most often an instant crash of Construct.

• Simply saving can create the issue afterward, and rarely during, making the save not happen (no corruption as of yet). Usually causes an instant crash, I think.

Seems to me to have to do with reloading the textures used in a project over and over. Compiling would deal with textures, going between the animation editor several times reloads animation frames (watching how Construct acts it seemingly reloads everything after you finish in that editor) and I assume saving deals with the textures somehow too.

I don't know the exact workings of Construct, but visually it seems to imply reloading sprites in a project quite frequently, so that probably feeds the leak quickly?

Thanks for showing an interest in my problem!

Hey, Lucid, what would be the result of the memory leak the changelog claims you fixed regarding resizing client windows?

Based on my post higher above, my game does resize the client window and such, and I'm trying to figure out of this version could help. It's probably not it as I seem able to get my "out of memory" bug from doing other things than compiling, but I can't know if I'm simply hitting a memory limit doing those things after several compiles, since I'm nowhere near a C programmer. <img src="smileys/smiley1.gif" border="0" align="middle" />

Great work!

I just want to ask what the "Ceil" fix means? Sounds like you removed the only use of it, which is to round up? I'm probably confused.

Also, if you kind souls do make another version, my only remaining gripes are with a memory leak that seems to have to do with textures. If I mess with animations for a while, or simply compile the game over and over, the program will eventually tell me "out of memory" and not work properly until rebooted, unless it just plain crashes.

Keep up the great work!

Hopefully somebody is still tinkering with Classic for the occasional update. I just wanted to say that I've been getting a bug more frequently where Construct says "Out of memory" and you have to restart the program, so I'm guessing there's a leak somewhere? Most frequently happens when compiling a preview, since I guess that builds up the most memory use.

Most annoying because the program goes weird and might not let me save before the restart sometimes because of how glitchy it gets.

So what I'm hoping, and you might be suggesting, is I won't see much of a drop in framerates as I go along now? It will get lower as the game gets bigger, but it exponentially decreases how much FPS it loses? Don't think "exponential" is the right word for shrinking...

Tanks again, Ashley!

I just want to say I got a MASSIVE spike in FPS when I ran an empty layout and disabled my Xbox controller plugin being global, I'm now running my test level that used to be 250 fps at 700, so this coupled with your new runtimes has given me a whole lot of leeway.

I just have to ask a difficult question: do you think you (or someone else kind-hearted) will be able to improve this further? It still doesn't reach the 11,000 fps of an empty layout in a new game, even if I hunt down everything global and remove it. An empty layout in my game now reaches 2600 (originally it was only 500, so a massive improvement).

I just want to be able to decide if I should continue this game or not. <img src="smileys/smiley19.gif" border="0" align="middle" />

Thanks for helping, but the problem, as discussed, still occurs on levels not using any events at all, and I don't use pixel shaders except for one place.

Not much happens, but there's still the matter of running a single, new, blank layout and only reaching ~500 than the ~2500 I get if I remove everything except a layout with maybe one or two sprites in it.