lucid

Hello again everyone, Here's the second of our bi-weekly releases on our way to 1.0. As of now all reported crashes and bugs have been fixed, and we've added basic file saving and loading features to the new format. However, this new multi-platform Spriter is still in alpha, and things are still very early on, so bugs, including crashes should be expected. There is still basic functionality missing, such as copy and paste, and it does not yet track your changes and warn you before closing that you should save your file. We understand these things are essential for the program to be complete, but as promised in the Kickstarter, everyone is here with us on the ground floor, and things will gradually get more polished and complete as we approach our December estimated release date. This version is not to be considered stable, and one should not begin major projects with it, as of yet. Any brave developers who plan to or already have begun major projects with Spriter, we've purposefully been prioritizing functionality over polish, so Spriter can be more useful in the short term. But please, please save very frequently, to separate filenames, so there is always a backup to come back to. We've tested saving and loading extensively in house, but that is 2 users versus thousands. Again, please save frequently, and to alternate filenames, in case something goes wrong with a file, you have something at least semi-recent to fall back on. Now that the disclaimers are out of the way. The good news is in the changelog below, and also we have the basic groundwork layed for bones/heirarchy, so this feature should be coming soon in one of the next 2 updates. As stated in our last update, we plan to release a version roughly every 2 weeks, so the 1st and 15th of each month, give or take a few days. Over the next few days I'll be writing up some slightly more detailed documentation for developers working with the file format. But most of the developers who already implemented the previous file format, and/or participated in the discussion that ended with the final format should have little trouble. Also linked at the bottom of this post is once again the full format outline, as well as a compact version which only shows the features of the format currently implemented in the editor. Thanks again for testing everyone. Don't forget right now only the non-pro features are implemented, so encourage all your friends to come download the free version. We'll be replacing the official download page with this version in the next few days, but for now, the Kickstarter page, and our forum is the only place with these links. Change Log: Additions: [*:1excaqnd]Added basic file input and output to the new file format. [*:1excaqnd]Added a Playback Speed slider in the Timeline Window, to preview your animation at different speeds, including backward (-200% to 400% actual playback speed) [*:1excaqnd]Proper multi-object select with proper multi-object transform controls. Fixes: [*:1excaqnd]Fixed a crash when click-dragging the background before a file is loaded. [*:1excaqnd]Fixed a crash when dragging and dropping to reorder objects in the Objects in Frame window, when dropping objects below the lowest object on screen. [*:1excaqnd]Fixed several bugs where the objects weren't drawn in the correct order in the Canvas window, so the order in the Objects in Frame window didn't correspond perfectly with the canvas view. [*:1excaqnd]Fixed a visual bug where jumbled text appeared in the expanded object properties in the Objects in Frame window. [*:1excaqnd]Fixed several bugs where the tweened objects behaved strangely when dragging the timeline slider. [*:1excaqnd]When zooming with the mousewheel, it was impossible to get back to exactly 100% zoom [*:1excaqnd]Fixed a visual bug where keyframes weren't aligning properly with the timeline slider. This bug was much more pronounced on Mac and Linux, but should be fixed on all platforms now. [*:1excaqnd]Delete when several objects were selected didn't always delete all objects. Mac specific fixes: [*:1excaqnd]Fixed a visual error on Mac, when dragging and dropping to reorder objects in the Objects in Frame window, though the objects would reorder correctly, it appeared like the drop was being rejected. (animated sliding back to it's original spot) [*:1excaqnd]Fixed a bug on Mac that didn't let you expand object info in the Objects In Frame window by clicking the arrow. Miscellaneous: [*:1excaqnd]Several optimizations to improve performance while manipulating images in the canvas. Windows Download Mac Download Linux Download Monster Example File Compact SCML Format Outline (only currently implemented editor features) Full SCML Format Outline

Hi everyone, Just a quick update to say we're a tiny bit behind for the 15th as you may have noticed. Just wanted to clean up a last minute bug/optimization or two we discovered at the last minute. All that's left now is packaging things for release. Expect your new release tomorrow. Thanks for your patience everyone.

