Jump to content
Search In
  • More options...
Find results that contain...
Find results in...
Donowa

New PLAYPAL proposal

Recommended Posts

Posted (edited)
22 minutes ago, MrFlibble said:

Yeah, I remember about the script, but from what I can tell the resulting file is nearly completely identical to that from original Doom (I just ran a comparison between COLORMAP lumps extracted from the nightly builds and from Doom shareware 1.9, and there were only 10 bytes different out of 8 704 bytes in either file).

 

My guess is that the entire script's purpose is to avoid including the original vanilla COLORMAP, which is still id/Bethesda property, by generating an analogous-but-free replica. If that is correct, using a custom COLORMAP would effectively remove the need for the script altogether. Or, it could be rewired to produce a COLORMAP lump of your own creation, better suited to your palette.

i think the colormap script just fades to black, which combined with the strange choices of the doom 2 palette (like having so many browns and yet no dark reds, or having magenta be so distinct from other colors that it fades into gray, or having 39 colors in the gray range despite having 32 light levels) gives you some pretty awful results

but even with just the edit of the doom 2 palette that i posted, it's possible to manually correct things so that they work well on the colormap (like making the dark reds/browns closer in hue to one another, or making the magentas be closer in hue to the flesh pinks) and combine that with manual ramping to make something that is visually acceptable and on par with the colormaps in quake, heretic, hexen, blasphemer, and strife

 

to be honest, one of the reasons that i wanted the palette to hueshift was because of how it could affect a manually ramped colormap and create a greater difference between bright and dark areas, but that plan was completely screwed over by how the colormap was auto genned

Share this post


Link to post
11 hours ago, Donowa said:

but that plan was completely screwed over by how the colormap was auto genned

I don't see how that could not be altered in the way the IWADs are built. If you palette works best with a custom COLORMAP (and I think the experiments above clearly show that this is the case at least in some instances), then it would make no sense to stick to the default COLORMAP it isn't suited for.

 

After all, the way Freed∞m's files are arranged is not set in stone. For example, up to a certain version the project used the GIF format for assets and also used symlinks to grab the actual files from folders named after individual contributors, which was completely overhauled at some point. I believe the same could apply to the current COLORMAP lump auto-generation procedure.

 

I'd love to see your palette with your own COLORMAP that reflects your vision of how this should work. I suppose that if the project maintainers like the results and approve its inclusion in the project, then they'll find a way to include your COLORMAP in how the IWADs are built. And if not, then we'll at least have a cool palette as an option to play with :)

Share this post


Link to post
Posted (edited)

image.png.9d1d31fb68e22aba9683738daa17de79.pngimage.png.957435f7d57ffd6e028cc142a7435b32.pngimage.png.6b8f04ec9b7dc1350c215a47b2366606.png
while i decided against reinstating the hueshifting, this is a concept i always wanted to do with the palette but fell through after the autogeneration got in the way: less obtrusive tints for software rendering.
from left to right, the palettes above are the item, pain, and radsuit ones at full opacity.

if anyone knows how to write a python script, i'd prefer if the pain and item palettes maxed out at 100% for their highest opacity, since the preservation of brightness renders the <100% tint maximums of the id palettes redundant

Edited by Donowa

Share this post


Link to post
Posted (edited)
1 hour ago, Donowa said:

if anyone knows how to write a python script, i'd prefer if the pain and item palettes capped off at 100% for their highest opacity, since the preservation of brightness renders the <100% tint caps of the id palettes redundant

I had a brief look at the current playpal script (I'm not experienced with Python but the language does not seem overly complicated). It looks like what it does is implement the changes that are described on the DoomWiki PLAYPAL page. Basically, each colour in the playpal-base lump is gradually shifted towards red, yellow or greed at fixed intervals, like the ones described in DoomWiki. The script does not set each colour individually, unlike what you seem to have done with your versions of the palettes.

 

I think that if the project is to use your palette and colourmap, it would make a lot more sense to ditch the Python scripts altogether and just use your lumps in building the IWADs. Like I said above, the scripts are seemingly only used to generate what is essentially identical to the vanilla palette without actually using it as a file (which would probably not be "clean" enough for FOSS purposes).

1 hour ago, Donowa said:

i'd prefer if the pain and item palettes capped off at 100% for their highest opacity, since the preservation of brightness renders the <100% tint caps of the id palettes redundant

I'm not sure I fully understood you here, are you suggesting to keep all palette indices at their max values, i. e. the ones you've shown above? (e. g., indices 2 to 8 would all be the same palette?) Wouldn't that make the Berserker pack effect tint the whole screen red in a way similar to the invulnerability powerup, instead of just giving a reddish tint but with otherwise discernible colours of the palette?

Share this post


Link to post
1 minute ago, MrFlibble said:

I'm not sure I fully understood you here, are you suggesting to keep all palette indices at their max values, i. e. the ones you've shown above? (e. g., indices 2 to 8 would all be the same palette?) Wouldn't that make the Berserker pack effect tint the whole screen red in a way similar to the invulnerability powerup, instead of just giving a reddish tint but with otherwise discernible colours of the palette?

i wasn't all that clear, but it's kind of a mouthful to explain in detail:
an example of what i was thinking of is the pain palettes. instead of having it increment in ninths (pal 1 at 11%, pal 3 at 33%, pal 8 at 89%) i'd have it increment in eighths (pal 1 at 13%, pal 3 at 38%, pal 8 at 100%)
the item palettes, on the other hand, would increment in quarters (pal 1 at 25%, pal 2 at 50%, pal 4 at 100%)
since the highest palette would cap at 100% with this different divisor, i said "capped off at 100% for their highest opacity" in the original post

Share this post


Link to post
15 hours ago, Donowa said:

an example of what i was thinking of is the pain palettes. instead of having it increment in ninths (pal 1 at 11%, pal 3 at 33%, pal 8 at 89%) i'd have it increment in eighths (pal 1 at 13%, pal 3 at 38%, pal 8 at 100%)

I think that it should be quite possible to implement in the current script. As a word of caution, I actually lack any firm understanding to figure out why it is written that way, but it looks like this change would achieve what you're aiming for (somebody please correct me if it does not):

# STARTREDPALS

for i in range(8):
    p = (i + 1) * 0.9 / 7 # was 0.9 / 8

    palettes.append(bias_palette_towards(base_pal, (255, 0, 0), p))

# STARTBONUSPALS

for i in range(4):
    p = (i + 1) * 0.5 / 2 # was 0.5 / 4

    palettes.append(bias_palette_towards(base_pal, (215, 186, 69), p))

 

Share this post


Link to post
5 hours ago, MrFlibble said:

I think that it should be quite possible to implement in the current script. As a word of caution, I actually lack any firm understanding to figure out why it is written that way, but it looks like this change would achieve what you're aiming for (somebody please correct me if it does not):


# STARTREDPALS

for i in range(8):
    p = (i + 1) * 0.9 / 7 # was 0.9 / 8

    palettes.append(bias_palette_towards(base_pal, (255, 0, 0), p))

# STARTBONUSPALS

for i in range(4):
    p = (i + 1) * 0.5 / 2 # was 0.5 / 4

    palettes.append(bias_palette_towards(base_pal, (215, 186, 69), p))

 

how would i make the palettes bias towards separate .lmp files instead of just an rgb value?

Share this post


Link to post

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×