lucid

everyone: Original Post updated with first revision based on feedback so far RE: tweening. the first expanded candidate will cover the tweening. It takes zorder, direction of rotation, and many other things into consideration. Pivot Point info for images will also be covered. This first release was meant to only focus on what was available in the beta format release to let devs focus on what's been changed. I'll be releasing an expanded candidate after we're all generally satisfied as to what's here now. izb: the folders system will work for developers as well, folders don't have to mean physical folders, and will be useful for character maps, spritesheets, and user modding, but if there is anything truly useless at gametime, I'm totally fine with having a game export option that just strips off the extra info. We'll go into greater detail in the near future. as far as frames vs time, I'm not completely against doing things by frames if others agree, but personally, I like the idea of being able to stuff more details in animation only truly revealed when played back in slow motion. With frames, you would be stuck with the slightly awkward situation of very high frame numbers and very slow playback speed for any animation that had this type of detail. Of course this won't matter much implementation side, the awkwardness would come in for the artist and animator

sorry for the hugely long reply, I hadn't expected so many replies so quickly, I'll try to check back here more often for this review process, so there isn't as long as a reply needed next time. I was going to split this into many posts, but in the interest of...not doing that...just please excuse this one TL;DR reply if you want my responses to what you or anyone else said so far good idea also easy to retrieve in any gfx libraries I've used. if others agree, I'm fine excluding these agreed you can able to change width and height per keyframe, if that's what you mean. The default for xscale and yscale(w and h) will be 1.0, meaning if they don't appear, you use the images' default size oops. just a typo. definitely will allow larger than 1, and less than 0 values for x-axis-flipped images as of now, I've avoided the possibility of nested folders, though it's not something that definitely has to be excluded. The reason for this is the way character maps will work(which will be explained soon), and also to make it simple for folder to refer to 'spritesheet', and each image be a texture in the atlus just wanted to start off this review process with the bare minimum. Everything you see here would be read by Spriter and implementations as containing No tweening, not even linear. The full version of the format which we'll review once everyone's happy at this level, will contain the possibility for the following curves: instant(like now, no tweening), linear, quadratic, and cubic. It will be easy to expand to higher order curves as well, but those options allow for ease-in, ease-out, and ease-in-and-out. I personally would prefer to use additional keys rather than have any more control over the curve speed at that point, but this is definitely open for discussion. Also, if you're curious, the control points for the curves will be defined as sliding numerical values, so it's not just ease-in or not, you will have control over the exact acceleration/deceleration possibly in the future, but in the interest of making it easy for artists to sell art packs, and know they'll work for everyone everywhere, and to speed up the adoption process, and make universal support as quick and painless as possible I think we should focus on one version of the format until it becomes very widespread. There are many free webbased XML to JSON converters online(seriously, there's alot), and if a particular target platform will work much better with JSON, I encourage those developers to support that, and just let the users know to convert to JSON that does make sense, and we can do it that way. the logic behind it though, was when other things come into play like sound effects, and a more advanced feature sub-entities, those key entries would all use the same 'folder'/'file'. interesting. There's a few additional concerns that enter when character maps are introduced, and I'd be interested to hear your thoughts once those factors apply If many agree with you about the transformation matrix, I'll be more than happy, but personally, I strongly prefer the human readable separation of x,y,etc. Aside from my personal preference, I think developers creating implementations for game authoring tools, rather than libraries and apis, will usually have alot of extra work to do to convert a matrix to useable values, whereas programmers working in DX, opengl, etc can easily convert to a matrix Hmm...Again give me your thoughts once we expand to show tweening, as colors will also be tweenable, I'd be interested in your thoughts when you see how tweening will be handle in the format yes, stay tuned for Character Maps in the expanded description this should be doable yup, just a mistake, above 1, and below 0 will both be supported I agree with all of this, though probably 'a' instead of 'alpha' you say below. If no one else has a problem with it, I would prefer this method as well. Again, I personally prefer this method, unless anyone objects this, let's wait and hear more opinions. The beta format used counterclockwise, and there was a bit of confusion/requests to change it. I hope a few people will weigh in, so we can choose by popular vote. Obviously, either way is very simple to implement Spriter side yes, see the response to the other interpolation question above I responded above to RGB(I agree), and I also agree angle should stay 0-360 possibly, and if we do, the compressed format will also be created through a similar review process. However, we definitely want to stick with one format for now, until it's more widely adopted however, the format will never become a standard if there are too many flavors starting out version info was definitely planned. The generator tag is a good idea, too another good idea the array thing, yes. the id's will simply be array indexes in most cases. the other devs can weigh in as well, but personally, I don't like 1 indexing. 0 indexed is most universal for programming, at least for the platforms/languages I've had experience in, and there's certain mathematical tricks that just don't work without 0 indexing. but again, this isn't set in stone, so if the majority agrees, I have no problem with that right, it will always use the lowest unused integer(starting at 0) hmmm...interesting. Well we can discuss this further as we look at more of the format. There's a few other things that need to be decided with IDs as more of the format comes into play. For the most part, with what's been presented here so far, you can see the IDs aren't really needed much yet agreed. typo again. I thought I had corrected that already sounds good, though the opposite might be better (instead of the 'image' attribute, it could be the 'file' attribute), as it will make it more consistent with other elements we will discuss in the expanded format review yes. we can make that the default value so there isn't a wasted time="0" for every first key k, that's +2 for counterclockwise definitely. the 1.0 limit was just a typo, got a little overzealous copy pasting the 0.0 - 1.0 range I agree, this will make it more simple for me as well See the note above, about considering not supporting nested folders. If we do, however, another possibility is actually nesting the tag itself? +3 for not needing thatThanks everyone...please keep up the great participation

