[Ohrrpgce] Sprites, animation food for thought

[David Gowers (kampu)]

On Mon, Oct 18, 2010 at 9:58 PM, Ralph Versteegen <teeemcee at gmail.com> wrote:
> On 14 October 2010 13:45, David Gowers (kampu) <00ai99 at gmail.com> wrote:
>> On Wed, Oct 13, 2010 at 7:20 PM, David Gowers (kampu) <00ai99 at gmail.com> wrote:
>>> 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.)
>> Of course, depending on how clever it's okay to be, we could actually
>> encode all sprite data as a solid block of pixels with 0 wasted bytes.
>
> That's actually a really small change to the file format, isn't it?
> You're only suggesting concatenating the pixel data lumps together,
> aren't you? (I think I'd prefer it that way, as it's a bit simpler to
> handle, but less self-describing)
yes, it would require reading individual images, not the 'whole image'
- which would look like gibberish.
OTOH if we ever use hardware accel, being able to read spritesheets as
one big image would definitely help performance.

>
>> This would require a rewrite of the gfxset every time a sprite changed
>> dimensions, and we would need to do a little work to export:
>> 1. Take the maximum of the dimensions of the sprites in the gfxset and
>> designate that the tile size.
>> 2. Guess an appropriate WxH of tiles (ie how many tiles across and how
>> many down, in order to attain an aspect ratio near 4:3, which will fit
>> the most sprites on screen.)
>> 3. Place the sprites sequentially (converted to masterpalette indices,
>> rather than private-palette indices) within the tiles according to
>> default-offset info (clamped so the sprite doesn't escape tile bounds)
>> 4. Save a matching metadata file, specifying sprite bounds, default offsets,
>> masterpalette->private palette mapping
>
> And (optionally) animations?
Animations associated with the gfxset? (ie normally any animations in
the correspondingly numbered animset)
Good idea, seems pretty useful to me if you're writing a filter or such.
(I'd bet I could hack up a PyGIMP plugin which built GIMP-viewable
animations from animation+frameset. That could be pretty handy esp.
given GIMP's nice time-zooming animation player.)
>
>> 5. Save the actual tile-based bitmap.
>
> This sounds almost exactly like how I wanted to export sprite sets.
>
> I also thought about drawing two-colour X- and Y-axis guides (line
> segments) along the edges of the tiles to show the size/position of
> the frame and of the srcrect/"bounding box". It does not matter that
> the (along with background) three colours used won't be unique, if the
> edges of the tiles can be found on import. This could be done even
> without any metadata.
I think I know what you mean. If we add 1 to the w/h
of each tile, we can use that for said annotation.

>
>> This would require:
>> a) the user to export frames individually if they wanted to resize(not
>> scale -- just change the dimensions) them (or else provide resizing in
>> the sprite editor).
>
> Of course we'll provide resizing in the sprite editor.
>
>> b) them not to 'lose' the metadata file
>> (IME this kind of thing is a bit of a pain, however hopefully being
>> able to do a fresh export of a sprite set would mitigate it)
>> c) we would have to autodetect added indices and do something with
>> them (prompt the user whether to add them to the private palette?).
>> This would require scanning every frame which the metadata says uses
>> the same private palette.
>>
>>> 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.
>> I suspect it to be low.
>
> By sprites, I assume you mean frames. I don't understand the question:
> shouldn't the answer be "virtually never", since that would only
> happen if you use different frames of a spriteset as separate images
> with separate palettes, for sprite slices or something?
I was thinking eg an anim that involved periodic glowing/color change.
but that should probably be done using anim opcodes.

>
>> regardless, spritesheets have a definite limitation WRT palettes: they
>> must be shared across all sprites in a sheet in order for the
>> spritesheet to be human editable.
>> If we postulate that all sprites in a gfxset share a palette, this is
>> not a problem. As I suggested above, we could convert to master
>> palette and that could be the 'shared palette' (with private palette
>> data stored in the metadata file)
>>
>> That might actually work quite nicely.
>
> We don't need to support giving different frames different palettes.
> One palette is enough; more than enough with the palette changing
> animation ops.

Okay, I was thinking of eg elemental effects, which might plausibly be
in a different palette. However, you can just as easily do that by
adding to the palette.

>
> There's a problem with converting to master palette: if multiple
> indices in the default private palette map to the same index in the
> master palette (but mapping to different indices in some palette
> swap), then that information is lost.
hmm, are you talking about having different 'palettes' on the same sheet?
Otherwise, that is what the metadata is for. (palette mapping info per bbox)
Anyway, as I agree with you about the single palette thing, it's
irrelevant. The original reason I thought of it was quite ill thought
out ('making it easier to add to a palette')
Plus, this way it's easy to rearrange and add to a palette, actually
(particularly, GIMP has a plugin included by default which allows
interactive rearrangement of an indexed image palette (with
'automagickal' color remapping. very helpful))