RunnerPack

It's probably already in this huge list somewhere, but I would really appreciate it if right-clicking on the play button would just stop at the end instead of auto-rewinding. It should probably be optional (in case I'm the only weirdo who wants it this way ;)). EDIT: I forgot to mention the dilemma of how to handle right-clicking when the head is already at the end of the time-line. You could have it restart from the beginning, but sometimes it might be nice to be able to go from somewhere in the middle to the end. In that case, you should probably save the head position when play is right-clicked, and rewind back there if it's right-clicked again with the head at the end. Just my two cents...

Get VirtualDub. It's FOSS and very powerful, yet easy to use – especially for simple things like trimming a video to a certain length, cropping/rescaling it, and compressing it. If you install it and can't figure it out, send me a private message and I'll walk you through it. BTW, you hit the nail on the head regarding the way Spriter uses (and doesn't use) the RMB.

Nice plant! Here are some ideas you can use, if you want: 1. Make an "idle" stance, where it tries to be "inconspicuous" while waiting for something to wander into range. 2. Make it bite straight down on its "prey". 3. Add a "swallowing" animation.

(Sorry for double-posting...) These might already be on the "todo" list, but I think there are some problems with the new "hiding/locking" mechanism. Currently, only selected items can be hidden, shown, locked, or unlocked. However, once you've hidden/locked something, it can no longer be selected. Thus, you cannot show/unlock individual items. As it stands, you have to unlock and show all items, then manually hide/lock everything you still want hidden/locked. Suggested solutions: [*:1ohwu6eh]Add a right-click menu to the Hierarchy and Z-order lists. [*:1ohwu6eh]Right-clicking a locked object should show a menu with only "Hide this object" and "Unlock this object" options. Other suggestions: [*:1ohwu6eh]Right-clicking an unselected object should make it the only selected object, then bring up the menu. [*:1ohwu6eh]If nothing is selected, the menu should not include the "...selected objects" items.

When I first start Spriter, and load/create a project, the right-click menu pops up when I use the middle (wheel) button to pan the view. It also starts happening after you select one of the right-click menu items. In either case, when you left-click the canvas, it stops happening. (Windows 7 Ultimate 64-bit, generic Logitech USB 3-button mouse. I have a Logitech M310 wireless coming in the mail; will test again when it gets here)

I just thought of a great feature for the Spriter format: clipping rectangles! (Apologies in advance if someone's already suggested it :oops:) Since you already have rectangle primitives, all you need is a special axis-aligned (i.e. can't be rotated) subclass of that. When an image or sub-entity* is made a child of this rectangle, only parts of said image/entity that coincide with the rectangle will be drawn. I don't have much experience with C2 or the other "game authoring systems" you're targeting, but most low-level 2D rendering libraries I've seen (e.g. Flash/AS3, SDL, libgosu) have included a mechanism for clipping graphics primitives to a rectangle, so implementation should be quite simple. While I realize this could be implemented at the renderer level using the current rectangle primitive, I feel it is both useful and powerful enough that the ability to preview the effect in Spriter in real-time would be worth adding. * (IMO, sub-entities should be called "components")

The best way to fix missing MSVCR*.DLL problems is to install the latest official VC++ Runtime Redistributable package. Due to things like 32/64 bit systems and multiple languages, it's no longer as easy as putting a DLL in the "system32" folder (not to mention the possibility of getting an infected one). As a stop-gap, you might try putting the DLL you found in the same folder as the Spriter executable itself. You might also want to have virustotal.com scan it for you, while you're at it.

@loudo: this is just a shot in the dark, but maybe a generic XML merging program (or XML editor with merge function) would work. I don't even know if such a thing exists...

