[Ohrrpgce] Sprites, animation food for thought

[David Gowers (kampu)]

On Mon, Oct 11, 2010 at 4:07 AM, Mike Caron <caron.mike at gmail.com> wrote:
> First off, a disclaimer: This is not an actual proposal for a data format
> for the OHR. This is something I've cooked up for another project which may
> or may not ever see the light of day (hopefully, it will, but it's
> immaterial to this discussion).
>
> This is how I've implemented sprites and animations in this other project:
>
> First, all pixel data is stored in sprite sheets. These are PNGs that
> contain all the sprites for a given on-screen entity.
I wanted to use a sprite-sheet based system in my proposition,
but so far I don't see how to avoid dumping a load of complexity on
the user. (as a user, arranging images on a sprite sheet is something
I don't want to deal with. Defining some nominal 'default dimensions'
and padding to that when adding new sprites would help.)

> Technically, as I am
> writing it in .NET, nothing is stopping them from being BMP or JPG or
> something, but I prefer PNG for its true-colour and transparency support.
>
> Then, with each sprite sheet, there is an XML document that describes it:
>
> <spriteset xmlns="http://mike-caron.com/za" name="link1" file="link.png">
>    <frame x="33" y="1" width="16" height="22" ox="8" oy="19"
> name="stand-down" />
>
>    <frame x="3" y="31" width="16" height="22" ox="8" oy="19"
> name="walk1-down" />
>    <frame x="33" y="31" width="16" height="22" ox="8" oy="19"
> name="walk2-down" />
>
>    <!-- etc. -->
>
> Each frame has a name, a position and size on the sheet, and an origin. The
> origin is aligned up with the actual entity's origin (which, ATM is always
> their (x,y) position, but that may be customizable later on)
>
> Then, after the frame definitions, we have the animation definitions:
>
>    <animation name="stand" deftime="1" loop="no">
>        <dir dir="down">
>            <frame>stand-down</frame>
>        </dir>
>        <dir dir="up">
>            <frame>stand-up</frame>
>        </dir>
>        <dir dir="right">
>            <frame>stand-right</frame>
>        </dir>
>        <dir dir="left">
>            <frame>stand-left</frame>
>        </dir>
>    </animation>
>
> This is mostly self explanitory. Every frame has either one or four
> directions defined, depending on if the sprite has meaningful directions (an
> item on the ground, for example, probably only has one direction. An NPC, on
> the other hand, will have all four).
>
> Each frame in a direction can have a time parameter, which describes how
> many ticks the frame is displayed for. deftime is just the default such
> value. Obviously, as well, if loop is yes, the animation will start from the
> beginning. If no, it will just stop on the last frame forever.
>
> Finally, every entity in the game references both a sprite sheet and an
> animation. The idea is that you could change one or the other. For example,
> if you get a better shield, the sprite sheet changes from "link1" to
> "link2". And, obviously, the animation changes based on what is happening in
> the game.
Ugh, you're giving me all these awesome ideas :) I'll have to cut
down, there are already too many ops.
>
> A few notes on this structure:
>
>  - There is no accounting for palettes. If you wanted to use a paletted
> sprite, then by all means you are able, but don't expect to be able to
> change that palette in game. The canonical way to add palette swaps is to
> have a different sprite sheet with the same animations (and, I may add some
> way to automate this. Eg, "this sprite sheet is exactly the same as this
> oth er sprite sheet, so use those definitions")
I'm a bit ambivalent now. TMC's proposition of attaching a set of
palette indices to each sprite "makes my common-sense tingle" :) I
think we need to look at how frequently color swapping is used vs a
number of sprites sharing the same palette. If it's high, that favors
individually defined frames. If it's low, blobs of glued-together
frames.
>
>  - There is also no way to get any fancier animations. I.e, there's no way
> to automatically oscillate or go backwards or whatever. The way to achieve
> these effects would be to duplicate the frames in the animation.
>   - I may or may not add sprite flipping.
>
>  - The way the images are laid out on the sheet has absolutely nothing to do
> with how they are animated or displayed. If you wanted the same frame, but
> offset by 5 pixels or whatever, you just modify the origin. No muss, no
> fuss.
>
>  - Also, there are no inherent limitations on how large or small the sprite
> is. If you want to make a 2d version of Shadow of the Colossus, then be my
> guest! (just, don't expect the video card to necessarily play along ;)
>
> So... yeah. Make of that what you will, I'm just adding ideas to the pot. I
> am aware that this format, as is, is unsuitable for the OHR. It's just my
> two cents.
> _______________________________________________
> Ohrrpgce mailing list
> ohrrpgce at lists.motherhamster.org
> http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
>