Developers, this discussion has moved to a new topic: viewtopic.php?f=2&t=545 image and SCML file below updated to reflect suggestions made by developers: Revision 1: 5/12/12 6:04PM EDT Hello everyone, Over the past two weeks I've been designing the candidate for the 1.0 version of Spriter's file format. Today I'm presenting it to the community of developers as an initial proposal. I request your participation so you can help shape the file format you'll be using, and ensure it's something you'll enjoy working with. The format as it's presented here is meant to be able to grow with Spriter. Down the line when new features are added, such as procedural animation or deformation, it should be possible to make these additions without affecting anything else in the file format. Another primary goal of this design was to allow for many different styles of animation with minimal effect on implementation and the format itself. These are the two main goals that decided the overall structure of the format. As of now, the full version of this specification will allow for the following features: sprites, collision boxes, action points, variables, sound effect triggering, character maps, tweening, bones, sub-entities(containers and subanimations), user mods, and spritesheets. Though each individual feature is very straightforward, the entirety of all those features would probably be overwhelming in one dose. Today we'll just be looking at the features that were available in the beta, and the differences in the way they're handled in the new version of SCML. The following is a grid visualization of the downloadable .SCML(XML) version of the format description. Certain items have a default value. In the visualization and the SCML download, default values are indicated as the value corresponding to the attribute or element. The value will be displayed at the precision it will occur in the file. For example x="0.00000" indicates that 'x' is a float with 5 digits of precision with the default value of 0.0. If an item is of this default value, that attribute or element simply won't appear in the file at all. This is meant to save space and avoid checking values just to confirm they don't need to be used. (Anything in parenthesis) is not part of the default value, but an explanation of that value. Basics [*:119cxisc]For now, just think of an as a complete character. There can be any number of s per file. [*:119cxisc]Each can contain any number of s. [*:119cxisc]Each has exactly one (main timeline). This has to do with tweening, and will make sense once that part of the format is presented. [*:119cxisc]The can have any number of s. [*:119cxisc]Each can have any number of sprites, whose drawing order is the order they appear in the key. If you implemented the beta version of SCML, you'll notice quite a bit has changed. Aside from the feedback I got, the beta format's basic design was mostly legacy from the way the old version of Spriter worked. There are some of the differences: [*:119cxisc]Elements that can occur more than once have an value. It is an integer unique to that instance of that item at that depth. [*:119cxisc]Each does not show the duration that key should remain on screen. It shows the time in milliseconds that the key occurs in the animation. Example: If there was a 1 second animation with 4 evenly spaced keys in it. The beta format would give each key a 'duration' of 250. In this version each key would have a time within the 1000 millisecond animation, and the keys' 'time's would be 0,250,500,750. [*:119cxisc]Frames are no longer listed separately from the animation and referenced from keyframes. The key itself contains the information needed to display the frame. [*:119cxisc]Width and height('w' and 'h') are no longer pixel size values, they are ratios to the original size of the image. For instance, if an image is 50 pixels wide, and the 'w' value is 1.0 it should be displayed at 50 pixels wide, if w="0.5" it should be 25 pixels wide, etc. Please post your thoughts on what's explained above, ask questions, give suggestions, and post feedback before we move on to the other parts of the format. Thanks everyone.

