From davidcapello on March 11, 2011 15:39:22

Owner: davidcapello
Labels: -Priority-Medium Priority-High Milestone-0.9

From chriswil...@gmail.com on November 25, 2013 02:23:25

Is there a specific XML format in mind, if not could this be JSON, which is faster/easier/lighter to parse and use more commonly for modern animation.

From davidcapello on November 25, 2013 11:07:07

Not yet, if you have some ideas for different JSON formats, it would be great. I remember to see that there are a lot of different formats (mainly for texture atlases).

More info: http://www.codeandweb.com/texturepacker http://renderhjs.net/shoebox/ TexturePacker uses Grantlee templates to export files, so that could be handy to support several formats (XML, JSON, YAML, etc.)

From davidcapello on November 25, 2013 11:12:07

More: http://esotericsoftware.com/spine-json-format/

From Carduus....@gmail.com on November 29, 2013 05:42:49

Export frame timing would be soooo nice !
We're using Starling format(Sparrow), but we will use a custom parser so any format would be great
at the end we want the tile sheet(png) its atlas (XML/JSON Whatever)and the animation timing(XML/JSON/whatever).

By the way thanks for this amazing soft!

From davidcapello on December 05, 2013 11:09:29

Status: Started

From davidcapello on December 08, 2013 15:27:13

I've committed something in 'dev' branch to start with: f531f6d You are able to export one file (or several files) to one texture file. For example:

./aseprite.exe --batch --sheet out.png --data out.json test.ase

This load test.ase file, and generates a couple of files. The sheet, out.png, contains all frames in a row (like a sprite sheet), and metadata, out.json, has all the animation info (look the attached file in this comment).

Also you can use something like this:

./aseprite.exe --batch --sheet atlas.png --data atlas.json images/.png images/.ase

That will create a texture atlas with all your images and animation frames. (Sorry but the layout of images is really simple at the moment, there are a waste of space in the texture.)

Please make comments about what you think, and I'll be uploading a beta for Windows today (it is really unstable).

Attachment: out.json

From davidcapello on December 13, 2013 04:23:52

I've release a command line version beta for Windows http://www.aseprite.org/cli/ You can try it and write comments here.

From davidcapello on February 24, 2014 03:15:44

Issue #179 has been merged into this issue.

From davidcapello on April 09, 2014 18:06:56

Labels: -Milestone-0.9 Milestone-1.0

From davidcapello on April 09, 2014 18:09:29

Labels: -Milestone-1.0 Milestone-1.1

There are new command line options to export a texture atlas: --sheet-pack, --sheet-width, --sheet-height. Anyway we cannot choose other formats yet (and there is no GUI at the moment, just the CLI).

What I would really like to see is the option to export sprite sheets into most standard sprite sheet formats of different game dev libs. It would be a bit of effort to get all the variants to run smoothly, but you would be quite the boss for offering that functionality.

There is a tool that can do this, called TexturePacker. If you try the free version you can get an overview of the formats it supports.

I was trying to use that tool to export to cocos2d-x's plist format, which has two different sprite sheet versions: One for a collection of frames and one for animation of these frames. Unfortunately TexturePacker only supports the first one, so there is literally no tool available on Windows platforms that is able to write cocos2d-x compatible animation.

I'm about to roll my own converter from Aseprite's json format to cocos2d-x's animation format, but it would be really cool if you could offer different formats for the most popular libs. Again, please take a look at what TexturePacker has to offer to get an overview about how much effort that would introduce.

Maybe you can implement some way for the community to write own converters with a scripting language of your choice. That way everyone can contribute with their own converter function and you would have much less effort maintaining the conversion if the format should change.

I might be able to help out with the conversion to cocos2d-x since the format is quite straightforward (basically xml based key-value pairs).

Hi @Cerno-b, I know TexturePacker, but I've never tried it. Each time I think about this, the scripting capability appears on my mind and it's good to know that you though the same (possible) solution.

Anyway a integrated template system would be the best solution (and possibility to use the template system from scripts).

This is related to #126, #138, #382, #475

Some tasks:

• find a template engine for C++ (e.g. ctemplates, or see this comment)
• depending on the templating engine, document how to create new templates
• create two templates for current json-array and json-hash outputs
• create a couple of new templates for cocos2d-x plists
• change the CLI option to choose the template name
• change the GUI option to choose the template name

I really like the idea of doing this via templates since it's a great way to handle for non-programmers. It might be neat to offer some place where people can put and rate their templates for different gaming libs. (e.g. wiki on the aseprite website or external online resource).

Concerning cocos-2d-x, I read into the matter some more and apparently you need two plist files for your animation. One contains the frame images including sizes and meta information, the other is just a collection that groups frame images into an animation and ties them to a name and a frame rate.

It's actually less fancy than I initially thought, since apparently you can only set the frame rate globally, not per frame. Anyway, my point is that the template mechanism should allow outputting multiple files.

Just as a starting point, the following information would have to be exposed to the template engine to create cocos2d-x animation files:

frame file:

• frame name (usually generated from sprite map name and a number)
• position and size of each frame in the sprite map
• image size of each frame (would be the same for all frames in your case)
• pixel format (e.g. RGBA8888)
• sprite map size

animation file:

• animation delay
• animation name (e.g. loop names). The file can contain multiple animations (i.e. each Aseprite loop can become a separate animation)
• list of frame names (see above) that make up the animation

There are some more values that can be filled (e.g. rotation if you want to pack your sprite map tightly), but from my limited understanding they can be left as default.

I'm just starting off with cocos-2d so take everything with a grain of salt. It's possible that people tend to write their animation.plist files by hand since the format is not very complex. It's also possible that they organize their images in multiple sprite maps but use one large animation.plist for the whole game.

Maybe someone more proficient in cocos2d can comment on this.

I'd like to suggest that this be raised a bit higher in priority. The current state of the texture atlas export is of limited use. Let me explain....

Imagine 3 sprites. 2 animated birds flapping their wings. 1 smiling face, not animated.

aseprite -b jay.ase robin.ase smile.ase --trim --sheet-pack --list-tags --list-layers --sheet atlas.png --data atlas.json

The result is as follows:
atlas.txt

Problem 1: Designer must remember to uniquely tag the animations across all ase files (minor)
At first I named my animations "flying" in both .ase files. I could also have "idle" and "pecking". The sprite sheet packer gave me two animations both named "flying". It was impossible to then figure out which frames to go grab with this. So going back to the .ase files, I renamed the tags with a prefix and ended up with "jay_flying" and "robin_flying". This at least gives me a prefix. But that brings me to Problem 2.

(also Layers are mixed together making them tough to match to their original sprite)

Suggestion for Problem 1 How about creating a section called "sprites" with a list of "Sprite" objects? Each Sprite object would contain a name, a list of frameTags (and layers and so on) that go with. This would let us avoid prefixing the tags. Perhaps the sprite name can come from the command line or the .ase file name.

Problem 2: Ineffective ID numbers to lookup frames of the animation
Looking at frameTags, I have "jay_flying" and "robin_flying". The frame for the jay flying are frames 0 to 5. Using this information is barely enough to uniquely identify the frames of the animation. You have to know that the files are called "robin", so they match the frameTag prefixed with "robin". But that's only because I solved Problem 1 like this.

Suggestion for Problem 2 How about uniquely ID every frame in the file and then specify the list of unique frame IDs under the frameTag. Like so:

"frameTags": [
   { "name": "jay_flying", "frames": ["jay_001", "jay_002", "jay_003"], "direction": "forward" },
   ...
  ]

Problem 3 Locating the static sprite by name as an ugly name
This is more of a preference. The non-animated sprites are ID'd using their literal file name. In this case "smile.ase" is ID'd as "smile.ase" in the JSON. I'd like it to be just "smile". (Minor thing)

Problem 1: Designer must remember to uniquely tag the animations across all ase files

Hi @dagostinelli, indeed I've never thought about --list-tags and --list-layers with multiple files. They are options to be used independently for each file. E.g. when you want to list the tags of jay.ase file you should use --list-tags for jay.ase only. Then you can post-process all resulting JSON files to create your own JSON data for your game.
For example:

aseprite -b jay.ase   --list-tags --list-layers --data jay.json
aseprite -b robin.ase --list-tags --list-layers --data robin.json
aseprite -b smile.ase --list-tags --list-layers --data smile.json
node generate-data.js

Where generate-data.js will merge all JSON data in one output-data.json file.

How about creating a section called "sprites" with a list of "Sprite" objects? Each Sprite object would contain a name, a list of frameTags (and layers and so on) that go with. This would let us avoid prefixing the tags. Perhaps the sprite name can come from the command line or the .ase file name.

It might be a good solution when multiple sprites are specified --sheet, I'll take note about this. Anyway I'm not sure if it would be good to change the current format, it might break compatibility. Maybe other --format when templates are already available. (Also there is some progress in a scripting API, which might be the latest replacement for all command line options.)

Problem 2: Ineffective ID numbers to lookup frames of the animation

I'd prefer the sprites section or identifying frames from the frameTag name. I don't think that a frame number should be a string.

Problem 3 Locating the static sprite by name as an ugly name

To fix this I think you might use the --filename-format option. For example:

aseprite -b --filename-format "{title}" jay.ase robin.ase smile.ase --trim --sheet-pack --sheet atlas.png --data atlas.json

https://steamcommunity.com/app/431730/discussions/0/1741105805742397201/

aseprite/api#12 is related to this.

Like @dagostinelli I was hoping to use --batch --sheet-pack --sheet --data with multiple .ase files as one big atlas. I also found out that the required data just isn't there because of how the frames are encoded.

I was hoping this would be an easy way to set up a workflow for PhaserJS, Tiled, and Aseprite. But seems I'll have to build more of it myself. Either with a Lua --script, or exporting each .ase file separately.