lucid

Hi RavenX, Spriter is just for creating the animations, and then it saves them to a general format that can be loaded into any game engine. But you can't make the actual game in Spriter. You can see some of the implementations for different game engines that were made during the Kickstarter with the beta format in the Spriter Plugins forum and on the Kickstarter page. These allow you to use Spriter animations in the various engines listed. When the format is finalized, pretty much anything that can be used to make games should have a Spriter plugin or library. It should be possible to make a non interactive motion comic with Spriter, however.

VictorT, the next version stores and uses sprites differently, so it will be possible to choose which behavior you want

it's a definite possibility for the long term. good idea. It was already going to have the spinboxes, but that's a good idea. Also, the angle control will have a wheel you can rotate with your mouse. The current beta does have a 'protected selection' feature. You can drag, drop, and rotate a selected object even if it's behind others. only if you click a sprite on an area that doesn't overlap the currently selected object(s) will it change the selection. yes, that's in there yes, the next release will be native UI on Windows, Mac, and, Linux yes, all of that is planned for the long term, and the groundwork is already layed for those features. thanks for the kind words, and yes, we do want to work with the community to develop an ecosystem of some sort for both the animators and the developers. the todolist is huge, but things are going very well on fronts. working hard on the next version, and loving every minute of it.

sorry for the trouble, crazyheckman. The next release of Spriter(still in development) will have a much more solid foundation, so it should feel much more solid, and behave alot more like you'd expect it to. Also, also, the grouping system is getting a large revamp, and will work much more intuitively

Hi everyone. The next release should fix most bugs that exist in the current Spriter, and definitely fixes that cpu issue. The current working build idles at 0% on my PC. I've been building a much more solid foundation for Spriter for both animation processing and OI. Still a bit to go before release, but it is by far more stable and efficient, and behaves more like you'd expect it to. It's on the todo-list.

Sorry again for this stretch of silence. As I mentioned in my previous post what I've been working on is a very large and critically important step in Spriter's development. This will be the final and much more stable foundation that Spriter will be built upon. Once this initial groundwork is complete, you can expect very frequent updates. The current build looks better, runs more smoothly, and requires less RAM and far less CPU than the stop-gap UI from the beta. Also, beginning with this next beta release, there will be native PC, Mac, and Linux versions, and all 3 platforms will get simultaneous native releases from this point on. Still not quite ready to give a solid date for the next release, but things are moving along wonderfully. Thanks again for your support and patience. Upon the next release, I’m sure you’ll agree it was worth the wait.

Hi everyone. I apologize again for the lack of meaningful updates as of yet, but hard at work on a big update. The bad news is what you're experiencing now: some delay and silence while waiting for the next update to the beta, as well as an initial period without a fixed date for the next version. The good news is that this will be a huge update, and should be the last time such a delay will occur between updates. The even better news is that this update should solve all bugs reported thus far, run far more efficiently, address all the ui complaints, fix any installation and compatibility issues on Windows, and is a huge step toward getting Spriter on Mac and Linux much sooner than previously anticipated. It will also use the new file format(as well as automatically convert the current beta format). I realize I'm being a bit vague at this point, but in all honesty a more detailed description of what's to come in this update would be a bit premature as of yet, and the short version would raise more questions than it answers. In short, we are doing something, so please don't be alarmed by the quiet as of now. The next release will mark a huge step toward the finished, polished, multi-platform Spriter everyone is hoping for, and there haven't been any changes to the long-term estimated delivery date. It will also make all future updates much quicker, and less prone to any future bugs. I will provide another update when things are a little further along.

This is a known bug and will be fixed in the next version. There's still a little bit to do before I can give an accurate timeframe for that version. But the next update will be a pretty major one, and should fix most/all of the bugs/issues people have reported so far. More details within the next week. Thanks for your patience.

Does it make any difference? I'm sure some have their preference. It will look the same no matter what, but if 0 degrees is pointing to the right on your platform of choice, and you want to spawn a fireball in the direction the arm is facing, it's convenient to have that value match up instead of having to do -90 every time. My choice was different than the majority for clockwise and y up/down, so I'd prefer to go with the majority again. Seems like a minor detail, but if it makes it more convenient for 75% of developers, we may as well reach a consensus on that as well.

