[Ohrrpgce] better palette options

[David Gowers (kampu)]

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


>
>>>
>>> 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'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.
I'd like to extend this by requiring a 'master palette #' as part of
the on-disk image format. This can
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 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)?

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

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