06-12-2012, 05:22 AM
Yup, it's indeed not a spriting program, but really just a sprite sheet manager. The main goal of the program for me,
is that the ".graphic" files it exports are serialized Java objects that can be directly loaded into a game engine. That
way, you can just tell the game engine to play eg. animation 2 or show eg. frame 5, and it'll know what do do, without
having to load in animated GIF's for every animation.
The point in the pipeline I see this program being useful is after the sheet has been finished or when a first prototype
is finished. At that point it can be used to preview more complex animations, generate an overview of all animations,
inspect individual frames for mistakes, palette errors, ... . If you have a game engine that works with animated GIF's
(I think GameMaker has an option for this) you can batch generate those. If you want to showcase your sprite
animations, you can use the GIF's as they are browser compatible and are color keyed.
Having all poses of a character organized in a fixed grid is a good way to store an entire sets of animations in a single
image. Most sheets on TSR have all poses of characters randomly scattered across an image. By randomly, I mean
they may be grouped per animation, but they aren't pasted onto the sheet uniformly. Some frames are a couple of
pixels off to the left, some to the right, ... etc. This means, if you want to create an animation out of them, you need
to re-position every frame manually. Grid-like sprite sheets don't have this problem as the positioning of individual frames
has been done for you. SmithyGCN has a great sort-off intermediate way of organizing his sheets. While he doesn't
fully fill up the entire grid, he places one animation per row, and leaves redundant cells to the right of rows open.
This way all frames are aligned perfectly, and he can yet keep an overview of how the animations are grouped.
Grid-like sheets are also usable in games, while non-uniform ones aren't. You could technically, for every pose define
where it is located on the sheet. The graphics manager of your game would require a lot of computations and cutting
out of pixels however. Graphics manipulations are costly in a computational sense, so a grid might be better. If you
say "show frame 5" of a grid sheet, you can immediately grab the frame, on an unorganized sheet, it's more difficult.
So, I'm an advocate of grid-like sheets, but then again I'm a programmer, not a spriter :p .
is that the ".graphic" files it exports are serialized Java objects that can be directly loaded into a game engine. That
way, you can just tell the game engine to play eg. animation 2 or show eg. frame 5, and it'll know what do do, without
having to load in animated GIF's for every animation.
The point in the pipeline I see this program being useful is after the sheet has been finished or when a first prototype
is finished. At that point it can be used to preview more complex animations, generate an overview of all animations,
inspect individual frames for mistakes, palette errors, ... . If you have a game engine that works with animated GIF's
(I think GameMaker has an option for this) you can batch generate those. If you want to showcase your sprite
animations, you can use the GIF's as they are browser compatible and are color keyed.
Having all poses of a character organized in a fixed grid is a good way to store an entire sets of animations in a single
image. Most sheets on TSR have all poses of characters randomly scattered across an image. By randomly, I mean
they may be grouped per animation, but they aren't pasted onto the sheet uniformly. Some frames are a couple of
pixels off to the left, some to the right, ... etc. This means, if you want to create an animation out of them, you need
to re-position every frame manually. Grid-like sprite sheets don't have this problem as the positioning of individual frames
has been done for you. SmithyGCN has a great sort-off intermediate way of organizing his sheets. While he doesn't
fully fill up the entire grid, he places one animation per row, and leaves redundant cells to the right of rows open.
This way all frames are aligned perfectly, and he can yet keep an overview of how the animations are grouped.
Grid-like sheets are also usable in games, while non-uniform ones aren't. You could technically, for every pose define
where it is located on the sheet. The graphics manager of your game would require a lot of computations and cutting
out of pixels however. Graphics manipulations are costly in a computational sense, so a grid might be better. If you
say "show frame 5" of a grid sheet, you can immediately grab the frame, on an unorganized sheet, it's more difficult.
So, I'm an advocate of grid-like sheets, but then again I'm a programmer, not a spriter :p .