hi jmcmorris, as Mike said we'll have a pixel-art friendly mode at some point, but at this point where we're still adding basic functionality, it's hard to say exactly when it'll happen. There have been quite a few requests for this lately, so we'll take that into account after we get all the basics in, and we're prioritizing what to do next.

I've had some of the same ideas as well, and it'd be especially useful for more complex interactions like climbing a ledge. This is something that will come a little further down the line though, after we've got the basic stuff in, and we're moving onto procedural animation, since some of the same interface needs will come it it. Also, being able to tie the movement in with an existing body part or motion. For instance anchor the hand, so it, the characters relative movement say in, climbing a ladder, or jumping a fence would be determined by making sure the hand wouldn't move, but instead the rest of the character would move to accommodate that one part being stationary. I think it should be similar to bones and objects, with the with the same tweening/nontweening options, and not needing movements to be keyed at each mainline keyframe. Again for a ledge climb, it'd be necessary to have direction changes for it to be truly useful.

We'll probably hold off on the Mac app store until 1.0, and keep the alpha/beta via direct download.

hi t4udner all of the bugs and crashes you mentioned are fixed for the next version (8/15)

Minor change in the order of things. Moved and information above the information. Everything in will always be needed for "sprite" s within the tag, so anyone wanting to read the file sequentially and build a mirror data structure that refers to this information would have needed to read through the file twice. Also, corrected an omission. The tag was missing the "parent" attribute. Either on the next release on the 15th or shortly afterward, I'll publish more thorough documentation of the currently implemented(in editor) subset of SCML, as well a sample file.

glad everyone's enjoying it. Ray we're working on getting an up to date sample file in the new format. We aim to have this by the next release scheduled for mid-august

hi guys. I'll look into dragging on the gray background before a project is open crash the crash where you drag something in the zorder below the last item has been fixed for the next version. also in the mac version there is a visual bug, where it looks like it will reject the new position of the zorder(animates back to it's original spot in the list) even though the zorder ends up being correctly changed. This is also fixed in the next version. The save and load are purposefully disabled in this build, because they were too recently introduced just before release, and we knew most people(including ourselves) would ignore a 'please don't trust the save feature yet' warning. The next version will save. Also, timpart. We will have more tutorials and make it easier to discover on your own as time goes on. But in the Persistent Object window, you can drag two items together to combine them as one persistent object as long as they both don't exist on any frame together (such as the hair on the knight sample animation). You should receive a notification that the operation was unsuccessful if there are two instances on the same frame. On the knight animation in particular, unfortunately it switches from two body parts for one hand, to one part at certain points, so though the feet and hair can be properly fixed with the drag and drop technique the hand cannot. In future versions when we have a working hierarchy system, you will be able to do this.

Thanks guys. I'll try to get an eta on the C2 plug ASAP

surefoot. Mike was right, that bug was very recently introduced and is fixed for the next release

@robpearmain & nascode as for the Windows errors, I'll zip the next release, so at least a few less virus programs and browsers will panic that you're downloading an exe. And thanks for the tip about TexturePacker having the same issue, so I least know it's an ongoing problem with Norton in general. Charles. Yes we will expand the format spec document into full documentation. I'll be building and releasing that gradually over time, beginning with the basic features so people can start making implementations as soon as possible. For anyone else who's already made an implementation with the previous format, alot of it will probably be familiar.

