Construct Classic r2 released

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!

konjak

First, you may already do this, but please make sure you're saving incrementally(ie. first you save it as Konjakscap1.cap, next save Konjakscap2.cap, ... ...etc). Another option is dropbox, which keeps a history of file versions. So storing your cap in that folder would work as well.

It's rare, but there have been a few cases of cap corruption in the past. In my personal experience with file i/o, a crash during a save operation is a likely cause of data corruption in an otherwise reliable save system. If you're crashing frequently, again please make sure you're not saving over your only copy.

For the visual corruption of the IDE, make sure your graphics card drivers are up to date. I believe this is the first time I've heard of visual corruption like that.

Next thing I would do is save your game to a separate test cap so you can add random things, and save frequently, and do whatever to try to cause the crash. Before doing this, press Ctrl-Alt-Delete, and open task manager. Look for Construct.exe and watch the ram usage meter. Check to see how much it's going up when you do things like preview, or save, or whatever you normally do to cause the crash. I just tried this and there is a small amount of ram usage added on each preview. The first preview a large jump, and then much less afterward. 0 to 1MB per preview, and about 2 megs per save. It's small enough that I don't encounter this error at all, and save very frequently, and have been working most of every day all day in construct for a few months now.   I have a crash now and then but it's usually related to either undo/redo operations, or trying to move events or groups around.

I'm not sure if the edittime shares any of the renderer code with the runtime, but after you get an idea of how much ram is leaking for each preview and save - try installing the new version to a different folder, like "c:/program files/construct r2/". If you save, make sure you don't overwrite your previous file, because the old version won't be able to load it anymore. Try to see if previewing and saving cause a smaller leak, if it does, then the problem's solved.

If not, I'm curious about the size of the cap on disk, the size of the RAM usage jump in task manager, and how much ram you have on your pc, and your gfx card vram. Also, does the error say anything else? or just "out of memory".

The cap I was using with task manager is one layout, and one event sheet with 762 events.   If this is a problem directly with the editor, I probably won't be able to even attempt a fix, because I don't have the Prof-UIS library required to compile the edittime. Of the people still working on Construct Classic, Rojohound is the only one who does as far as I know. These things may help narrow down the problem in any case. And it could be that adding a little ram to your machine will at least bandaid the problem so you don't have to worry about it, even if the memory is leaking.

Lastly, do have any particularly huge image files? or an insane amount of images?   I believe Arima said he had problems with large backgrounds messing up the IDE, and making it slow down. He said he fixed it by having the game load them from disk at runtime, at least during development. You could always disable those events and add the images to the cap just before release.

Lucid, if you recall, there used to be a major memory leak in CC every time the parameters window of the event wizard appeared - it had to do with drawing the icons in the window at the bottom where you can get the expressions from. The more icons there, the more memory it would leak, and eventually that would result in the IDE getting screwed up, and a 'not enough memory' window that appears that, at least on my machine, was a different visual style than the rest of the IDE (it might have been when I was using XP though, I can't remember what it looks like on my new comp). It's the same effect.

Also, huge image files isn't the problem - those drastically increase preview time, which is why I load them at runtime. I think the problem has more to do with huge numbers of completely different objects in a layout (different objects with different animation frames, not clones), possibly a result of drawing the icons in the objects bar, as the bug seems to hit quicker for me when editing animations in layouts with tons of objects. If I switch to editing animations in a layout with less objects, it seems to take longer to happen. I think it also requires actual editing and saving of the edits to the animations rather than just opening and closing the animation window. I'm not entirely sure it's that though, but that's what it seems to be.

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.

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.

7500 is a lot though. Your cap with the memory leaks doesn't have that much does it? If you just only keep open one layout and event sheet per session, does it still leak as much?

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. :(

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.

Great release, however there seems to be a bug with Families and Effect parameters.

The Action Wizard will not display any parameters on the third screen (setting the actual values) - it will say "There are no parameters for the selected item". 2-state properties will work properly, however.

For example, screen-by-screen:

PickFamily->OpacityPlus->ActivateOpacityPlus will work, but

PickFamily->OpacityPlus->SetIntensity will not, as the third screen will be blank save for "There are no parameters for the selected item".

Randomly, when clicking Finish on the last blank screen, an "Invalid argument" error appears, but mostly the wizard closes and the Action reads 0%.

The Effects show properly inside Manage Families.

Vsync does not work in Fullscreen Mode. It switches from Vsync to no Vsync ten times a second. Games are unplayable in Fullscreen because it stutters really bad and FPS jumping from 600+ to Vsynced 60FPS all the time.

I can reproduce this with all my cap files on 4 different computers.

I was noticing fullscreen framerate issues too, so it's probably something weird going on for many people. I don't find it horrible, but other players might so it'd be nice to see fixed someday. Alternative is fitting the image to people's screens along with zoom effects.

EDIT: Actually... no, it seems to ber working now. I was going to test if it was due to my main monitor insisting on reading out 59Hz in the Control Panel, whereas my second monitor does 60. Both ran fine right now, so I'm confused. <img src="smileys/smiley1.gif" border="0" align="middle" />

So happy to see advances on CC. Thanks for all the hard work Lucid! I feared CC was long gone...

CC is about feature-complete. The only thing left to do now is clean up the GAZILLION tiny bugs that hide in every corner! After that, the main features people are requesting are ones that require a huge slot of time and potential rewriting (OpenGL, Portability, etc).

I'd still like better non-DX9 program support. A lot of things just don't work too well, on top of not being available, when using CC to make general-use programs (standard controls and manipulating them, for one).

Anyhow, just as everyone else says, wish I could help, but I have a lot going on, aside from knowing the little bit of outdated C++ I learned in highschool.

Thanks for all of your hard work!

I always feel people working on construct underestimate the stuff game makers do. I'm a good deal over a thousand events and I'm making an NES Style game. Much less dialog, much simpler bosses, much simpler cutscenes, much simpler enemies and a much simpler engine in general.

Everything is working semi good on my end (all my assets and stuff are so small that I've never noticed a memory leak issue. Just crashes), but I'm always find it a little strange when people are surprised by this stuff. When you make an engine, it's easy to make nice, clean, reusable code, but when when you make a game you WILL want to do things your engine doesn't expressly support. Any decent game designer is, more often than not, going to muck with and grow their codebase rather than stifle their creativity.

That said, you guys are great and always accommodating. I just always found this funny, even when Ashley and co. were still heading C1 development.

You just gotta always assume we're doing way more than toy expect. :)

Thanks for the new version!

But please someone fix the memory leak problem. I want to see the game ICONOCLAST of Konjak finished.

Message for Konjak: Please complete this game! Your games and projects are amazing!

Thanks, but I'm still managing so far. A fix would just make me able to rest easier in case it gets out of hand later in development.