[Ohrrpgce] better palette options

[David Gowers (kampu)]

On Mon, Oct 18, 2010 at 11:11 PM, Ralph Versteegen <teeemcee at gmail.com> wrote:
>>>
>>> Wondering why you noted reset as only resetting gfxset  - you don't
>>> think the rest is useful?
>> I hadn't thought how to derive the defaults yet.
>> I've partially amended it now.
>
> I intended to just save the state at the start of the animation, and
> restore it when resetting.
Fair enough. So we need an 'original_state' pointer?

>
> Then the question arises of what to do when chaining to another
> animation: should the saved state be overwritten? Both possibilities
> could be useful; maybe another parameter to 'end' would even be
> justified.
This seems hard. I'll poke around a few different models and tests to
see what comes out.

>
>>>
>>> I'm wondering how much trouble it would be to unify 256 and 16 colour
>>> palettes. Either allow palettes to have a variable number of colours,
>>> or upgrade all palettes to 256 colours so that there is no
>>> distinction. It would make a lot of things easier.
>> I totally agree. The only question is, how?
>>
>> You are proposing sharing one master palette between all graphics of
>> the same class?
>> so 8*256 = 2048 in total.
>
> No... I don't think so. I thought I left specification of master
> palettes open, but (changing topic slightly) perhaps it's dubious to
> not associate a master palette with each 16 or 256 colour (more
> correctly: index) palette, if you allow more than one master palette
> at once.

I think it's important, especially given the low overhead of doing so

>
>> I'd like to extend this by requiring a 'master palette #' as part of
>> the on-disk image format. This can
>
> This sounds good, unless master palettes are instead associated with
> 16/256 index palettes.
Not sure what you mean but the following might answer it

The current scheme associates a masterpalette number and an
indexpalette with each gfxset. This works out nicely for existing gfx
types, particularly tilesets and fonts.

>
>> a) double as a way to indicate unpalettedness, if this ever seems
>> appropriate in the future.
>> b) allow for 'peripheral' graphics that aren't precisely part of any
>> graphics class.
>
> I'm not sure what this has to do with master palettes. I thought we
> would add one additional class for misc graphic sets. Or better, allow
> users to define multiple, so that they can group their sets as they
> wish.
Yeah, I reread what I'd written above several times, and I have no
idea what I meant by b)

>> I don't seem to grok that. Doesn't it need to have an 'first
>> applicable tile' property in order to be a range (or to make sense at
>> all in the context of old TAP)?
>
> I meant that the animation would be defined for the first tile in the
> range (implicit in the animation itself), and the n-th animating tile
> would display as the animation's current tile/frame + n.

One animation runs, and you add eg ((TILENUMBER - 160) % 48) to it to
get the actual tile number to display?


>>
>>>
>>> Storing each tile as a separate frame is a slight nuisance. I'm just
>>> going to load them all into a single frame as an optimisation.
>> SPECIALCASING UGH (this would require tile animation to run off a
>> variant animation engine instead of a universal one.
>> But I understand why.
>
> Actually, no, as the animation engine doesn't need to access the
> sprite data, aside from number of frames, as far as I can see.
right, good point.

> It
> would instead require tiles to be drawn using a variant sprite drawing
> routine -- and they already are. I think that this allows a noticeable
> speed-up in drawing the map due to improved memory locality and
> reduced processing of hundreds of frame structures.
>
> I should have talked about strings instead. Fonts are also
> special-cased, yet the overhead of drawing each character is still
> about as large as actually blitting the 64 pixels (largely due to FB
> vs. C optimisation differences).
>
> So, (I think) I forgot to mention fonts. We'll want to store them in
> the same way as other graphics, minus animations.
I had thought about fonts earlier. You propose to store them as
256-color graphic sets? This makes sense to me, particularly for
multicolored fonts.


>
>>>
>>>>>
>>>>>> * 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.
>>>> Do you mean from a UI perspective?
>>>
>>> Partially; I was thinking of associating with each sprite an array of
>>> palette indices, rather than giving each sprite its own copy of its
>>> palette. Using copies of the palette will . It's my nature to be
>>> uneasy about the extravagance of a 256 byte array per sprite, but we
>>> can use copy-on-write, and anyway 256 bytes
>> This sounds interesting. +1 on that, more thoughts on it later.
I'd just like to point out this is still required due to instancing,
in spite of now sharing a palette
>>
>> http://gitorious.org/nohrio/nohrio/blobs/master/tools/lumpdefs.yaml
>>
>> <- various updates, still considering other updates as a consequence
>> of Mike's input.
>
> Initially I thought tag2ctr was quite nice, but I wonder whether some
> people will find the extra layer of indirection required to use tags
> in their animations as they currently can in TAP to be confusing.
>
> I suggest 'frame' use the default wait when W = -1 instead, to allow a
> wait of zero so that other ops may follow before the next wait. You're
> forcing 'frame' to be the last of any sequence of simultaneous
> operations.
Good catch, thanks.