MOMENTUM. That's the word that best fits whats going on here at BrashMonkey. First, as promised, the long wait for a new Spriter build is over. While not yet ready for production use, this new version is definitely something you don't want to miss. From this day forward, not only does Spriter run on PC, Mac, and Linux, but this build also introduces the foundation for Spriter's tweening support. Spriter's revolutionary interface for controlling what's tweened, and when, and it's asset usage tracking allows for an exquisite workflow that simply must be seen to be understood: Expect more innovation that makes animation and game design exciting and easy as Spriter continues to develop from this early state. More good news? Now that the foundation for this new cross-platform Spriter is finished, update builds with new features, tweaks and bug-fixes will be drastically more frequent, with an official update build at least once every two weeks. For those already using the previous beta of Spriter, don't uninstall it just yet, as this new alpha is not yet ready to take its place. Because this release is so completely new under the hood we've left out the ability to save to avoid potential loss of work. But fear not, with your help reporting any bugs, we should have this new Spriter running stable by our next release at which point we'll unlock the saving features. After that, top priority will be to add in the remaining features to make this new Spriter the ultimate game animating tool as quickly as possible. Skeletal Animation, you're next to be revolutionized! (image property of Code 'n' Web) And just when it seems Spriter news can't get any better, we're proud to announce that BrashMonkey will be collaborating with Andreas Löw, creator of the industry standard texture-atlas(sprite-sheet) generation tool, TexturePacker. The plan is to have texture-packer be able to export to a Spriter-specific format that can be embedded into your SCML file, and for those of you whose platform of choice already has excellent support for one of the many texture atlas formats Texture Packer uses, you'll be able to keep the atlas files separate, and Spriter will provide the necessary information in the output file to reference your TexturePack'd textures. (image property of Code 'n' Web) And Spriter itself is not the only thing picking up steam. With the final default data format revealed, all Spriter plug-in developers can get to work creating fully featured Spriter plug-ins for any and all game authoring systems and game engines starting immediately..meaning its highly likely fully features Spriter plug-ins will be ready for several game authoring systems even before the release of Spriter 1.0. So far it looks like we've reached a workable final file format and I encourage all developers to get going so we can all take the 2d world by storm. We'll leave this unmarked as final until the next release 2 weeks from now, so anyone can ring in with last minute suggestions, and we'll have a little more time to explain/discuss some of the new stuff, but any changes made in this final stretch should be insignificant to development time. http://brashmonkeygames.com/spriter/FinalSpecCandidate.pdf But that's not the last of the good news. Art Pack production is also about to get turbocharged! Several great artists have signed on with us to insure that not only will several art packs will be ready for the release of Spriter 1.0. but they will contain even more premium quality content. One of those great artists is a professional game artist you might know by the alias StOven. For years the visual quality of his sprite-work and his exceptional animating skills earned the respect and admiration of the entire game making community and his fellow game artists. We couldn't be happier to be working with him to make superior game art available to all game developers, no matter how small their budget. You can see his online portfolio here: http://spriteart.com/ (best viewed with Safari or Firefox) And here are a few samples of some of his past works: (past work by Stoven.. all characters are the sole property of their respective copyright holders) And finally, in closing : of the many developers who've come to us with their secret Spriter animated game projects, one project that's not so secret is an interesting 2d moddable sandbox game about to get funded on Kickstarter: Crea! By Siege Games (image property of Siege Games) (image property of Siege Games) Check them out at Kickstarter and spread the word if you like what you see. Thanks everyone for your extraordinary patience while we caught up this new version rebuilt from the ground up, you can all now look forward to regular updates, and we can all look forward to our impending 2d revolution! Oh yeah, and about those new versions: Windows OS X Linux OS X and Linux users, please let me know if there's an ideal way you'd like your releases packed from here on out, and I'll do my best to make it happen.

As of now, yes, all properties are keyed together. And like the speed curves, there's definitely room for expanding this in the future without breaking already working implementations.

