Spriter Alpha version A3

[lucid]

Hello everyone,

Once again we've reached our roughly bi-weekly Spriter Alpha build. We have some big things coming down the pipe next update, including bones. After that the remainder of features should be 1 or 2 updates behind. From there, its just getting all the basic things that are missing or disabled currently, and fleshing out the interface further to make everything work more smoothly.

Changelog:

Fixes:

[*:1m27vr2u]Fixed some issues where not all components of Spriter were aware of frame changes, which could cause some instability in rare situations, but would more likely/often cause strange or unexpected behavior.
[*:1m27vr2u]Fixed the issue where zooming in the canvas also zoomed the transform controls
[*:1m27vr2u]Fixed several crashes and a file corruption issue (which would cause program crashes after loading) all dealing with deleting keys
[*:1m27vr2u]Fixed a crash that would occur when dragging a key over another key under certain circumstances
[*:1m27vr2u]fixed a bug where saving while objects were selected would cause the selected objects to save to incorrect locations.
[*:1m27vr2u]fixed : opacity information wasn't being saved
[*:1m27vr2u] Spriter now correctly saves the width and height attributes to the structure
[*:1m27vr2u] Fixed a bug where deleting all instances of a persistent object would leave behind an unusable empty object, Spriter also now automatically destroys these empty persistent objects when you load a project from the previous version where this happened.
[*:1m27vr2u]Fixed several sources of instability dealing with object selection and tweening when scrubbing the timelines or dragging the keys.

Additions:

[*:1m27vr2u]Basic Copy/Paste of keyframes and objects. More options such as paste an object to all frames, or copy/paste of multiple keys, coming soon.
[*:1m27vr2u]Timeline widget is more fleshed out with status bar tips, tool tips, and grouped categories for controls.
[*:1m27vr2u]added a repeat on/off button for animation playback (when playing back in the editor, this decides whether the animation will repeat over and over when you press play, or only play once)
[*:1m27vr2u]added a loop on/off button for setting the actual looping properties of the animation itself. This alters the animation itself, and the saved file to indicate whether an animation should be looped at game time, or just played once.
[*:1m27vr2u]Added an Add Key button to the timeline window
[*:1m27vr2u]Spriter now remembers the last file path used, so when saving the dialog path defaults to the last used one
[*:1m27vr2u]Added basic 'Export to .PNG Sequence'. For now it exports only each keyframe in an animation. In the future it will be expanded to allow much more flexibility like setting a frame rate to get tweened frames from between keys, and many more options.
[*:1m27vr2u]Completely revamped the drop-down info for Sprites in the Objects in Frame list when you click the arrow next to a sprite. You no longer have to click a specific property like 'x' or 'opacity' to open up it's editor. All editors are always present once you expand the sprite info. Incidentally the underlying code was changed as well resulting in better performance and also fixing several sources of instability.
[*:1m27vr2u]Did some general restructuring for more efficiency in the code for Sprite objects. Uses a little less ram, and runs a little faster now.

In other news,

implementations of the final file format are starting to appear!

implementation in Scheme by Brian Taylor - https://github.com/netguy204/gambit-gam ... priter.scm

early implementation in Cocos2D by @TacoGraveyard - https://t.co/xIe7CQsz

and there's a Spriter plugin for Scirra Construct 2 I recently started working on. You can view it in action here. This is running pure HTML5/javascript with no browser plugins.

I've been in talks with Ashley Gullen of Scirra, and we're working on the best possible solution for the plugin to integrate with Construct 2 in the most streamlined possible way, allowing for Spriter folder structure import with the same ease you can currently import sprite images.

Thanks everyone for testing! If you're making a Spriter implementations, or using Spriter in your game, please let us know about it. Have fun:

Spriter Alpha version A3:

Windows

Mac

Linux

Example Spriter (*.SCML) file

Guide to developing SCML implementations

[bjadams]

Thumbs up for the C2 integration. Love that.

Have you talked directly with The Game Creators to try to implement Spriter support as a native command set with their AGK 2D toolkit?

[XtraTrstrL]

Nice work! Can't wait for the inclusion of bones.

[soho54]

Nice update. It seems to have fixed all my initial Alpha issues.

One question though... what happened to being able to move the objects a pixel at a time with the arrow keys? Is it because of the way the new bone system will be implemented? I only ask because I am still fine tuning the structure of my characters, and had initially set them up with this feature in mind as a fall back point.

[PR Simmons]

Thanks for the update!

Do you have a target for when you're planning to implement the UNDO function?

[timpart]

Alpha 3 crashes quite a lot for me on Windows 7, more so than recent builds which didn't crash at all. I can't see a particular pattern. Once I put mouse over the put a frame here button, another time I used the move to next frame on timeline button, but most of the time these don't have a problem.

When exporting to PNG the status message has two problems

a) The number in the message is out by one, for instance when exporting the final frame it said “Exporting key frame 9 of 10â€. I suspect this is because the images are numbered 0 to 9.

b) The final “Exporting...†message hangs around after export has completed, giving the impression that is still going on. Perhaps add a final “Exported 10 frames†message.

When I have a long timeline (900ms) I find it hard to work out exactly where I am on it as there is no number shown saying what time I am positioned on, nor any numbering on the line. My mouse doesn't move finely enough for me to put it on particular points, so I wasn't able to position it on a tick mark much of the time. Perhaps a numeric box showing the current position which is tweekable in some way?

As a result of the previous paragraph I discovered another feature when I looked at the resulting SCML file. I had started by putting in a tweened object on a frame at the start of the animation and a frame at the end. (It was doing a rotation by a known amount). I then put in intermediate frames with a non tweened object which was rotated by the correct amount so I would have test of tweening. When positioning the frames I misjudged where I was on the timeline and got one of them on the wrong tick on the line, and I didn't notice until I'd put another one on. As I'd already typed in the right angles for both these frames I didn't want to delete them. Instead I moved the frames on the timeline to the correct position. (Or as close as I could get.) I later looked at the SCML file to check I'd got the right timings as some still looked out of place. It was at this point I discovered the feature.

When a frame is inserted into a timeline where there is a tween spanning the timeline position, Spriter splits the tween at that point and stores the values of the tweened variables. If the key frame is moved the tweened values don't change, and what was a linear tween becomes non linear. So basically the positions are preserved but the timing isn't when a frame is moved. I can understand that this is desirable much of the time, but when there is a “surrounding†tween around a more detailed piece of action it could prove unwanted. Might it be better to have some way of saying “This is a defining key frame for this tween†by noting where the user changes the positions and recalculating intermediate frames when they are moved?

Regards,

Tim

[lucid]

@PR_Simmons not this coming update most likely, but the next

@timpart - I know exactly what you mean about the tweening. That's currently just a limitation of the editor, but the format already supports that. In a future version, it will stop auto keying all objects on a keyframe, unless you move that specific object.

as for the instability. I'll put out a hotfix in the next day or so that fixes a few crash vulnerabilities introduced in this build. All the one's I'm aware of so far are already fixed for the hotfix. If there are any others I'd like to try to get those as well:

[*:2sit9tx3]deleting keys when the key is exactly at the currently displayed time leaves the UI in an unstable state, where doing certain things can crash it
[*:2sit9tx3]using the next and previous buttons when in between keyframes was causing a crash
[*:2sit9tx3]there was a type of file corruption from key deletion in the previous version that the editor wouldn't detect, and would cause crashes. The hotfix will automatically detect and fix the issue(without crashing), and it will fix the file when saved again. If you're having crash issues besides the above with a custom character, see if you still have them with the monster example file