There is a new version available for download on our front page. Just 2 small fixes. [*:r3ldf7gn][FIX]Fixed problem where clicking a sprite would nudge it a few pixels in the direction of the mouse even if you just meant to select it [*:r3ldf7gn][FIX]Shortcut keys 1 and 2, to move directly to the previous or next keyframe, now takes you exactly to the specific time for that key, instead of maintaining your time offset from the current key Thanks for your patience everyone. There's a few things that take a little time that need to be done before we start seeing the larger and more exciting updates. There is much needed code maintenance and refactoring to be done that our previous budget of time didn't allow us to do thoroughly, and also upgrading the GUI from it's placeholder state to the actual final UI. These things, while they'll make the update news a little sparse in the beginning, will ensure everything moves quickly once they're done. It'll be much simpler to add features and track bugs so updates will become quite speedy once this part is over. I'll update you with time estimates as things progress. Aside from this, we're reworking the fileformat to something approaching the final form. The current fileformat structure has a number of legacy elements from the previous version of Spriter, and rather than have developers wait for close to Spriter 1.0, we'd rather do this early so when the remaining features start appearing, no one has to redo anything, and developers can immediately start using Spriter, and even laying the groundwork down for features the editor doesn't support yet, so day 1 of those beta releases, these functions can work within implementations. There are several sweeping changes that will be made to the file format to prepare it to work well with everything planned for Spriter's future, and it's impossible for me to anticipate the needs of so many developers across so many platforms. In the coming weeks, I'll be posting the proposal for the final file format, and I'd like feedback from developers to ensure that it will work well, and that implementation will remain easy. Thanks everyone!

this is fixed now. redownload. I'll post a release thread soon

a stop gap is probably most accurate yes.

yes, we're aware of this problem, and it will be fixed in an upcoming version

please check your kickstarter mail again. It should be there by now. Thanks again for your patience

excellent work. For the parts appearing out of place, please make sure you are reading angles as counterclockwise

I'll be working on general stability in the near future that will probably fix most of these problems for people, but if you didn't download within the last week or so, please uninstall using the uninstaller in the installation directory, and reinstall the new download at brashmonkey.com. Allow it to install dx and the runtime as well even if you already have a newer version of directx thank you

excellent work. thank you for helping get Spriter everywhere. it's fine to use the example file, and even distribute it with examples of your implementation if necessary

there will always be a free version(which will do everything the current beta can) and a paid pro version. Also, at some point the character map features will have some mod friendly particulars.

plate is pretty full for 1.0 onno, but I will look into adding at least basic SVG at some point since I do see how it might be useful

Awesome work, thank you very much!

Ok enoch. I'll be doing some general maintenance this first month or so and cleaning some things up I didn't have a chance to do before the kickstarter. Hopefully some of these fixes will fix your problem. Also, I think you mean you tried a previously posted installer. The installer was updated in the last week or so, so it may fix your problem even if the previous one didn't.

thank you udo. We'll be upgrading our payment options, but for now it's the only option. Please try our free version, and stay tuned for updates

hi skullsoft, There is a bit of a CPU hog issue which will be corrected as development continues. The early beta is pretty early for being released on such a wide scale. As far as the other bug. Are you saying the program is completely unusable now? Can you load the sample project from the installation directory?

Both of those things are planned blazah. thanks for the suggestions

sorry for the slow reply blazah. Some strange bugs indeed. After the kickstarter dies down, the first thing I'll be doing is some general code maintenance, which should make everything more stable and efficient. If things like this are still happening, I'll dig deeper.

the format is made to be easy to implement on any platform, and the current beta download includes the information needed to implement. Currently in it's beta state, all that's required is reading the xml, which contains lists of sprites to put on screen and hold there until the next frame. Anyone who can load XML in c++ (i recommend the tinyxml++ library), and can put sprites on screen should be able to implement the beta format very quickly. And we'll continue to update documentation with format descriptions, and eventually pseudocode for things like tweening, or procedural animation when those features are complete. There have been over 14 different implementations since the kickstarter began, including one on a users personal game engine, which if I remember correctly was c++.

hi js_software, The interpolation or tweening, is only available as a test mode, as is not even complete enough to be considered a feature yet. We will be expanding this into a full feature for 1.0. In it's current state, editting or animating where each key doesn't use the same set of sprites in the same order results in unusual program behavior, and it automatically tweens everything(tweening will be toggleable on a per object basis when it's complete. To enable the tweening test mode, press ctrl alt t

yes. that's fine. just please understand that the current format will be changed and expanded. but you're free to distribute your implementation however you see fit

what do you mean the "third post"? Please uninstall using the uninstaller in the installation directory, and reinstall using the latest download, and allow the DX and runtime installs, and see if it still gives you trouble: http://www.brashmonkey.com/spriter/SpriterBeta.zip

hey enoch we'll be doing general stability fixes in the coming months. but first thing, did you allow the dx and c++ installs during installation? also the installer was updated within the last week to integrate these. if you didn't download recently, please uninstall with the uninstaller in the installation directory and reinstall the new one. thank you

funny you should ask that now johannes but the recently completed procedural animation feature description document discusses linking feature further in. http://www.kickstarter.com/projects/539087245/spriter/