Hi everyone. We'll have another file format review soon, with the remaining features integrating all the ideas we've discussed so far, and this will be the complete file format. We'll still review the format further before it's final, but we'll be reviewing the format in it's entirety. As soon as we mark it as final, developers can begin implementation so by the time Spriter has each feature, the implementation can already be complete aside from testing. I'm in the middle of building Spriter's new ui, so it may be a few days before I post the rest of the file format. Also, just a few thoughts. I think it would be useful to have 'license' included in the meta-data, so people can release free for non-commercial use characters, or watermarked SCML examples of their commercial work, with a standardized method of presenting the licensing information to the user. On that note, I'm currently researching different licenses for SCML itself. I know many people are passionate about licensing and or may have specific needs we may not have anticipated, so I think it's a good idea to get everyone involved in the process. What we want is for developers to be free to use implementations of the format in their games/editors/api's/plugins/etc for free or commercial use without need for attribution. We want to maintain control and ownership of the format, and we don't want anyone(including us) to be able to sell the format description itself, or any derivative of it. The format description should be able to be redistributed freely as long as it comes with the license information/authorship/etc, and only in unaltered form. Developers can of course alter their implementation for their own purposes, but at least until SCML establishes itself firmly we want to avoid fragmentation by allowing several flavors of SCML floating around. And lastly, it seems 'y' increases as you move upward, 'angle' represented in counterclockwise degrees is the clear winner. And just to make sure we're on the same page here, an arrow pointing to 0 degrees will be pointing up, down, left, or right? edit: you should be able to get the same result by multiplying everything by the sizeratio I believe. So if the new images are half the size of the one's in the spriter file, you would just multiply all the x and y values *0.5, and use the current xratio/yratio with no changes. The benefit of using xscale is when you do character maps and other custom image replacement, you multiply the new files' heights and widths by the same ratio. If one choice for your character's head was wearing a helmet with a long feather at the top, you wouldn't want the height squished down to the height of the original head. By using ratios you solve this problem, while still allowing each part to be stretched and squashed.

I see what you're saying. My fault for being unclear in thoughts I've had and revisions made to those plans in the intervening time, and since we've been having this review. I think bones and entity's combined should be sufficient to cover both needs, but having bones be a subtype of some hierarchical object or 'group' sounds good. since it's basically a group that it's own spatial data I think the supertype thing is a good idea, and does make for more simple expansion, as well as greatly simplifying the format definition. What if instead of //, there was just in the mainline, with a 'type' attribute or something of the like and (or just ) to the s that have their own timeline. We could even rename the to or something else. And retain the name of the within? Someone(may have been you) didn't like the idea of not having a full picture of the object type until checking attributes, so I want to make sure this approach is good for everyone The time attribute is not redundant for the timeline keys, as they do not have to correspond with each mainline key. as you can see not every persistent object(object with it's own timeline) has to have a keyframe for each mainline key. The mainline keys have universal values, such as zorder (you can't change the zorder for one object, and disregard the others) and parentage for bones. Assuming the red line is the current time: in the mainline key 1, references to timeline 0 would specify the redundant helper 'key' value at 1 for timeline 0, and 0 for timeline 1 and 2. This is to avoid having to step through each key, and check the time value until you find the current key. But the time aspect is still important. If we want tweening, not forcing every keyframe to key every tweenable object is absolutely essential for animators to be able to do their job well, and without frustration. Actually, I think entities will hand this problem well, as well as shortcut it, and automate it as well. See 'subanimations' in that previous linked procedural.pdf. I'll reexplain it here as well, when I upload the rest of the file format.

