[Ohrrpgce] better palette options
David Gowers (kampu)
00ai99 at gmail.com
Fri Oct 8 18:39:48 PDT 2010
On Sat, Oct 9, 2010 at 5:07 AM, Ralph Versteegen <teeemcee at gmail.com> wrote:
> 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.
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 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?
>
> 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.
>
> 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".
+1. I was thinking about this problem and couldn't figure out how to
do it nicely, but this is excellent.
>
> 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.
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.
>
> 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?
I wasn't sure what to think about this. Because default palettes of
the 256-color variety are NOT addressed with the current scheme.
Although it looks like we can use negative values in defpal%d.bin to
implement that.
Anyway I changed to a reload-wrapped blob of pixels.
>
> * 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.
+1 on that.
>
> * 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.
Yeah, I've tested this. It does inflate small image files. we start
winning at about 24x24 (288 raw bytes vs 158 compressed png).
as for (individual) zlib:
$> gzip -9 *.bmp; gzip -l *.bmp.gz
compressed uncompressed ratio uncompressed_name
329 1518 81.4% jbokei attack 2 frame 2.bmp
174 246 49.2% jbokei boxborder 0 frame 0.bmp
690 3310 80.5% jbokei largeenemy 0-.bmp
604 7478 92.5% jbokei largeenemy 0.bmp
595 3318 83.4% jbokei largeenemy 0+.bmp
1007 3318 70.9% jbokei largeenemy 1.bmp
1016 7478 87.0% jbokei largeenemy1.bmp
1069 3318 69.0% jbokei largeenemy 2.bmp
482 1518 71.1% jbokei mediumenemy 0.bmp
1372 65078 97.9% jbokei screen0.bmp
300 798 67.7% jbokei smallenemy 0.bmp
3276 65078 95.0% jbokei tileset0.bmp
189 358 60.9% jbokei walkabout 0 frame 0.bmp
156 406 72.9% jbokei weapon 0 frame 0.bmp
543 192054 99.7% nacmene.bmp
583 3318 83.2% p0.bmp
12385 358592 96.6% (totals)
compressing as a block yields
11593
actual compression should be better, though, since we would have less header
>
>> 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.
Okay, there was another change I needed to make anyway
which should address variable length and size other than 20x20.
Tile animation (might, possibly) be able to be a subset of the
proposed sprite anim format, including these ops: (relframe wait label
goto loop setctr checkctr reset end editpal cyclepal)
This would be a superset of the current TAP.
>
>> * 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?
I've noted that a few constraints are needed:
- editpal Le Pl Do # modify part of the palette.
# Pl == source palette
# (per 'palette' spec)
# Le == length
# Le = 0: copy entire source
# palette
# (16 or 256 colors)
# Le = N: copy N colors
# (Le <= len(Pl)
# must be enforced)
# Le < 0: undefined
# Do == offset into sprite palette
# Do + Le <=255 needs to be enforced
#
And some way to move by larger increments (16) would help for the above op.
Also thumbnails of the palette as it changes, next to the palette
modifying op, would be very helpful in CUSTOM.
That could be hard.
>
>> * 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.
I think Chrono Trigger did it by first swapping in an appropriate
palette, then cycling it, and finally reloading the original.
http://bpaste.net/show/10014/
^ current draft of proposition. addresses many of the issues brought up.
More information about the Ohrrpgce
mailing list