[Helixhorned]

No, the problem is that colors outside of tile 251's blue stripe begin to "wash away" into yellow as shade increases, not the looked-up color itself.

[Danukem]

I don't have much to say about this, except that I would not recommend any solution that requires reworking HRP textures, because we cannot depend on anyone to actually do it.

[Jan Satcitananda]

Helixhorned, on Mar 1 2011, 12:15 AM, said:

No, the problem is that colors outside of tile 251's blue stripe begin to "wash away" into yellow as shade increases, not the looked-up color itself.

Oh, I've overlooked that you were talking about the gray part of the texture. Actually it's a highpal fault. In the previous versions of my highpalookups this artifact was even more pronounced, so I was looking for a way to reduce it, but dark grays still get affected by that blue-to-yellow conversion. A bit of manual editing on hipal #23 might help, but it's better to continue modifying my highpal generating algorithm to increase its "stiffness" on dark colors.

[wayskobfssae]

Any chance of adding functionality to this so a certain palette number can affect a certain element of a texture? For instance, I would like to alter the colors of the fullbright colors (as they were in the 8-bit palettes), which means I would need to be able to have a palette that would change the glow map without changing the texture.

[Plagman]

I suppose that's possible. Would it be sufficient to just apply the same highpal to the glowmap or do you really need to be able to differentiate between say, regular red and fullbright red?

[wayskobfssae]

Plagman, on Mar 7 2011, 05:28 PM, said:

I suppose that's possible. Would it be sufficient to just apply the same highpal to the glowmap or do you really need to be able to differentiate between say, regular red and fullbright red?

It would have to be able to be applied to the glowmap without being applied to the base texture. The idea is to create a lot of interesting blinking light patterns without having to load up the folder with a bunch of extra texture files.

[Kyanos]

I'm working on making a Highpal lookup table for WGR2s palette. I've read Craigfatmans evaldraw script and ran it and understand how to use it to make a Highpal table. The issue I'm having right now is how best to get a base with all of the lookup data applied to the palette, like DukePals.bmp in clutstat. I mean I could make my base palette a sprite and take pics of each pal applied in eduke32, or maybe editart would do this, or maybe another better way like an evaldraw script, or some other old dos program?? Any help is always appreciated.
 DukePals.bmp (97.55K)
Number of downloads: 103

[Jan Satcitananda]

Drek, on 05 January 2013 - 11:00 AM, said:

I'm working on making a Highpal lookup table for WGR2s palette. I've read Craigfatmans evaldraw script and ran it and understand how to use it to make a Highpal table. The issue I'm having right now is how best to get a base with all of the lookup data applied to the palette, like DukePals.bmp in clutstat. I mean I could make my base palette a sprite and take pics of each pal applied in eduke32, or maybe editart would do this, or maybe another better way like an evaldraw script, or some other old dos program?? Any help is always appreciated.
DukePals.bmp

Nice to see the script getting some more use. The wisest way to prepare the lookups is to load raw data into a graphic editor supporting raw format.
The lookup data is, not surprisingly, stored in the LOOKUP.DAT file. So let's look into its format (quoted from the ExtCLUT readme but works for all Build palettes):

LOOKUP.DAT:

  Address range        Description                                        Size
           0x0000    Number of pals                                     [0x0001]
0x0001  -  0x8080    Palettes (first byte is the mapped ID, up to 127)  [0x0101 * byteptr(0x0000)]
0x8081  -  0x8380    Underwater palette (BGR 0-63)                      [0x0300]
0x8381  -  0x8680    Night vision palette (BGR 0-63)                    [0x0300]
0x8681  -  0x8980    Duke3D logo palette (BGR 0-63)                     [0x0300]
0x8981  -  0x8C80    3DRealms logo palette (BGR 0-63)                   [0x0300]
0x8C81  -  0x8F80    Episode 1 Seq palette (BGR 0-63)                   [0x0300]

