Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

New default master palette #60

Closed
ohrrpgce-bugbot opened this issue Apr 12, 2005 · 11 comments
Closed

New default master palette #60

ohrrpgce-bugbot opened this issue Apr 12, 2005 · 11 comments
Labels
bug Yeah... that's broken rel: voxhumana Present in voxhumana 2008-01-21

Comments

@ohrrpgce-bugbot
Copy link

[bz#60]

Neo has put considerable work into creating a new better master palette. I would
like to get this included into the OHR. Naturally it will not automatically
replace the master palette in existing games, it will just replace the palette
in OHRRPGCE.NEW which is used for new games.

The hard part is that so many menus use pre-defined color indexes which don't
neccisaraly match up nicely with the new palette. All colors really should be
customizable.

From: @bob-the-hamster
Reported version: 20080121 Voxhumana
URL: http://gilgamesh.hamsterrepublic.com/wiki/ohrrpgce/index.php/Plan_for_default_master_palette_replacement

@ohrrpgce-bugbot
Copy link
Author

Comment author: @bob-the-hamster

Created attachment 18
Neo's Better Palette (PCX)

Here is Neo's palette

Attached file: updated_palette.pcx (application/octet-stream, 1030 bytes)
Description: Neo's Better Palette (PCX)

@ohrrpgce-bugbot
Copy link
Author

Comment author: @bob-the-hamster

Created attachment 19
Neo's Better Palette (PNG)

In case anybody wants to actually SEE the palette, here it is as a PNG :)

Attached file: updated_palette.png (image/png, 832 bytes)
Description: Neo's Better Palette (PNG)

@ohrrpgce-bugbot
Copy link
Author

Comment author: @0ion9

Okay, you want
a) the colors current used to remap sensibly when the palette changes in custom, and
b) specification of colors used for interface; nicety for CUSTOM and necessity
for GAME.

Correct?

I'm thinking of a hack involving a temporary file and the bitmap2page function.
I have a prototype here that has an [n][4] array of [index, r,g,b] -- throw
pixels into the first line of the BMP according to this.
This array could be deleted immediately after mapping.

So, these would be the steps to working menucolors for CUSTOM:

  1. load icolormap() contents from RPG
  2. save temp BMP, black but for the first N pixels
  3. bitmap2page and storepage
  4. read first N pixels (planar, so 3 seeks)
  5. Fill in icolor() with the indices thus obtained.

I'd like to compress the indices so that instead of using indices splattered
over the range 0-255, they were grouped adjacently. For textboxes this is easy,
they're mathematically calculated anyway.

that leaves:
18,28 : menus, inbattle boxes
21 -- active hero's timebar content
34,44 -- selected save slot
35 -- energybar
160 thru 174 -- enemy selector.
242, 252 -- quit box and unselected save slot

@ohrrpgce-bugbot
Copy link
Author

Comment author: @bob-the-hamster

I was actually only thinking about (b). (a) had not occured to me.

My intention was to allow specifying the interface colors in custom,
then replace the old palette with the new palette in OHRRPGCE.NEW so
that new games would use the new palette.

Although your idea (a) sounds really good. That way when people import
new palettes, they won't risk rendering custom unusable by changing the
interface colors.

My plan for textbox colors is this:

there would be a text box style editor in custom that would allow you to
define 16 text box styles. This includes freely selectable background
colors, border colors, and maybe other stuff like border width. It would
store this info in a new text box styles lump. In the text box apperance
editor, the "background" would become the "style". For games that lacked
a style lump, the styles would default to colors the same as the current
method of coloring text boxes.

menus, save slots, energy bars, etcetera could all also be handled as
additional records in the same text box style lump.

So anyway. I think we will need to work in this order:

  1. implement interface color editor and box style editor
  2. support interface and box colors in GAME with support for reasonable
    defaults for old games
  3. implement smart remapping of interface/box colors when importing a
    new master palette, using the cool temp BMP hack you suggest
  4. replace the master palette in OHRRPGCE.NEW
  5. release and celebrate
    5a) update a whole bunch of screenshots in the HOWTO ;)

@ohrrpgce-bugbot
Copy link
Author

Comment author: @0ion9

Created attachment 49
python code to generate some of the needed code and tables

This generates some of the menu code (names, consts, minimaxes).
The table at top defines the colors as CUSTOM and GAME currently
expect them -- it is needed for deciding default interface colors.
It should be expanded, so that all the new indices for the various things are
chosen.

Edit the interface_colors table (which defines menu structure) if you have a
better idea what options should be given.

Attached file: color_mapping.py (text/plain, 3457 bytes)
Description: python code to generate some of the needed code and tables

@ohrrpgce-bugbot
Copy link
Author

Comment author: @arperry

In the interest of cleaning up the buglist... I'm pretty sure this one can go,
since the master palette has been updated. Reopen if I'm mistaken.

@ohrrpgce-bugbot
Copy link
Author

Comment author: @rversteegen

Hasn't yet. The palette is attached to this bug, but it's not in ohrrpgce.new,
and it can't be because it mucks up alot of the ui colours. So the ability to
change them (and good defaults for the new palette) need to be implemented first.

@ohrrpgce-bugbot
Copy link
Author

Comment author: @bob-the-hamster

Created attachment 87
Neo's better Palette.mas

Neo's palette in MAS format (created with 2mas). The trouble with importing palettes from BMP is that you have very little control over the order of the palette entries. Sure they are in a fixed order, but the graphics program you use to edit the palette is likely to change that order without telling you.

A suggestion: Rather than importing the palette as it is stored in an 8-bit BMP, instead it would be better to import palettes from a 16x16 pixel BMP file (which could be either 8-bit or 24 bit) and ordering the palette colors by the pixels positions.

Attached file: [Neo's Better Palette.mas](https://rpg.hamsterrepublic.com/bugzilla/old-attachments/Neo's Better Palette.mas) (application/octet-stream, 1550 bytes)
Description: Neo's better Palette.mas

@ohrrpgce-bugbot
Copy link
Author

@ohrrpgce-bugbot
Copy link
Author

Comment author: msw188

Can this now be officially marked fixed? I hesitate because I don't understand what .mas means. I'm just saying because of the stuff on the mailer's list.

@ohrrpgce-bugbot
Copy link
Author

Comment author: @bob-the-hamster

This is fixed now, and TeeEmCee has already long-since implemented the new master palette import format (the 16x16 BMP file)

@ohrrpgce-bugbot ohrrpgce-bugbot added bug Yeah... that's broken rel: voxhumana Present in voxhumana 2008-01-21 labels Mar 14, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Yeah... that's broken rel: voxhumana Present in voxhumana 2008-01-21
Projects
None yet
Development

No branches or pull requests

1 participant