I'll explain the idea in a little more detail. The same way Sprite can exist on a per keyframe basis or on it's own permanent tweenable timeline, the bones can as well. Each timeline key(not mainline) has an equivalent mainline key. So each mainline key specifies the current Zorder, and the current bone parentage. This means at any keyframe a bone can be reparented, or the skeleton can be reconfigured to have more or less bones. On the surface it might seem this is flexibility for the sake of flexibility with no real useful purpose. I believe however that lacking the ability to reconfigure bones in any arbitrary way at any time is part of the reason every time you see something animated by bones you think "oh look, it's bone animation", without having to know what program they used to make it. Keep in mind, it's not like the artist has to manually set up the parentage each frame, it will carry over from the previous frame. They will just have the freedom to do so if they wish. There's an example of how id's a parent's are used. The parent element/child element structure reflects the hierarchy of the bones, which is mirrored by the 'parent' elements. Also I agree there should be a way to specify unchanged, to avoid waste, especially in cases whether the bones don't change at all. It should just be one value perhaps for the entire skeleton (on that keyframe) that contains the 'key's 'id' for the last change. This way, if there is a change on key 2, but not on keys 3 - 10, on frame 11, you don't have to manually iterate through each key to find the last changed configuration. See above. Personally, even from my limited hobbyist animation experience, the lack of freedom with bones and parentage (particularly adding and deleting bones) is to be expected, but in those cases where you do want to make a shape changing character, or weapons that change hands, all of the sudden you're doing some time consuming workaround, that would have taken a moment or two if you could just change the parentage at any moment. Spritesheets will be supported for now, think of folder/file, as spritesheet file/image. I haven't put it in this file format yet, but there will be a flag at the beginning that specifies spritesheets or subfolders. As far as in editor creation of spritesheets, that may be added at some point, but in the meantime I will add support to export to and import from and existing spritesheet creation program. Even without that support however, it should be simple for the developer to interpret folders/files, as spritesheetfile/image entry, and then combine the individual images into spritesheets after they're done in spriter. In the response above I mentioned that for every timeline key there is one mainline key (more than one timeline key can share the same mainline key). You get the drawing order from the mainline key. If the object is not present in the mainline key, it is simply not drawn. There won't be an extra value to check for invisibility, it just won't be there. I agree. I think sprite_ref, or sprite_timeline are fine, and then do we keep the names of the and 'key'? . So you could add any number of tags to something like or or anything else that will be useful to have in the file, and included with your animation data

The pro version is a preorder for the pro version. If you backed at $25 and up, you get the pro version. Basically the current beta has only the free features. As we get further along, all backers and purchasers will be contacted with their serial keys, etc. The incentive for preordering is that it's a big discount off the final price, which we'll announce closer to 1.0. thanks for the interest

hi everyone. Had to reinstall windows due to a failing hard drive. I'll be back with responses to these things. I definitely agree on the rename, but I'll explain ideas behind bone parentage/untweened duration/zorder/etc when all this updating is over - Either later tonight or tomorrow morning thanks for all the input

This is how bones will work: basically it lists the bones in an order where the full tree can be read in one pass. if anyone prefers it, we can actually have the bones have their children as child elements, so people keeping the XML DOMs as their only data can already have them in an actual data tree, if they prefer to work that way. the implementation should store each bone's position/angle/scaling/etc data for each 'id', and any subsequent bone that contains that id for the 'parent' attribute should rotate around, be scaled by, and positioned according to the angle/scale/position of the 'parent'. those new positions/angles,dimensions should be used by any other bones that have it for a 'parent' as opposed to the values stored in the file. you'll also notice that it contains an alternative reference version as well, just like the sprite object. This is worthy of note because the usual way bones are used, they are permanent, at least for the course of the animation. this would be the reference version. Bones have the same options to bring a referenced or unreferenced bone in and out of existence on any keyframe. making characters like this, that pull random objects out, where you don't necessarily want to have this as part of the skeleton at all times, but might still benefit from skeletal animation: the same goes for characters that change shape and limb configuration frequently or even occasionally: also you'll notice because parenting is specified per mainline key, bones and other objects can be re-parented at any keyframe. So objects can be removed from holsters, or characters like robots or Ms. Fortune from skullgirls(the cat girl in the screenshot above, can remove her head and hold it) can remove their limbs, and the animator doesn't have to do anything except reparent the object at that keyframe. for bones that are not in the persistent referenced timeline, Spriter will eventually let you choose to remove nontweened bone information as an export option. if the animator is just using bones to help them animate frame by frame. the game would be wasting processing power by calculating bone information also, notice that sprites contain the 'parent' attribute as well

