From jcso...@gmail.com on March 11, 2011 19:41:15
What do you need to do? Export animation info in an xml format for an animation created in ASE and batch save all the frames of an animation as separate images. How would you like to do it? Add an export animation to the file menu.
Original issue: http://code.google.com/p/aseprite/issues/detail?id=17
The text was updated successfully, but these errors were encountered:
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 Carduus....@gmail.com on November 29, 2013 05:42:49
Export frame timing would be soooo nice !
By the way thanks for this amazing soft!
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).
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).
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:
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.
The result is as follows:
Problem 1: Designer must remember to uniquely tag the animations across all ase files (minor)
(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
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:
Problem 3 Locating the static sprite by name as an ugly name
Hi @dagostinelli, indeed I've never thought about
It might be a good solution when multiple sprites are specified
I'd prefer the
To fix this I think you might use the