We'll need to extract the lookup palettes which are in the beginning right after the first byte, but each lookup is preceded by a byte denoting which pal the game should setup. So there are 257 bytes stored per palette. Knowing how many palettes is contained in the file, we can rename LOOKUP.DAT into LOOKUP.RAW and open it as a grayscale (8-bit) 257x*** image, having the height equal to the number of palettes. Don't forget to set the header size to 1 byte, since we have to omit the first byte. Now the leftmost column of the image will keep mapped pal IDs (no correct colors will be seen at this step), with each row of pixels corresponding to a specific palette, so we can rearrange them in ascending order or simply crop the image to remove the extra column and leave 256 colors. Resave the image into another RAW file and reopen it with a width of 16 pixels and a height 16 times the number of palettes (each pal is interpreted by my script as a 16x16 block). The image is still grayscale, but you should be able to apply any palette to it (possibly, extract it from a screenshot if you don't have one you need), of course with the 'maintain indexes' option selected. That's all, good luck.

[Kyanos]

Thank you, I've gone ahead and started just manually making one using a bmp extracted from my palette.dat. I made it a sector floor, took a series of pics for each pal (only 25 phew) I then just eyedroppered the discrepancies over your DukePals.bmp

Once again thanks for the info, I will try your way too, if only as an exercise in CG. The .RAW format is new to me and sounds interesting.

Actually here it is:

[Kyanos]

Well, I've got a nice workflow going here using pics taken in 320 X 200 software renderer to get a perfect lookup of my pal strip in both water and nightvision.

@Craigfatman; I'm thinking of making a nice little tut for the wiki and was wondering if I can i) include your script unchanged from this thread or ii) link to it

[Jan Satcitananda]

Drek, on 06 January 2013 - 11:10 AM, said:

Well, I've got a nice workflow going here using pics taken in 320 X 200 software renderer to get a perfect lookup of my pal strip in both water and nightvision.

@Craigfatman; I'm thinking of making a nice little tut for the wiki and was wondering if I can i) include your script unchanged from this thread or ii) link to it

As for the tutorial, it would be really nice to have. Also I should state that the script is free for distribution and modification.

[Kyanos]

http://wiki.eduke32....ki/Highpalookup

The making of: Highpal Lookup Tables
 highpal_tutorial.pdf (290.49K)
Number of downloads: 7863

[Jan Satcitananda]

Drek, on 08 January 2013 - 07:23 AM, said:

http://wiki.eduke32....ki/Highpalookup

The making of: Highpal Lookup Tables
highpal_tutorial.pdf

Nice one, Drek. Quite detailed and intelligible, that's how a good tutorial should look. But there are several things to note. Did you know that this script has a TGA output feature? That is, when you go into that output mode by pressing the space bar, then if you hit F6 and save a TGA file, there will be your highpal ready to use. So you don't actually need to make any screenshots. I apologize if it wasn't clear enough, but you might have overlooked this function.

Otherwise, I'll link to your tutorial on my page about CLUT Stat when I finally get to writing it =P

[NightFright]

I am currently experimenting with removing all custom palette graphics from the HRP (in a local build of mine first, not in the SVN) in order to see what changes.

So far, what I can say about size is that the difference in size is not that spectacular. We are talking about maybe 30-40 megs. However, it could be that loading times decrease a bit, I need to check that out.

What I would like to know:
Are these custom tile skins/textures still needed at all, e.g. for Polymost, or would no one mind if they got removed completely? I still have to look at the results, i.e. how the highpal maps are doing in comparison, but if they are not totally off regarding colors and if it gains a noticable advantage, I guess some cleanup work in the repository would make sense.
If Polymost still requires them, maybe it could at least make sense to remove the extra pals from the Polymer dirs (and defs) and move them to Polymost subdirs/defs instead, for easier "isolation" in case you want to have a Polymer-only pack.

(Since I don't know how far this feature has progressed since its introduction and considering no one has tried to do this step until now, I hope that no one minds my minor bump of this thread.)

[Hendricks266]

Polymost still needs the alt-pals. In addition, there are some specific alt-pals (like the HUD expander crystal) that should be kept.

[LeoD]

NightFright, on 12 April 2013 - 04:42 AM, said:

I am currently experimenting with removing all custom palette graphics from the HRP (in a local build of mine first, not in the SVN) in order to see what changes.

So far, what I can say about size is that the difference in size is not that spectacular. We are talking about maybe 30-40 megs. However, it could be that loading times decrease a bit, I need to check that out.

What I would like to know:
Are these custom tile skins/textures still needed at all, e.g. for Polymost, or would no one mind if they got removed completely? I still have to look at the results, i.e. how the highpal maps are doing in comparison, but if they are not totally off regarding colors and if it gains a noticable advantage, I guess some cleanup work in the repository would make sense.
If Polymost still requires them, maybe it could at least make sense to remove the extra pals from the Polymer dirs (and defs) and move them to Polymost subdirs/defs instead, for easier "isolation" in case you want to have a Polymer-only pack.

(Since I don't know how far this feature has progressed since its introduction and considering no one has tried to do this step until now, I hope that no one minds my minor bump of this thread.)

The highpal feature (not supported by Polymost) still needs quite some adjustment. Using red and yellow keycards looks pretty bad for example. Therefore the removal of remaining alt-pals from the Polymer DEFs should be done carefully.


Given the size of recent model and texture additions the relative size of the Polymost overhead gets more and more negligible. You can create a Polymer (or Polymost) only HRP hierarchy any time by running ./installer/hrp_extract.sh, so the "isolation" is not that important.

FYI : current sizes (unzipped):
Full HRP : 769MiB
Polymer HRP : 681 MiB
Polymost HRP : 384 MiB
shared contents : 315MiB
Polymost overhead : 68MiB (<9%)
Polymer 'overhead' : 366MiB

[NightFright]

I see. Well, if you first had to compare whether highpals or the provided custom pal textures are better, then it's a painful process which might take quite some time. Right now, I guess we can leave it as it is. Still, in case this works acceptably one day, it could be an option, even though not that much is gained from it.