[Ohrrpgce] Sprites, animation food for thought

[Ralph Versteegen]

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)

> 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?

> 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.

> 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?

> 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.

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.