I am by no means a professional animator, but a couple of things I noticed are the scarf thing Mike mentioned, the head/eyes, and the feet. The inner ears and eyes provide most of the balance and orientation information to the brain. When a person runs, the head – within which these four organs are mounted – should be the most stable part of the body, remaining level and moving only up and down, not rotating, smoothly, as if mounted on a spring. The eyes themselves are usually more-or-less fixed on a point some distance ahead, so they really shouldn't be bobbing around like that. At best they might do a slight (i.e. a few pixels) up/down slide, in sync with the footfalls, to compensate for the body's (and head's) up/down movement. The foot issue has been mentioned elsewhere on the forum a few times: feet have to bend at the "ball" to give the front of the foot more time to push against the ground as the body moves forward, changing the angle of the leg. You can either draw a few bent feet to choose from, or cut the foot up and add more bones.

Since there really is no "camera", per se, you just have to move everything else. E.g. if you want to pan left, move the whole sprite to the right.

You could use a dummy image in place of the "circle" which has the same alpha channel, but all one, solid, unique color (i.e. one which appears nowhere else in the animation; "magic pink" – #FF00FF – is a popular choice) and then use a (semi)automated process to erase it from the exported animation; i.e. a "color replacer" tool in PS (I don't use it, so I don't know if it has one or what it's called) or ImageMagick. Essentially, you'd be using a form of chroma-keying.

Nicely done, Tagmonkey! The only thing I'd add is some motion to the facial hair. Otherwise, it's perfect.

ilimi, Have you read my thread about MessagePack?

FYI: when I click the "Start" button, it almost instantly crashes my browser (Opera 12).

I'll get this one, guys... You seem to be asking for the "Skin" system, which is already implemented, albeit not quite ready for production use. You can find a video about this feature on the BrashMonkey YouTube channel. I can't figure out the youtube BBCode, but here's a link to .

Thanks for the information and updates, finscn. I'm definitely looking forward to the "good enough" version, because this prototype is already excellent!

Nice work, finscn! BTW, it works fine in Opera 12.17 (and probably the newer WebKit-based ones, too), although maybe a little slowly. Are the animations supposed to be going as fast as in Spriter itself, or have you slowed them down? If you're not already planning it, maybe an FPS counter would be a good idea. EDIT: I just tried it in Chrome, and it goes the same speed. EDIT2: I checked the files and there's no copyright or license info. Is this public-domain?

Have you checked out the "View" menu? Try "Restore Zoom (Ctrl+Alt+Shft+Space)". Are you just suggesting a tool-bar button be assigned to this function? Since any given image can be scaled up or down, it's not possible to have one zoom level that shows each one at its original size, but AFAIK, "Restore Zoom" shows unscaled images at actual size.

Add my vote for all of these, as well as quick keys/buttons for 90° rotations (and please assign "H"/"V" to flips and "L"/"R" for rotations).@Tumira: a work-around for exact flips is to negate the value in one or both of the scale boxes, under "Object Properties". E.g. (-1.0, 1.0) would be a horizontal flip (but it would work with any existing scale value).

No offense, 8DashP, but what does your rambling post comparing XML with JSON have to do with the topic of the thread? Other than an offhand remark about how it might not be better than JSON, you didn't mention MessagePack at all. Did you even try MessagePack on a Spriter file to see how it compares? I was curious, so I did just that. I modified the above Ruby conversion script to add speed profiling (posted below) and ran it on tombmonkey's "Mantis Girl" (converted to .SCON using b7pre3), and I got the following file size results: Original SCML: 3,655KB test.scon (Spriter): 5,330KB test.mp (MessagePack): 1,566KB test_out.scon (Ruby): 2,231KB The "test_out.scon" file – converted from the MP file by the Ruby script – loads and works perfectly in Spriter. Now for the speed comparison. Running the script (in 32-bit Ruby 1.9.3p374 on my i5-3570 under 64-bit Windows 7) produced this output: MethodProfiler results for: JSON +------------+------------+------------+--------------+------------+-------------+ | Method | Min Time | Max Time | Average Time | Total Time | Total Calls | +------------+------------+------------+--------------+------------+-------------+ | .parse | 194.011 ms | 194.011 ms | 194.011 ms | 194.011 ms | 1 | | .create_id | 0.000 ms | 0.000 ms | 0.000 ms | 0.000 ms | 1 | +------------+------------+------------+--------------+------------+-------------+ MethodProfiler results for: MessagePack +---------+-----------+-----------+--------------+------------+-------------+ | Method | Min Time | Max Time | Average Time | Total Time | Total Calls | +---------+-----------+-----------+--------------+------------+-------------+ | .unpack | 48.002 ms | 48.002 ms | 48.002 ms | 48.002 ms | 1 | +---------+-----------+-----------+--------------+------------+-------------+ So, for the specific case of Spriter files loaded in Ruby, it looks like MessagePack is a winner in both size and speed. Here's the profiling script: #!ruby require 'json' require 'msgpack' require 'method_profiler' basename = 'test' # Parse .SCON, save MessagePack profiler = MethodProfiler.observe(JSON) File.open("%s.mp" % basename, "wb") { |out| out.write(MessagePack.pack(JSON.parse(IO.read("%s.scon" % basename)))) } puts profiler.report # Unpack MessagePack, write .SCON profiler = MethodProfiler.observe(MessagePack) File.open("%s_out.scon" % basename, "w") { |out| out.write(JSON.generate(MessagePack.unpack(IO.binread("%s.mp" % basename)))) } puts profiler.report tl;dr: Compared to SCON, MessagePack files are about 1/3 the size and load in 1/4 of the time (in Ruby).

I have another one: I tried exporting PNGs at 33.3333% (1/3) size, and the images came out "stacked"; i.e. each frame consists of all previous frames with the current one drawn on top, as if the buffer isn't getting cleared before drawing the next frame. I don't know whether it happens with other scale factors, but 100% comes out fine.

Then a character map with no targets makes no sense to me. Why should Spriter save such a useless character map? According to this post, an image with no target means "hide it" (i.e. "replace it with nothing"). When you want the default image, just leave that image out of the map entirely.

If you have Ruby installed, you can use this nearly one-liner: #!ruby require 'json' require 'msgpack' File.open(ARGV[1], "wb") { |out| out.write(MessagePack.pack(JSON.parse(IO.read(ARGV[0])))) } Note: You'll need to 'gem ins msgpack json' first. This was only tested under Ruby 1.9.3 in Windows, and even then not extensively, so BACK UP YOUR DATA! EDIT: Found a bug; it was writing the output as text, but it needs binary (the little "wb" in the File.open call).

While doing research on JSON, I stumbled upon the MessagePack format. It's a binary object serialization system with support for quite a few programming languages. It compares favorably in both size and speed with JSON and XML (which isn't surprising), so it seems a good fit with video games, where loading times are to be avoided like the plague. I know you guys can't start throwing in every possible file format, but if you ever decide to do a binary format (perhaps one that incorporates the image/sound data itself?), this might be one to take a good, long look at. Even it it doesn't get built into Spriter itself, it might be of use to a few of my fellow Spriter users. :D

It might be too late in the game for this, and it would probably interfere with current and future IK code. It would even be a bit troublesome to incorporate into the GUI, but I think it might be worth it... Here's my idea: the "inherit" values (rotation and scale) of a bone should be numerical values instead of booleans. Basically, they would represent what fraction of its parent's rotation/scale is applied to a given bone. A good choice would be a float, so that the range 0.0-1.0 would equate to the existing "range" of false-true. A percentage would also work. It shouldn't be clamped to 0-1, though; negative values or values greater than one might produce some interesting effects... The main use I can think of for this is to help with flexible things like tails, whips, backbones, etc., but you never know how useful a tool can be until you make it and get it into the hands of a large user base, right? (Case in point: Spriter itself!)