[Ohrrpgce] Sprites, animation food for thought

[David Gowers (kampu)]

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.
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
5. Save the actual tile-based bitmap.

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