Do you throw away the frame information when you generate an animated sprite sheet?
Do you throw away the frame information when you generate an animated sprite sheet?
I'm quite new here, and I recently posted a question in the Programming forum asking how, if I want to make use (in a game) of an animated sprite sheet like this gorgeous blob by Redshrike --
http://opengameart.org/content/the-blob-ultimate-smash-friends (the blobsheet_0.bmp sprite sheet)
-- I'm supposed to work out precisely where the frame boundaries are for each animation, and, if any frames are repeated in an animation, the order in which all of the frames should appear.
In the past I've used a sprite packer program, which takes all of the individual frames of an animation, then saves them to a sprite sheet like the blob one above, as well as generating a text file that contains information on the dimensions of each frame, and which frames belong to which animation, and in what order. The sprite sheet looked very like the blob sprite sheet in the link above... but, in the uploads that I've browsed through on opengameart.org so far, I haven't found any accompanying frame information.
When I asked the question in the Programming forum (where I explain the issue in a bit more detail), I was hoping and expecting that this kind of information was hidden somewhere, and that I was just failing to recognise where it was -- but the two people who have answered so far have said that they've had exactly the same problem, and have had to resort to splicing the sprite sheets manually, using a bitmap editor and guesswork.
The bitmap editor+guesswork approach is always an option, but it takes a lot of time and effort (for someone who is more adept at coding than art) to work out, in single-pixel precision, exactly what the artist intended for each frame. It feels as if we're trying to reverse-engineer some closed-source, proprietary bit of of art that we've ripped nefariously from the resources of a game, rather than using an ostensibly open-source art resource, which I think is what this site is intended for.
If you're an artist who makes animations and produces sprite sheets like this, do you use a sprite packer program to generate your sprite sheets? If so, does that program, along with the sprite sheet, generate a text file or some other file, which might contain information on the animation? If so, it would be really helpful if you could upload that file along with your sprite sheet: it would make the lives of programmers wanting to incorporate your art into their games so much easier.
OR, if you don't get a file like that, and you were presented with a sprite sheet like this blob example, and you wanted to get that back into a form in which you could see all of its animations running, what would you do? Is there some technique (or information embedded in the sprite sheet) that has eluded me and the other programmers?
You seem to have gotten largely complete answers (though probably not the ones you wanted to hear) in the other thread. However, I think it's worth leaving one comment here just to summarize and make it clear.
{1} No, there's no magic information sitting around somewhere that you're missing. Sprite sheet animation frames are generally arranged implicitly, not explicitly.
{2} There's typically more than one valid sequence of animations in many, if not most, of the more advanced sprite sheets. For those, it's impossible to determine in advance what the "correct" sequence is due to the multiple potential answers. Describing every potential answer can also get unwieldly due to the exponential growth of the combinations.
{3} For small-time work, it's normally an understood and expected responsibility of the developer/programmer, not the artist, to devise the method, structure, and sequence of the animations to be actually used in-game. At least, this isn't something that an unpaid artist is reasonably going to do for you.
{4} There are algorithmic methods of breaking semi-irregular (rectangular, but not necessarily equally sized) frame blocks apart into constituent frames, and then reassembling them in different orderings. However, the algorithm generally needs to be specialized at least slightly for each particular use case. It further relies on the construction of the sprite sheet following a few obvious rules, including the use of a consistent identifiable background color, a mandatory minimum spacing between frames/blocks, and some locality of reference/context (grouping related object frames closer together).
It's possible to save a substantial amount of time (hours, perhaps days) by writing or tweaking an algorithm that disassembles and reassembles the sprite sheet instead of manually moving/cut-pasting every last frame individually in an image editor. The amount of time saved really depends a lot on exactly what you're trying to do, though. The more animations that will be constructed from the same tile/frameset, the greater the savings can be. The better integrated the algorithm is with the final result required by the game engine, the more time saved. (And so on, for just about every factor imaginable.)
One last note is that a lot of games and game engines likely insert one or more intermediate formats and tools between the input stage (a loosely assembled sprite sheet or whatever the artists are generating) and the final output stage (which is interpreted by the game engine directly). By adding another format and manipulation tool in the middle, it's possible to delegate the work of animation construction to somebody who's neither artist nor programmer. This is talking serious company business, though; most indies and hobbyists aren't going to bother with any such formal abstractions since they don't have extra labor to throw at the problem anyway.