@timpart, I actually misread it a few times before I understood what you meant. It's important the file format be as clear as possible, so we want to make sure to get this right. The reason I named it 'key' was because it was a choice between semi inaccurately naming it 'key', and missing the 'sprite' aspect, or naming it 'sprite', and missing the 'key' aspect. The sprite doesn't have time values, but the key does. More importantly, in the mainline, keys are the things that are arranged in an order that represents time, in the mainline key if there are several 'sprite's in a row, they are all to be displayed at the same time and their order is determining their draw order. So I actually do see it from your perspective as well now, but I think it's important we take both problems into account for the final naming. Also, I should have included it in this release, but I was trying to expose only tweening related things to keep things simple. In that second type of 'key' that is more like a 'sprite', there is a 'type' attribute, that will have a string value like: sprite, collision box, bone, etc. Any ideas on a name for it, or do you think it should just be called 'sprite',regardless of the time aspect.. Or do you think it's fine with the 'type' attribute? Also, is the concept confusing or difficult to understand aside from the potential for better naming, and does it sound workable? Is it something you could easily implement, or at least as easy as you'd expect a tweening animation system to be? If so, I'll post another expansion, while we continue to think of a better name. I said I'd release everything else next, but let's just make sure bones are easy to understand as well, before we throw in everything else.

@charlieman, that should work just as well. @timpart I'm not sure if this will answer your question or not, but here's the way I visualize it: mainline contains a list of every sprite that should appear in that key, untweened sprites contain all of their x,y,etc data right there in mainline key, while the tweened sprites contain references to their x,y,etc data in a separate timeline the boxes containing other boxes aren't meant to represent element containing relationships. This is merely to illustrate that both keys are there to display certain data. Its mostly the same data for both tweened and untweened. The difference is that untweened sprites have the data locally, and tweened sprites get the data from a separate timeline.

Ok, I'll put as many of those as I can in editor, and for anything else, a 'custom...' option to write in your own. I think it'd be better to have the blending mode(even when custom) separate from the the variable system agreed, next iteration I'll make sure the position of the x_, etc in those compound names is consistent I like -1, personally, I prefer 0 indexing whenever possible, as most languages use 0 indexing for arrays. This is for making the target folder n/a for invisibility I'm guessing you mean what I mean is, source and destination. You have a file called "arm" in the "normal" folder. The target folder is "zombified", so if the charmaps had "normal" as the (source)"folder", instead of displaying '/normal/arm.png' when that character map is applied, it would display '/zombified/arm.png' Though we now have the 'z_index' as part of the 'sprite' entries, many developers(myself included) will be ignoring that value, and just drawing each item as it appears in the list. pretend the two types of sprite entry are called 'sprite' and 'refsprite'(for the new one that references the separate timeline) you would have a simple list like this and that key within would have a complete list of every that should appear at any given time. It's of course possible to just go through and read all the zindex values, and go through a separate pass and render and order everything, but I do think it's much simpler to have them all in the same list this way, even if it's redundant to the devs who'll use z_index value. It's the best of both worlds without much extra filesize. Something I hadn't considered originally was SAX parsers, which a few devs expressed their concerns about through email. Different set of requirements, but I think having redundant ways to determine things like z_index, or the way the "refsprite"s list the key, even though you can step through each time in the 'timeline' and determine your current key anyway. Anything to ease implementation is worth it as long as it's not bloating things significantly. Also, if anyone's thinks we should have a separate name aside from to refer to this second that only has the timeline/key references, that's fine as well. This was going to be my recommended method of handling tweened values. Any mathematical or hardware accelerated equivalent is of course fine, and if anyone has a more efficient, or more readable suggestion, I'd of course like to hear it. I'll just use C++ here instead of pseudocode. Also, there are obvious ways this can be reduced and made more efficient, since there are so many 0's and 1's involved, but this is the most clear way to present the logic/math behind it: //t is a time value between 0 and 1 float linear(float a, float b, float t) { return ((b-a)*t)+a; } float quadratic(float a, float b, float c, float t) { return linear(linear(a,b,t),linear(b,c,t),t); } float cubic(float a, float b, float c, float d, float t) { return linear(quadratic(a,b,c,t),quadratic(b,c,d,t),t); } now assuming t=(currenttime-keytime)/(nextkeytime-keytime) start and end could refer to x values, y values, r,g,b) anything except angles, which require the extra consideration for crossing the 0/360 border) so for linear curves: linear(start, end, t); for quadratic linear(start, end, quadratic(0.0,c1,1.0,t)); and cubic linear(start, end, cubic(0.0,c1,c2,1.0,t)); In the actual editor, I think there should be an actual visual graph version of the curve, but here's a simple HTML5 demonstration of the different speed curve types. A and B are drag droppable. Click the curve type, and drag the sliders to adjust c1 and c2: html5 speed curves

