[Ohrrpgce] better palette options

[Ralph Versteegen]

On 9 October 2010 02:48, David Gowers (kampu) <00ai99 at gmail.com> wrote:
> On Fri, Oct 8, 2010 at 11:42 PM, David Gowers (kampu) <00ai99 at gmail.com> wrote:
>> http://bpaste.net/show/10001/
>> ^^^^^
>> The format proposition
>>

Generally this looks good. Aside from the following long string of criticisms ;)

I'm not sure, but I believe you're suggesting using a plain binary
lump instead of Reload for animation? If Reload is actually part of
it, I don't see much point in a separate lump per animation.

I notice that separate image size and bounding box size/offset are
missing. Intentionally?

I don't understand the difference between the 'animset' command, and
chaining to another animation using 'end'.

You're also missing animation names. I think naming animations is
better than numbering them. Then you can add a attackee flinch
animation to an enemy, say, just by adding an animation and naming it
"hurt".

The check/setctr codes seem to be very inefficient for creating loops:

setctr ctr0 = x
label 1
...loop contents
setctr ctr0 -= 1
checkctr ctr0 == 0
goto label 2
goto label 1
label 2

Those last 5 instructions could be replaced with a loop(ctr,label)
code: decrement ctr and goto label if ctr > 0. A relative frame change
code would also be very useful for loops.

I suggest a 'reset' command. Changing the sprite state after the end
may be desired (ie. a transition animation), and sometimes not.
'reset' would return to the original gfxset, frame, palette, and
offset.

> Note that I intentionally made it as unrestricted as possible.
> Imposing additional constraints could allow the removal of certain
> tuple types and runtime data fields. Whether additional constraints
> are appropriate is a matter for discussion.
>
> Comments on PNG:
> * I saw your suggestion, Mike, and I thought : though it isn't the
> only option, it has a lot going for it.
>
> * Note we may want to rewrite imported images even if they are in PNG
> already: Some programs (notably Photoshop) are pretty bad at
> compressing PNG relative to libpng.
>
> * I opted to include a simple source-tracking tEXT chunk
>  to aid import <-> export cycles
>
> * using PNG (and implicitly assuming 256-color sprite data) has the
> side effect that we can play nicer with eg Grafx2, which always writes
> a '256-color' image even though only the first 16 colors are used.

I'm uneasy about using PNG:
* the biggest problem: paletted PNG files require a palette, which is
useless to us. We could instead encode our images as 4-bit/8-bit
greyscale pngs, but then the PNG is not even human-viewable; isn't
that half of the point of using PNGs? Would we put real palette
information (default palette) in a private chunk?

* it would be a horrible idea to import whole PNG files. There could
be all kinds of other things in them that could change meaning later
(eg. requesting pixel data from libpng in a different way)

* requires interfacing with an external library, all this is going to
be potentially much more work than using our own barebones file
format. However we might want to use libpng for importing/exporting
png files anyway.

* It would probably actually increase file size when used for
walkabout sprites and smaller: chunk headers add a minimum of 56 bytes
(assuming no palette chunk) without even encoding the image size. And
individually compressing each 20x20 frame may yield lower compression
than just using zlib on the entire RPG file/sublumped spriteset file.

> On another topic:
> * my proposition does not include backgrounds or tilesets.
>  I believe backgrounds can fit into the scheme in a natural way.
>  I'm not sure what to do with tilesets as I understood that some
> other upgrade relating to them is incipient, but not sure exactly
> what.

Tilesets should allow a variable number of tiles. Tile animations
should be more flexible. We might as well not limit ourselves to 20x20
tiles. Beyond that, no plans. We could store them as an array of
individual tiles, but import/export/display in the current format. I'm
not sure if there's any benefit.

> * nor does my proposition address partial recoloring. With 256 color
> sprites, it would be far easier to standardize on recoloring, so, for
> example, you could fill a 256-color palette via sets of 16, and just
> swap in/out sets of 16 to recolor things easily.

I really like the idea of treating a 256-colour palette as 16
16-colour palettes. But swapping 16-colours individually doesn't sound
simple to support.

> * related to the above: color cycling, while not *important*, might be
> something we want to consider (eg for showing elemental effects on a
> character)

That would be very neat.