I also have no problems running vsync in fullscreen mode.

What inkbot said

also to make it a single action to set and keep it between 1 and 5

set charselect=clamp(charselect+1,1,5)      

to go right

To go left replace the +1 with -1

To make it cyclical with a single action, make it 0 thru 4 instead of 1 thru 5

and use charselect=((charselect+5)+1)%4

For right movement and replace (charselect+5)+1 with (charselect+5)-1 for left movement

Thank you everyone for your interest and purchases.

inkBot - yes, this is a pro only feature called a Character Map. The version of the editor releasing soon will not include all pro features as of yet. All the plugin code is there to support it for the Construct Classic version, and for projects converted from the old spriter, those charmaps will work. It should be less than a month after this release before you start getting the extra pro features in the editor, one at a time. The first one, 'export to PNG', will be available in this release.

As for charactermaps, your images will be divided into folders (manually on your hard drive. edittime folder management, or a virtual folder management system is on the todo list).   You could have one directory "/Robot Arms" and another one "/Human Arms", containing files with the same names that correspond to eachother. Each character map lets you specify any number of folders, and whether to display the images in that folder normally, don't display them at all, or choose an alternate folder to retrieve the images from when that character map is applied.   This allows for a wide range of uses. You could of course make a total conversion so characters could look completely different with a whole new set of sprites. But you can also make one version of each animation for your character, and have an event such as:

On SpriterCharacter collision with ClothingFamily

----Set SpriterCharacter charmap to ClothingFamily.PVNameOfCharmap

----ClothingFamily   : Destroy

Each charmap could specify folders containing those articles of clothing. So now your character has a hat, or a helmet, or shirt, or armor after touching the powerup, any number of sprites could be added removed. or replaced. All without having to touch the animation(either in the events, or in the editor).   

There are several planned enhancements on the todo list such as having multiple charactermaps applied at a time, and also, I'd like to add Charmaps that are definable at runtime, so you could basically define a modkit with simple actions that allow the user to choose a different folder to grab the sprites from. This way they could make their own character models, or whichever things you want them to have control over. This feature will probably be available when the C2 plugin arrives.

Also, eventually I'd like to add granular control like Replace RightArm.png with SomeOtherRightArm.png.

I don't think it has to be too complex mathematically, and if you figure how to space apart feedback, it might be doable with a neural network. I had considered making a neural network plugin for CC at one point and there were libraries for it for C++. I wouldn't be surprised if there are JS neural network libraries as well. It's not a magic automatic solution where you tell it to learn to fight and you're done. You'd have to study and experiment to find adequate starting weights for the nodes, how many inputs, etc, but I think that's the simplest approach to memorizing arbitrary patterns.

Fourier transforms are also supposed to be useful for the simplification and generalization of patterns, but you'd probably need to design alot more of the AI than for the neural network, and Fourier transforms really are computationally expensive.

Unless you're very interested in AI theory and want to do this for the sake of doing it, it'd be much easier to make fake learning. Program a stupidly hard AI that knows how to counter and dodge everything, and proper timing for effective attacks. Then dumb it down at the beginning of a round or game. Each time the player jump kicks, it increases the probability the AI player will "learn" that it's coming, and begin applying it's jumpkick counterattack behavior, randomizing timing, and mistakes will make it feel more natural. I believe this is how it's done in most fighting games. Even this approach would be timeconsuming, and it's probably the simplest of the three, but not impossible. Just know programming fun AI, even conventional AI will most likely be a long process.

hi grestord. I agree. There are a number of other improvements to S I'd like to make, aside from documentation. Since I wrote 's' I've learned alot, and I think I could make something much more accessible the second time around.

Unfortunately at the moment working fulltime on Spriter so I won't have time to work on any side projects like this for the time being. If you have any specific questions though, I or one of the other S users may be able to help you.

When you'll send e-mail for who bought the pre-order version? I had no updates of spriter by more than 6 months...hmm. I joined brashmonkey about 6 months ago in late september, and you should have gotten an alpha test version in mid-november. The beta im discussing here has not released yet, but you should receive an email when that releases.

If you didn't receieve that november email, and I believe another update or two via email that month, please pm me with your contact information, and I'll forward your information to Mike (Holymonkey), to make sure you (along with the other pre-orderers) are among the first to download the new version.   We've definitely been a little quiet the last 2 months or so, working hard to update the UI from the alpha placeholder UI into what we believe is the most steamlined animation interface for this type of animation. That process took some time, and builds halfway through that process wouldn't have been useful released on a wide scale to either us or the testers.

Things are about to get very awesome for Spriter, and we fully intend to give you your time and money's worth. Thanks for your patience thus far.

Correct, as of now, there is no C2 plugin, and there will not be for this initial release. Also, tweening is not fully supported as of yet within the editor.

For the testing purposes above I was using a proof of concept version of the plugin that performs all the necessary xml-reading, drawing, and math, but has no actions/expressions/conditions.

With the upcoming version, you can still export to PNG to create traditional sprites, and the files you create now will still be useable when the C2 plugin comes out.

Also, as stated in the other thread, anyone who purchases now, or anytime before the official release of the C2 plugin - will receive the C2 plugin for free when it is released.

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