no problem with lots of questions. it's better because A: It helps me understand developer's needs that fall outside our development experience, and B: I love talking about this stuff anyway the 0.0 to 1.0 limit was just the same copy paste typo from yesterday. 0 and 1 wouldn't be lower or lower limits limits to the pivot point ratio thing. as far as the tagging thing: it hasn't been showed yet in the format description, but there will be variables that can be animated (frame by frame or tweened). Strings, ints, or floats will be possible (obviously strings can't be tweened). Also, for numeric variables, max and minimum values can be tweened as well. These can be attached to specific frames, or action points, or collision boxes. Since you stated it'd be useful for sprites, I suppose they should be able to be attached to those and all other entities as well.

so instead of a character map's map entry specifying a single folder attribute, it would specify each file explicitly? other than that I see what you're saying, and am curious what others think as well on that particular Spriter's going to have a curve editor to customize at least the limited c1,c2 method. Just to be sure I was clear in how I mean to use those values: If you wanted a quadratic curve that looked exactly like a linear you would have a value of 0.5 for c1(0.00000 for ease in, 1.00000 to ease out), If you wanted a cubic curve that looked exactly like a linear, it would be 0.33333 for c1 and 0.66666 for c2(0.00000 for c1 and 1.00000 for c2 to have ease-in/ease-out). higher order curves could just have c3, c4 etc if people want that. You're suggesting tangent angles as an alternative representation? Also, when you say custom animation curves, do you mean something beyond specifying control points similar to this? I don't think it's a good idea to get too complex like being able to specify a curve that moves forward and backward, or beyond the next key, but again, I'm open to input on this front as well just an oversight. same number of significant digits as the other things(5 for now) just put in there for completeness sake. It should be totally unnecessary for plugins that display spriter animations. might be useful for people creating scml generation tools this will be more important once bones are in there, and will be fully elaborated on in the next and final expanded review(they are a revision of the 'container' concept in procedural.pdf, which explains them more thoroughly) but basically anywhere you can put a , or anything you can do with , you'll be able to do with an entire (which contains s). Right now the files we've been looking at contain one , but they can be contain more than one. They will be listed in the 'folder'/'file' element structure as well, so referenced entities can be in separate files. Subentities(just entities referenced in an animation) will be listed in the same entry with s to determine their zorder, and their keys will have an attribute and a attribute. These can be used to create hierarchical animations, and also to create complex procedural object relationships. The document above goes into detail about how this can be useful, but as far as implementation side, you'll basically just be doing the same thing you're doing to animate the entire character, but taking into account angle/rotation/etc, to rotate the entire entity as a single object. If you're thinking this through all the way, you might wonder if this means you'll have to skew/distort sprites. In the editor the artist will not see them distorted, and they should not behave this way, until distortion is supported by the editor, where it will be an extra option. Distorting sprites is the last thing on the todo list, and I think it'll be best to wait to even define exactly how that will work in the file format, though I designed what's there so far to definitely have room to add this without having to change anything editor/implementation side, and only add to it instead. definitely ask as many as you have. that's what this is for. the more questions/suggestions the better. good, I was a little worried people might see that as redundant. and thanks there will be a tree/bone structure discussed in the next update to this candidate/review thing. Because there's so much to consider, I thought it best to review it in phases like this, but it's definitely going to have a tree structure. As far as whats there for now, until we involve parenting, the idea is that the 0,0 position is your character or effects actual location on screen. So if a "sword" sprite has 100,100 for x and y, and your character is at 80,60, the sword should be drawn at 180,160 I probably wasn't clear in the description, and I'll edit it if anyone else got confused, but for now all I meant is you have one image, and that image remains and rotates/scales/moves according to the key, but at the next key you can swap it out for a completely different image. subentities will let you take hand drawn transition images, and automatically tween them, and in the far future we'll also have shape tweening. I've thought of the crossfading alpha so one image fades out while another appears as well. I was planning to add that option later, but I think it's sort of a niche option that won't be useful in most animation, so I was planning to add it further down the line since there's so much on the table right now, and it's probably low on the animators' priority lists. yes. this was in the original Spriter as well. To be honest it's an accidental omission. I was going to start out with only additive as an alternative, but I guess now's as good a time as any to see if there is a high demand for any additional modes. Action Points allow you to specify and animate arbitrary points. I was going to have dummy sprites down the line that had width/height/angle in addition to the positions(and variables, but we'll get into that next update) that action points allow, but it makes much more sense to rename action points, and just give them the option to not contain either position/angle/scale data. These will be listed as just another animated object that the programmer/game has access to along with other animation data, and will have the same tweening options. Also the subentity system will allow you to fully animate a very complex weapon, like the portal gun with it's little robot arms, and blinking lights, or a gatling gun, and choose animations to play, which would obviously be very different for those two guns. What's even cooler about that system is that you could allow for DLC and usergenerated content, without the animator anticipating the additions. as long as they have that "fire" animation, or whatever else you need, the implementation can dutifully do whatever it's supposed to. gotcha, right now the coordinate system is based on pixels, but this can obviously be ignored and viewed as the internal coordinate system. But would you still prefer the the pivot points be specified in a ratio of the image width/height, from 0.00000 to 1.00000. I think it's a good idea in light of what you said anyway. At least in the way I would implement it if I were creating a plugin or API, it would skip one or two math steps to use 0 to 1 ratios

