<font color="red">Update 3/23/12:</font>

At long last, Spriter Beta Free Version Release to Scirra and Brashmonkey Board members this coming week! The price will be increase to a $25 beta version price at that time, so now is the last time to grab it at the current price (once all pro features are fully implemented, and it's been battled tested as stable, the final price will be announced and take effect). We wanted to give you one last warning of the price change, but if you can afford to wait, we'd prefer you to wait until next week's release as we will be starting a Kickstarter.com funding campaign on the same day as well, and a pledge of $25 or more will get you your pro version of Spriter, and help us reach are funding goal. Kickstarter is all or nothing crowdfunding. If we don't reach our pledge goal we get no funding, so we'll be needing all your help not only in the form of pledges, but also in spreading the word to any developers, animators, and even gamers who want to see more great looking 2d games coming out, especially if you're an active or well known member of a community or forum that specializes in one of these areas. Spriter won't just be a Construct and Construct 2 tool. The idea will be to get Spriter supported on every major gaming platform and engine. We will be doing some of this ourselves, and third party developing of extensions for other game engines has already begun as well.

We will be announcing Spriter's full feature set, as well as our potential future feature set if we get enough funding to take Spriter beyond it's current scope. A few of you might be pleasantly surprised and/or amazed at what's in the cards for Spriter. We've worked very hard over the past 6 months to make Spriter as awesome as possible, but there's still a bit to do to get it from beta to 1.0, from polishing the pro features, to fixing the bugs that will inevitably rear their ugly heads once hundreds or thousands of users get ahold of something. This process will be much quicker with a fully funded Spriter. Spriter's come very far from it's humble beginnings in November. I left my fulltime job to work on Spriter. I've been funding this development time out of pocket, and sacrificed 4 years off the end of my life with caffeine, because I believe in this project, and I think it's something developers have wanted for a long time, and not just us Scirrans. This is a labor of love, and I'd like to continue to respond to every "could you make it so when you press this it does that" with an immediate "YES!!" and for that we're going to need your help.

So get your trigger fingers ready to click on every like, favorite, and share button we can throw at you. We're putting the finishing touches on our Kickstarter video, and preparing the Kickstarter site with as much information as possible. Once again, the full Spriter feature set is supremely wonderous, but the feature set for what we can do if we go beyond our funding goal will blow your minds. Thank you everyone for your patience and support, and to those who have already purchased Spriter, worry not. Everything that has been promised will be delivered. The funding is to help get everything to you as quickly as possible, as well as everything you'll learn about next week. Thanks again everyone!

<font size="1">3/16/12 new vid at the bottom of this post</font>

Update 3/11/12:

    The beta for the free version is now complete, and in the hands of a small group of testers, so we can iron out any last minute bugs for the latest features, and address any last minute usability concerns that may arise. Over the coming week(s) we'll be updating our website, and getting together basic tutorials and videos to get you started, and then at last it will be released to the general public. Once again, a reminder that the price will be increased upon this upcoming release. Now will be the last time to get Spriter at the super-low preorder price.

C2 spriter update:

   The development of the actual c2 plugin has not yet begun, and tweening is not fully supported by the editor as of yet, however preliminary testing with a proof of concept version of the C2 plugin seems to indicate that javascript/WebGL as handled by C2 is more than capable of displaying many characters on screen with tweening enabled, animating smoothly in the browser! This also means of course this will work with exe wrapped games as well, as those C2 features become available.   

   I will have a demo of this in-browser tweening as soon as possible, but suffice it to say - the smoothness and speed of the animation was very exciting to see, especially given the size of the sprites used.

   The HTML5 canvas version of the display will most likely not be fast enough for tweening, but should be fine for frame by frame animations. You will be able to use the same animation file for both the tweened and non-tweened versions, and easily toggle tweening on and off in Spriter once tweening is fully integrated.

   Stay tuned and bear with me a little longer - expect a flood of information, screenshots, and vids soon, as we are gearing up for release.

This information is cc'ed here, and that thread also contains the previous update.

<img src="http://dl.dropbox.com/u/1013446/Spriter%20Releases/birdscreen.png" border="0">

<font color="red">3/16/12:</font>

thanks again everyone. Release coming very soon:

having some fun with spriter:

runs much smoother when I'm not screenrecording:

watch in Original or 1080p please if your PC and Bandwidth can handle it:

I'm not sure if sprites that huge are a good idea on the web or for c2, but still pretty awesome :)

new update in original post

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