I want to talk about a new RELOAD-based graphics file format.
Previously I think we overcomplicated suggestions. A more powerful and
generic animation system might actually be worse if it's harder to
understand and use. And we don't actually need to design everything up
front. Animation details, font and tileset specifics, etc, can be
added later thanks to the magic of an extensible file format.
Supporting bigger and more frames is a good starting point; I want to
leave custom animations until later.
I decided to actually write some code instead of only talking things
through forever. It certainly helped. It seems obvious to me now that
we want to start with de/serialisation of Frames to RELOAD nodes. Of
course the bitdepth can be variable, to support 24/32 bit graphics.
Currently I've got 8 bit Frame de/serialisation; we could add 4 bit
too for space savings (though only 2MB for SoJ). Previously we were
cautious about putting image data in RELOAD, but my actually written
code shows it's no problem at all. For example reading a RELOAD doc
with 15MB of backdrops and writing it back out took <50ms.
Notice that a Frame is independent of palette information, and doesn't
even know whether it's an 8 bit or 4 bit sprite. And it makes most
sense to store palette information (default 16 colour palette, and/or
master palette number if we support using multiple master palettes at
once) only for an entire spriteset rather than per-frame because all
frames should share a palette.
We had a long 37 email discussion on a new graphics file format in
2010 ("better palette options"), which was largely about animations.
You can still see the proposed file format David wrote up here; I
think the animation part of it is still useful. It was definitely far
too complicated though; it's almost Turing complete!
https://gitorious.org/nohrio/nohrio/source/tools/lumpdefs.yaml
Then James asked about the following usecase, which really dumbfounded
me because it seemed like our marvelously complex and generic
animation system couldn't handle it without adding even more
complexity.
> Hypotheticlly suppose I have a side-scroller where the hero has a
> 4-frame walk animation. When I press and hold the attack button while
> walking, I want her to switch to to the sprite set where she charges an
> energy canon, and when it is fully charged, I want to change her sprite
> set to the one with the fully-charged canon. I want to keep my place in
> the 4-frame walk animation when these changes occur.
Reconsidering it now I think changing spriteset in the middle of an
animation without stopping the animation isn't going to be common.
However it would be nice if spritesets are interchangeable, just as
they currently are due to having the same number of frames each with
the same meaning. James expressed the same again in IRC yesterday:
<Bob_the_Hamster> I would like to continue to organize sprites into
sets of similar width+height+frame-count combonations
<Bob_the_Hamster> But to have another layer of abstraction on top of
that for things like variable size and variable frame count, and
complex animations
<Bob_the_Hamster> And things that need graphics could refer to sprite
sets, or to the higher level.
<Bob_the_Hamster> Because for some things you need greater complexity
than same-sized sprite sets can provide
<Bob_the_Hamster> but for other purposes you want the simplicity of
"yeah, this always needs 8 frames" and you don't have to care about
greater abstraction
<Bob_the_Hamster> Consider walkabouts
<Bob_the_Hamster> It would be cool if walkabouts could use any
sprite-set that provides 8 frames
<Bob_the_Hamster> OR any sprite set that provides 12 frames could be
used for a 3-frame walking animation
<Bob_the_Hamster> Or better yet, each sprite set type could have
metadata saying what context it may be used in
<Bob_the_Hamster> So you could keep 32x40 heroes and 32x40 walkabouts separate
...
<Bob_the_Hamster> And your NPCs could choose from sprite sets that
advertise walkabout compatibility, or from animation collections that
advertise walkabout compatability
...
<Bob_the_Hamster> In fact, even enemy data could be changed so instead
of needing to type in a number, you would browse, and the sprite
browser would show all the sprites of the three enemy types
I don't see much problem with allowing different frames in the same
sequence to have different sizes, though. So here's my suggestion,
based on thinking about how you would organise spritesheets:
In order to preserve current manual setsliceframe animation and
walktall we can continue to view a spriteset as a list of frames
numbered 0, ..., N-1, each frame of any size, and variable N. Each
spriteset can also have its own animation definitions, because those
are often unique. To support interchangeability abstract to frame
groups. (We could also allow naming individual frames and referring to
them by name (eg "Dead"), but that only goes partway.) Groups are also
numbered from 0, and could optionally have names; each is a list of
consecutive frames, and every frame is in one group. Eg. for an
existing 8 frame walkabout groups 0-3 would contain frames 0-1, 2-3,
4-5, 6-7. In the sprite editor groups would be visually separated a
bit.
I find the tile animation editor a royal pain to use. In probably 80+%
of cases just specifying a group of frames and the wait amount per
frame is a better way to define an animation. Also, animations,
whether defined in an editor or scripted, which refer to frames by
(groupnum, number_in_group) will be fairly robust to to addition of
more frames or groups, so that you can use your own conventions like
"for hero walkabouts group 5 is for a jumping to the right animation".
I suppose to keep walktall working, in the absence of animations named
"walk left", etc, the walkabout animation would fall back to the
current system which just refers to frames 0-7.
I think we'd likely want shared global/default animations too so you
don't need to duplicate suitably generic animation definitions.
The Reload tree I'm imagining looks like
*spritesets
**spriteset
***groups
****group
*****start (frame number). No need to specify end, it's implicit
*****name (optional)
***animations
****...
***frames
****frame
*****name (optional)
*****...
I think that once you have Frame serialisation there's not a very
great advantage to using a single generic skeletal Reload tree
structure for all graphics types, but it wouldn't be hard. That
skeleton would just be the above without groups or animations.
_______________________________________________
Ohrrpgce mailing list
[email protected]
http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