pstudio, we want to avoid any situation where there are options like that for export. The idea is to have one file format where everything works everywhere. It would be simple to simulate the second option by simply tweening from red to yellow, and then yellow to green afterward: Everyone, as a fresh start to avoid covering the same ground, and letting new people coming in skip this discussion, we're moving to this thread for the expanded/revised candidate: http://www.brashmonkey.com/forum/viewtopic.php?f=2&t=545

download the format description in SCML (or scroll to the bottom of this post for visual overview) I'll only document the new additions here that weren't explained/discussed in the previous thread, which also explains the way the description is organized, and the purpose of public review of the final file format candidate. First I'll list the minor changes, and the things that were added or changed according to yesterdays consensus: [*:174n8cuw]'r' 'g' 'b' values will be split into 3 values instead of a single 'color' value, 'opacity' renamed to 'a' [*:174n8cuw]'w' and 'h', and been renamed to the more accurate/descriptive 'x_scale' and 'y_scale' [*:174n8cuw]'z_index' added to 'key's, though you can still infer z_order from the order in which items appear in the 'key' [*:174n8cuw]'width' and 'height' deemed unnecessary and removed from image entries in the 'folder'/'file' list There are two main additions to the format in this description: character maps, and tweening. Please read these descriptions before commenting, because there are very specific reasons for doing things in the way they're done. Of course if after hearing the reasoning you'd prefer a different approach, I'm all ears. Also feel free to comment on anything that was changed based on yesterday's discussion. Nothing is set in stone. Also, you'll notice a poll there on the Y/Angle issue. I realize it's relatively minor to multiply these values by -1 to adapt it to the other way, but this was split down the middle yesterday, so a poll seems the simplest way to decide. Character Maps The concept is simple, but powerful. Each character map is a named set of rules with which to replace images (and in the full format sound effects and subentities). These can be used for alternate clothing on characters, or entirely different versions of characters that share the same animation data. Each 'character_map' has a name, an id, and any number of 'map' entries. As of now, the Spriter editor itself will use actual physical folders, but these can represent spritesheets, or even just virtual folder structures implementation side. For those curious, we do plan to add in editor spritesheet support at some point, but I'd prefer we keep that discussion separate. The idea here is that folders provide a simple way of dividing up images(and other files) for use in character maps. Each 'map' entry can specify either a 'folder', a 'file', or both. 'folder' only will replace all images in that folder, with images of the same name in the 'target_folder'. 'file' only will replace every file in every folder with the filename 'target_file' in the same 'folder'. 'folder' and 'file' will replace one specific 'folder'/'file' with another. Spriter will allow artists to preview multiple character_maps in the editor, and will apply them in order. In most cases order doesn't matter: Apply 'CowboyHat' character_map, and then 'Reptile_Skin' character_map. Going by the obvious assumptions it wouldn't make a difference what order they're in. Clever animators/developers could create unique combinations however, where the second map applies to the results of the first, so an "armor" character map will add armor to the character, and an "evil" character map will change a character to their evil version. If you apply both, for instance with "armor" going first - the "evil" character map could apply some of it's maps to the folders already used in the "armor" character map, so there could be an evil version of the armor used. There should probably be a default 'character_map', and a way to specify in that 'character_map' and others whether certain 'file's and 'folder's should be invisible. I didn't specify any method of indicating this in this description, but if anyone wants to weigh in on their ideas for this, feel free to. Also, important to note here is that Spriter will allow you to name and specify character maps, even if the files and folders don't actually exist. This will allow user modding and DLC. For instance, you could name a character_map "UserShirtMod" and specify that the 'folder' "shirt" should map to the 'target_folder' "MOD_shirt". At game time, the developer would simply replace the string for the folder "MOD_shirt" with a folder or spritesheet the user specifies in the game. Implementations with a high level of abstraction, such as game authoring tools, should support runtime replacement of folder names in character maps. Tweening/Pivot Points First you should notice that pivot points for each image are now specified in the 'folder'/'file' entries. These are useless without tweening, and that's why they were left out of the Beta Format export option. Next, there are now two types of 'sprite' entry in the mainline: The second type of 'sprite' entry includes a 'timeline' attribute and a 'key' attribute. If you find the 'timeline' attribute is present, you know this refers to a persistent sprite(one that can be tweened) and refers to a 'timeline' for this specific persistent 'sprite'. Before moving on to how the tweened sprites are represented in the file, I want to preface this with an explanation of 'if you need a separate timeline for tweened sprites, why not just use the same for nontweened as well, and just specify no tweening?'. In other 2D animation packages I've used, there is almost invariably an issue where either: [*:174n8cuw]it's easy to do frame by frame animation, but tweening is not supported at all [*:174n8cuw]it's possible and easy to do tweening, but bypassing tweening is either not as simple, and often times requires a workaround of sorts, especially if you want some frames with more sprites than other frames Let's say an animator wants create a magical tweened sorceress animation, and maybe add some cool looking frame by frame sparks and magic dust starting on frame 20. Should Spriter require them to specify each of these little sparks to be nontweened? Should the file format show each of these 30 sparks that exist only for a single untweened frame or two on it's own timeline? I went through several iterations of the file format. Over an over there was a problem with each method unless I explicitly separated them in the file format. Tweening, specifically with the flexibility of not requiring tweening for every sprite, and also with the flexibility of not requiring every keyframe to be a tween key for every 'sprite', simply works best if they have their own separate representations in the file format. Any other method either bloats the format to take up much more space, removes flexibility, or requires Spriter to do at least some guessing as to what the animator intended. Lastly, please don't be concerned if you've never done the interpolation math necessary to translate these speed curves and keyframes into actual positions, angles, etc. It's not difficult, and pseudocode will be provided that performs the math necessary in the final file format description. That being said, the 'timeline' entry refers to a 'timeline' element, which appears in the file after the 'mainline': Most of what you see there is exactly the same as the regular entry for sprite in a key. This entire timeline will be dedicated to the 'sprite' entries that refer to it. I'll list and explain the new attributes here, and also for attributes familiar from the normal 'sprite' entry, but which now have additional considerations: [*:174n8cuw]for now, please ignore the 'name' attribute [*:174n8cuw]Note that x,y,x_scale,y_scale,r,g,b,a,angle are all tweenable [*:174n8cuw]time:Note that each tweenable 'sprite' does not need to have a tweening keyframe at every 'mainline' key. This is extremely important for workflow, or every time the artist creates a key in between two other keys, it would create timing problems with all other tweened 'sprite's if this key is repositioned in time. The 'key' attribute in the 'mainline' entry for this 'sprite' specifies the 0 index of the 'key', so you won't have to manually step through each key, and figure out the specific keys you should be tweening. [*:174n8cuw]curve_type:can be instant(tweened sprites don't have to be tweened throughout the entire animation), linear(requires no control points), quadratic(includes additional c1 attribute), or cubic(includes additional c1 and c2 attributes). Those curve types allow for tweakable ease-in, ease-out, and ease-in/ease-out speed curves. [*:174n8cuw]c1 and c2:these are represented as 0.0 to 1.0 values. If a linear curve is lerp(0,1,t)*time, a quadratic curve is qarp(0,c1,1,t) and a cubic curve is cubic(0,c1,c2,1,t). I can elaborate further in the replies if anyone who's already worked with interpolation is confused by the idea of using 0 to 1 values as speed curves, but I don't want this section to become too intimidating for anyone who has not. [*:174n8cuw]folder and file:notice the image can be changed at any keyframe whether tweened or not [*:174n8cuw]pivotx and pivoty:if these attributes are not present the default pivot points will be used (specified in the 'folder' and 'file'), but pivot points are also tweenable. [*:174n8cuw]angle and spin:spin determines whether the angle change will go clockwise or counterclockwise. Notice I kept the 0 thru 360 limit, which will require artists wishing to rotate a piece over multiple keys if they want it to several full turns. This is mainly for my/artists' sake. I have yet to find an editor that allows multiple rotations per key aside from huge complex packages like 3dsmax that doesn't screw something up when you try to move angle keys. I think having this limit will be beneficial to artists. It keeps Spriter from having to guess(and animator frustration if it guesses wrong) what they want when the move and copy keys from multiple rotations. [*:174n8cuw]mainline_key:is only used by the Spriter editor. This just makes it so these keyframes always correspond to an actual mainline key Also, note this is still not the complete file format, not only to avoid being overwhelming and confusing, but also because what is decided here with tweening applies to most of the rest of what's in the file format. The next release will include the entire format, which contains action points, collision boxes, sound effects, variables, and subentities. Thanks everyone. Here's the visualization of everything listed so far:

