An internal image editor is already on the to-do list i believe, as well as other exporters (the exe exporter is already being tested!)

C2 is a game maker, not image or sound editor. You -will- need supporting software to use it

exe exporter already being tested?

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?

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.

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.

If I don't say Tom, but rather just tom, does it still send an alert?

I think it's perfectly feasible to make a c2 project converter to an alternate engine, on a piece by piece basis. Once I can establish some type of stability with my business situation and get some free-time back, it's a project I'd like to try my hand at.

To make a full runtime for c2 would take a very very long time, but making something piece by piece - starting of course with sprite object, some system ACE's, text object, and then mouse/touch object - you'd have something useful to play with as you developed it further.

The proof of concept kyat mentioned is in this thread.

It doesn't do much, but it shows that it's very simple to throw together something that converts C2 xml to some target language code. Depending on the platform, you usually won't even need a full plugin system. You can include the modules manually, or have the conversion application add the code needed to include the additional files.

title says it all:

http://store.unity3d.com/index.html

<font size="1">as a side note, there will eventually be a unity plugin for Spriter[/plug]</font>

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.

Try this exe -> http://dl.dropbox.com/u/1013446/forumhelp/anglerandomizer.exe

drag the red handle left and right to see different values for Angle Randomizer.

Angle Randomizer sets the maximum angle any one of the particles can turn in one second.

Try it around the lower values (between 0 and 30) especially to get a clear picture of how to use and explain it.

<img src="http://dl.dropbox.com/u/1013446/forumhelp/anglerandomizer.png" border="0">

i like how the whats next for html5 site just freezes my browser

thanks everyone. GenkiGenga, stability won't be a problem. The plugin isn't doing anything unusual that might cause stability problems. However, in the event that bugs are found, they will take priority. There is a long roadmap of future features planned for Spriter, so development won't stop anytime soon. We will be outlining some of those future plans after release, btw.

— Yes it still counts. Every current owner of Spriter and any new purchasers until Spriter's impending release will get the C2 plugin for free.

Sorry vidi, I thought I had responded to your last post already. but Yung is exactly right. Look at that pic again:

<img src="http://atomicrobotdesign.com/blog_media/sprite_movement/images/gb_walk.png" border="0" />

now this isn't completely scientific, but on disk that image takes up 168k. The next image is a rough example of the size of a cut up version of the character. If you made the images specifically for spriter, they would be in separate files, so you wouldn't even need to have that waster in between space.

<img src="http://dl.dropbox.com/u/1013446/Spriter%20Releases/spritered.png" border="0" />this image takes up 12k. I'm not sure how directly the disk space translates to VRAM space, but it should be a similar ratio.

There is some white space in the large version, but if you were to fill it with images, you'd have 18 frames worth of space. This means a sprite would use about 14 times as much vram, just to have 18 frames of animation, for this particular character. Want 36 frames, then the regular sprite would use about 28 times the space as the spriter version. The spriter version would still take up 12k of VRAM, even if you had a total of 1,000 frames. This will help not only VRAM usage, but eventually download size as well.