Hi NateS, sorry for the late reply. unfortunately because release is in a few days I can't give a detailed answer at the moment, but the design, which will undoubtedly evolve is meant to balance several factors, including maximizing the ability to run all features in realtime on all devices, flexibility, and ease of use. Eventually, the format will be fully documented, and at that point supporting re-parenting will be trivial to implement. Spriter will save enough information to the file that there will be no additional math involved to reparent, so it should run efficiently as well. As far as choosing export options for different plugins and api's, we want to avoid differing export options as much as possible, and multiple versions of the file format, aside from the artist just not using certain features. We want to avoid fragmentation, and help establish it as a firm standard that artists and developers can trust to behave the same on all platforms. The less fragmentation will also facilitate the development of a healthy artist/developer ecosystem, where people can share art, implementations, and advice and tutorials on either regardless of intended target platform. This will work best if everyone can use everything anyone else created with little to no complications and where the target platform doesn't add additional requirements or specifics to learn. With the current file format you can do varying degrees of ease in or fast in, ease out of fast out, and combinations of them (not supported in the UI yet in this upcoming version, just the file format). You cannot do things like bounce curves between 2 keyframes, but you can approximate the same effect without any great effort with multiple keys and less processing power. I think there's enough flexibility to achieve the visual end an animator wants, while keeping the ui very out of the way and uncluttered and the required processing at a minimum. Also, the format is designed to allow for arbitrary expansion. For instance, the eventual sprite deformation is not mentioned in this format, and some procedural animation features, but I can think of several ways to add those features to the current format, which would only require additions to support the new features, but not any editing of already working parsing or processing code. So if the current speed curve system proves to be lacking, expanding it is definitely something we can look into at a future point. Thanks for the input. Also, there is a more up to date posting of the file format here: http://www.brashmonkey.com/forum/viewtopic.php?f=2&t=609

hello. sorry for the late reply. So far I've only tested it on my mac-mini, which is OS X Lion 10.7.3. I'm sure we'll know in a few days shortly after the next release.

Thanks timpart for your sharp eye. I fixed the errors, and updated the file. I agree about the tag/variables in meta_data and that is updated as well. Very busy until launch date in a few days, but I'll elaborate further on the documentation where you mentioned it was vague, and expand on the aspects you were questioning after this upcoming release

the new version should have much less compatibility problems

still the end of july. just the very end. doing our best to make this a great update up to the last minute

Hello everyone, The upcoming version of Spriter will be here soon. After our last discussion about the file format, I began rewriting the Spriter animation system to incorporate this new design. Using what I learned while implementing it, and everything we discussed, I refined and reworked from the previous spec. This is the final format candidate. I will incorporate or change anything high demand before the upcoming release. Please take a look, and give any feedback or suggestions you have. In the upcoming release, Spriter will be using a small subset(specifics on release) of the features of this specification. However, at that point the format will have been finalized, and developers will be able to begin to implement the entire feature-set of the format. The editor will catch up to the feature-set throughout the coming months, and of course be fully compliant with the specification. There will thorough documentation at some point, but for the purposes of this discussion, please review our previous thread linked above to gain a basic understanding, or to refresh your memory. Also, please feel free to ask questions about anything, even if we've covered it. Click here to view/download a basic guide to the format Also, one thing I'd like to point out if anyone needs clarification on the license: it's being released under the Modified BSD License. This means that there are very few limitations on how you use SCML. If you redistribute the format specification document itself, you must retain the copyright notice. You may modify the document as well, but it must retain the copyright notice, and you may not misrepresent Brashmonkey, LLC as being responsible for the modifications. You don't need to display the copyright notice in your game, and you are of course allowed to incorporate support for loading and displaying SCML into any software without our knowledge or permission, for free or for profit. Looking forward to your input!

Surefoot, the plan is for there to be a 'pixel art mode' at some point. This would allow you to edit(not just preview) with point sampling(pixellated, rather than smoothed when zoomed in). It will also save and edit with integer values for position and dimension. This means there is no such thing as (x,y)=(20.3,30.8), only exact integer values like 20, or 30 can be used, which will allow for the precision required when doing pixel art. Theoretically in this mode, you could also add visible 'point' objects, which would allow you to actually add a few pixels here and there to clean up or enhance the image created from the normal body part images. I'm not ready to give an ETA on ant of this just yet, as there is still alot of more basic functionality that needs to get done first. 1.yes,soon 2.yes,soon 3.yes 4.yes,soon 5.yes,soon 6.yes

both the efficiency (fan speed), and the resolution problem are addressed in the version releasing later this month

it is not supported currently, but pro features such as that will start appearing after the version that arrives later this month.

just popped in to say wow at the art for your game as well. love the style

there will be. Not this initial version, but soon after, and tweening is very near the top of the list