for those currently browsing the forum just a heads up, expect the post in the next hour or so. Just have to upload the files and type of the description. again, will cover pivot points, tweening, and character maps also going to poll the whole y up or down/cw ccw issue it's definitely easy to use either one with a simple '*(-1)' either spriter side or implementation side, but I'm interested to know the majority anyway

Hello everyone. Last check in for today. Tomorrow, I'll post some more format info including tweening and probably character maps, since most of the remaining concerns have considerations and explanations rooted in character maps and tweening. Best to leave this as is at least over night before releasing the next batch of info to allow the rest of the time zones to check their email and weigh in on this thread. I definitely don't mind keeping the path as one long string if that's still the consensus after I reveal character maps, but at least you'll be able to see there is logical reason why they were separated in the first place. Also with tweening, to make things at least slightly more clear until I release the description with tweening, tweened objects will use different element/attribute structures than untweened objects, so if it looks like the current format can't possibly support it, that's because none of the element structures used in tweening are included in this limited description. I'll explain it all tomorrow. Till then good night everyone, and please continue to give feedback. Interested parties will find an expanded format description tomorrow - most likely in a new thread to avoid this becoming 18 pages of confusion. Thanks everyone

right, in my own experience, there's is usually a variable framerate depending on the system's ability to keep up, and advancing time is tracked - and gameplay/animation determined by a delta time value which reflects how much time has passed since the previous gameloop tick. So when the system is taxed, the animation and gameplay won't slow down, but instead become choppier, so the game runs at the same speed on slow and fast systems. This logic will become a little convoluted implementationside with the addition of frame numbers and framerate I think. edit: izb, spriter doesn't have an internal framecount. Each key has it's time value. The other issue with frames, is that the artist will still be limited by the distance between frames, so if they decided to change to a more detailed animation style, there would have to be a recalculation to make a higher frame density, resulting in altered snapping on the timeline