Construct Classic r2 released

New releases and general discussions.

Post » Tue Mar 06, 2012 6:41 pm

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!
B
5
S
2
G
3
Posts: 234
Reputation: 1,818

Post » Tue Mar 06, 2012 6:43 pm

I hit that bug too, it would be a good one to have fixed.
Moderator
B
88
S
32
G
33
Posts: 3,005
Reputation: 27,432

Post » Tue Mar 06, 2012 8:24 pm

@Ashley. I think it's safe to push this through autoupdate. only bugs reported are either IDE related (not changed in this release), and the false virus warnings.
Spriter Dev
B
87
S
21
G
12
Posts: 3,240
Reputation: 16,461

Post » Fri Mar 09, 2012 8:20 pm

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.
B
5
S
2
G
3
Posts: 234
Reputation: 1,818

Post » Fri Mar 09, 2012 9:37 pm

@konjak, It wasn't a horrible memory leak, and it would only leak once per resize. I only noticed it because I had a situation where canvases were resizing almost nonstop.

Also, not sure what you mean with the compiling. Do you mean if you keep previewing your layout it will eventually get an out of memory error? If you can explain the issue in more detail, I'll try to take a look at what relevant code I can when I get a chance.lucid2012-03-09 21:37:33
Spriter Dev
B
87
S
21
G
12
Posts: 3,240
Reputation: 16,461

Post » Fri Mar 09, 2012 10:07 pm

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!
B
5
S
2
G
3
Posts: 234
Reputation: 1,818

Post » Sat Mar 10, 2012 1:02 pm

@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. lucid2012-03-10 13:13:46
Spriter Dev
B
87
S
21
G
12
Posts: 3,240
Reputation: 16,461

Post » Sat Mar 10, 2012 4:40 pm

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.Arima2012-03-10 16:43:53
Moderator
B
88
S
32
G
33
Posts: 3,005
Reputation: 27,432

Post » Sat Mar 10, 2012 5:11 pm

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.konjak2012-03-10 17:20:23
B
5
S
2
G
3
Posts: 234
Reputation: 1,818

Post » Sat Mar 10, 2012 5:37 pm

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.konjak2012-03-10 17:57:09
B
5
S
2
G
3
Posts: 234
Reputation: 1,818

PreviousNext

Return to Construct Classic Discussion

Who is online

Users browsing this forum: No registered users and 0 guests