[Ohrrpgce] better palette options

[Ralph Versteegen]

On 11 October 2010 20:04, David Gowers (kampu) <00ai99 at gmail.com> wrote:
> On Sun, Oct 10, 2010 at 9:34 PM, Ralph Versteegen <teeemcee at gmail.com> wrote:
>>> RELOAD was not part of it (well, honestly RELOAD vaguely annoys me,
>>> the way it replicates XML's weird data model. So it's not the first
>>> thing I would think of.)
>>>
>>> But it is now.
>>
>> I wasn't actually requesting it. RELOAD as container for animation
>> data, as in your proposal, seems like a fairly good idea. RELOAD as
>> container for pixel data may be overly heavy. RELOAD annoys me a
>> little too, due to much increased complexity of read/writing.
>>
>>>>
>>>> I notice that separate image size and bounding box size/offset are
>>>> missing. Intentionally?
>>>
>>> Missing?
>>> I understood the base bounding box size and location as being
>>> immutable (and based off say, a manually definable box - see slice
>>> editor). While this was a bit annoying, it made some amount of sense.
>>> I'm not sure how to avoid confusing the user if they are not
>>> immutable.
>>>
>>> Please, explain further how you conceive of the interaction of
>>> bounding boxes and image offsets?
>>
>> It's a conflation of two (or three) different ideas. Perhaps they
>> should be separated. A "srcrect" is just a reference point (offset)
>> plus width and height equal to the existing frame size limits. I
>> called these "bounding boxes" because in the current tile-based
>> movement system (and also somewhat in in-battle movement and
>> positioning) the frame size is effectively a bounding box. But if/when
>> we add pixel-based movement one may well want the bounding box to
>> depend on the current frame.
> after reading Mike's email and recalling my own experiences with
> bounding boxes,
> I'm -1 on
> "frames should have their own bounding boxes"
> for the 'single image' sense of 'frame',
> and +1 on
> "frames should be able to have their own bounding boxes"
> in the 'unit of animation' sense of 'frame'. (implemented as an
> opcode, since while the need for this is definite, it's rare.)

OK, I admit it, I didn't think it was a good idea either.

>>
>>>>
>>>> I don't understand the difference between the 'animset' command, and
>>>> chaining to another animation using 'end'.
>>> animset != anim.
>>> it doesn't set the anim, it sets the animset.
>>> Anyway I removed that by allowing varlength tuples.
>>
>> What varlength tuples?
> one opcode + N parameters. I see I changed the proposition to not use
> the 'tuple' term though, so my mistake.
>
>>
>>>>
>> always be appropriate. Quoting from the 'text tags' thread, where I
>> proposed embedding tags in textboxes which trigger portrait
>> animations:
>>
>>> > Maybe animations should get both a name and a number. The name can be
>>> > used everywhere that it makes sense to use a name, and the number can be
>>> > used in whatever small number of places a name isn't practical (like
>>> > here)
>>>
>>> OK, sounds practical. But I wonder whether the ID number should be an
>>> index into the big global table of animation names (shared by all
>>> spritesets of any sort), or refer to the n-th animation currently
>>> defined for this spriteset. I'd prefer the first, since it might make
>>> sense to sort animations, say alphabetically.
>
> The first is obviously better IMO.
>
>>
>>
>>
>>>>
>>>> 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
> ..
> wait, what?
>
> checkctr is crazy.
> Def changed to '!= 0'
>
>>>>
>>>> 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.
>>> oh right, ctr and label can fit into 16 bits easily(3+8)
>>> Good idea. (note that I'm leaving in the original ops -- they have a
>>> specific use that cannot be readily attained by a loop command :
>>> interleaving instructions, like 'wait 1' that only execute eg on >=
>>> second loop through a particular area
>>> of code.
>>
>> Your definition of loop isn't correct.
> Indeed.
>
>>
>> The actual encoding of the bytestring, bits per opcode and argument,
>> isn't specified. Making them all 16 bit signed is easy, but we if want
>> to cram multiple arguments into the same short, maybe it would just be
>> simpler to same that opcodes are 8 bit, and arguments are either 8 or
>> 16 bit signed (or a string (wouldn't be necessary if we numbered
>> animations internally?)).
>>
>>>>
>>>> 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.
>>
>> 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.

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.

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

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

>>
>> I also compared compression of pngs (produced with Gimp) with bmps run
>> through gzip -9 on backdrops from Vikings and found that the pngs were
>> consistently smaller, but usually by only 1%. The gain from
>> compressing a tar of 4 bmps was only about 4% after accounting for
>> size increase due to tar headers.
> so not worth thinking about either way.
>
>>
>> Oh, I completely forgot; I was wondering whether that would be possible.
>>
>> One possibility would be to have an animation state for each tile in
>> each tile animation range (there are 256 - 160 = 96) for each tileset
>> used on the map. Upgrade the existing 2 tile animation patterns to 2
>> animations plus 96 animations which set the starting tile and then
>> chain to one of the two translated patterns. I really don't like the
>> sound of this.
>>
>> Much more reasonable would be to let people associate with each
>> animation for a tileset the range of the starting tile (frame) - a
>> small tileset-only extension to the file format. So TAP animations
>> would be translated to two animations for the first tile in each
>> range, with the ranges set to 48. People could define animations with
>> ranges of 1 to create a single tile animation.
> 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.

>>
>> Note that the frame number should wrap around for TAP animations to work.
> I've modified the spec to this effect.
>
>>
>> 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. 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.

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