[Ohrrpgce] better palette options

[David Gowers (kampu)]

On Fri, Oct 8, 2010 at 2:53 PM, Ralph Versteegen <teeemcee at gmail.com> wrote:
> On 8 October 2010 14:59, David Gowers (kampu) <00ai99 at gmail.com> wrote:
>> On Fri, Oct 8, 2010 at 9:44 AM, Jeremy Bursey <zippywings at hotmail.com> wrote:
>>> I'm only subscribed to the mailing digest, not the individual alerts, so I
>>> have to cut and paste those comments related to the palette discussion I
>>> introduced last night. Hopefully this doesn't come out all messy.
>>>
>>>>Did james modify my palette in that way? I know he changed it slightly
>>>> before
>>>>installing as the new default. That's a shame if so; I specifically
>>>> designed
>>>>it to not waste a single entry.
>>>
>>> The game I'm updating actually started 10 years ago on the old palette, so I
>>> am using most of the original colors. I just had to move all my yellows to
>>> the
>>> top row to make room for all my "sand" tiles. So that's the specific issue
>>> I'm
>>> facing. At the moment, using my updated palette turns all the UI colors
>>> yellow.
>>>
>>> I'd like to use yours at some point, actually, but the time it would take me
>>> to convert 160 palettes, 300 backdrops, over 1,000 sprites, and so on to the
>>> compatable colors would cause me unthinkable pain, and I'm not ready to take
>>> that plunge yet. An update to how palettes are handled would certainly make
>>> the effort more desirable.
>> i wrote an app which does that automatically (CHGPAL). have you tried
>> it on a copy of your rpg?
>> http://rpg.hamsterrepublic.com/ohrrpgce/Graphics_Utilities
>
> CHGPAL doesn't handle box borders, portraits or UI colours, and it
> uses the old master palette format instead of the new one, but it
> shouldn't be much work to update it if desired.
>
>> It's a simple enough procedure that CUSTOM  could conceivably
>> implement it as an option on the master palette screen.
>
> Yes, it would be good. I don't know how to best pick the nearest match
> in the new palette for a colour (and should you let the user override
> this somehow, as they can when importing backdrops?), but in this case
> Jeremy just wants to move colours around the palette.
>
>>>
>>> That's the part that made me question whether this was worth discussing.
>>>
>>>>have you seen
>>>>http://rpg.hamsterrepublic.com/ohrrpgce/Plan_for_256_color_sprites
>>>
>>> I have, actually. But it was my understanding that this was still light
>>> years
>>> away from becoming reality, if it was ever meant to become reality.
>>
>> I'm working on some formal YAML propositions regarding sprite
>> upgrades. They have the property of being very succint, so hopefully
>> that will help things to happen
>
> What is a "formal YAML proposition"?? A proposal for a new graphics
> format? I'm keen to have that agreed upon.

It looks like this O)
                          ^^ 'smiling cyclops with a monocle' emoticon.


animproposition1:
      description:
         (type)gfx.bin:
            type: sublumped
            subst:
               'type': [hero, walk, enemy, portrait, ]
            gfxset: # a set of related frames
               # <=1 per usage class(eg hero, enemy)
               # with the possibility of >1 owners
               datadesc :
                  header:
                     SIGNATURE:
                     METADATA_RECORD_SIZE:
                  metadata_table:
                     W : int16
                     H : int16
                     repeats_for : NFRAMES
                  data:
                     DATA : [byte, [H, W]]
                     repeats_for : NFRAMES
               repeats_for : NSETS
         (type)anim.bin:
            subst:
               'type': [hero, walk, enemy, portrait, ]
            anim:
              code : [[enum, [goto, gotorel, wait]]]
              param:
                   goto: frame_index
                   gotorel: frame_index_offset
                   wait: nticks
               repeats_for : N_INSTRUCTIONS_IN_ANIM
            repeats_for : NSETS

         # animation patterns and goto+wait1, gotorel+wait1 should be
implemented as a ui layer
         # over this IMO

(incomplete so far)