Anybody want a palette editor? [Bumpz]

Skip to latest update.

I decided to challenge my programming skills once again and choose to start a program capable of giving users complete control over editing a palette or colormap. Right now, the program is still in pre-beta stages, as there is a lot of design issues that need to be addressed before I can start on the actual program, but below is a screenshot of a concept program:

Edit: The program will look nothing like this. :P

Again, this isn't a screenshot of what the final thing will look like, but it will be quite similar. I was planning a double-pane view, where you could load a different file into each pane, like a playpal on the left and a colormap on the right (or another playpal for comparison purposes).

My goal is to provide a user-friendly interface, unlike those of XWE or DeepSea, something similar to Inkworks, only more powerful. You'll be able to edit any color/index in either type of file manually, or you will be to automatically generate the damage/pickup/other effects.

So my goals in a nutshell:

• Unrivaled user-friendly interface (this is the most difficult part).
  
• Support for all Doom, Heretic, Hexen, and Strife PLAYPAL and COLORMAP lumps.
  
• Complete control over the palettes and colormap entries.
  
• Many automated effects and filters to apply to palettes.
  
• Automagic colormap generation with various effect options.
  
• Completely self-contained and independant from all other programs.
  

That said, I know the demand is sort of high for such a program, since there isn't a whole lot of viable alternatives, but I'd like people to show support for this, mostly for motivational purposes. :)

There will be several disadvantages to the program. For one, it will only be available for Win32 systems. Another is that it will not load palettes or colormaps created by Inkworks or any other editor that exports their playpal or colormap files with extraneous data, because the file detection can only be done by the filesize of the lumps, since there are no headers.

I do plan on releasing it under the GPL, so you'll be able to tinker with the source code all you want.

So, I need to ask a few questions:

1) How would you immediately expect to interact with the program? Like, how would you like to go about editing the files, GUI-wise? Is there any sort of things GUI-wise, that I should not do, besides the blindingly obvious?

2) Would there need to be any support for non-standard PLAYPAL or COLORMAP lump sizes? So far there are Doom/Heretic/Strife palettes, double-sized Hexen palettes, and all colormaps (which are the same for each game). Is there any need for supporting smaller or larger PLAYPALs/COLORMAPS?

3) Are there any specific features you would like to see? I'm talking about preset effects, of customization options. Ways to modify the colors, or generate ranges of them. (And yes, you'll be able to modify the invulnerability effect for engines that support it.)

Hmm, that is all. I do plan on going through with this, and I will release a public beta as soon as I can finalize my design decisions.

Thanks for reading!

I'd like to see a feature where you can import palettes from gif images and use them for any of the game's 14 palettes. Likewise, I'd like to see a feature where you can export any of the game's 14 palettes as a gif image with the selected palette.

Awesome :)

EarthQuake said:

2) Would there need to be any support for non-standard PLAYPAL or COLORMAP lump sizes? So far there are Doom/Heretic/Strife palettes, double-sized Hexen palettes, and all colormaps (which are the same for each game). Is there any need for supporting smaller or larger PLAYPALs/COLORMAPS?

You could also probably toss in QUAKE colormap support too, then BAM, it's a fully featured QUAKE/QUAKE2 palette editor

that would mean implementing overbrights and fullbright ranges though :/

Doom_user said:

I'd like to see a feature where you can import palettes from gif images and use them for any of the game's 14 palettes. Likewise, I'd like to see a feature where you can export any of the game's 14 palettes as a gif image with the selected palette.

I definitely considered outputting the file to some graphics format for preview purposes, but if I actually did so, it would be an 8-bit windows bitmap (as I already have built-in functions at my disposal for that). I don't really want to bother with reading and writing a lot of unnecessary image formats though.

leileilol said:

You could also probably toss in QUAKE colormap support too, then BAM, it's a fully featured QUAKE/QUAKE2 palette editor

that would mean implementing overbrights and fullbright ranges though :/

I was only really aiming for something that would handle Doom-based palettes and colormaps, although if the Quake/Quake II palettes/colormaps use the same file format (and all I would need to do is raise the maximum filesize restrictions), then the program should already be capable of loading them. Could you provide me with palettes and colormaps for both (or file specifications), so I can consider it? If I did do this, it would be later in development, so it won't be a priority on my to-do list.

Edit: Also a GPL-related question... including the stock playpal and colormap files would be against the terms of the license, so how would I be able to include this vital data? As a separate download or forcing them to extract the stock lumps themselves?

Quake uses raw LMPs like Doom for colormap and palette. Quake2 uses PCX though

Can someone please explain to me what a palette is and what the practicality of changing it is?

The 8-bit renderer still used by most Doom ports cannot display more than 256 colors at a time. The palette is the list of said colors. If you change the palette, you change the colors that are displayed. This is a trade-off -- if you want to add a color, you'll have to remove another, and the sprites, flats and textures might look odd as a result.

Ports with an OpenGL renderer can display "truecolors" and are thus free from palette restrictions, but still use it a lot since all graphics in all original Doom engine games are paletted (mods for OpenGL ports might use truecolor formats such as PNG, but more often than not they're still paletted). Think of a sprite, patch or flat as a "by-the-number" coloring book. It's a list of pixels with a number associated to them. The palette tells the renderer that number 0 is that color, number 1 is that one, and so on until number 255, so the renderer can fill its coloring book accordingly.

Okay, I started working on this a bit more, and after taking a peek at Inkworks for the first time in like 5 years, I noted how the palette was drawn in a rectangle as opposed to a square:



The indexes are still in the correct order, they just "wrap" twice as often. By doing this, you can clearly distinguish each of the color ramps and it generally looks much nicer and cleaner.

However, there is a problem with rendering the palette like this... since I plan on supporting Heretic and Hexen, the palette turns into this awful mess, as obscenely illustrated below:



It wouldn't be so bad if Hexen's palette didn't have this tendency to make the color ramps "wrap" backwards.

The clutterfuck isn't as noticeable when displayed as a 16 x 16 square, so it would obviously look better in that form. But I really like how the Doom palette aligns so perfectly when rendered as 32 x 8. I don't see a compromise here, except for allowing the user the specify the dimensions. That's not quite as easy as it sounds, and it seems like a lot of trouble to go through for such a minor visual thing.

So... what do you think?

Should I just go with the 16 x 16 display? It would make the UI take up less space and avoid this whole problem, but then again, I like being indecisive.

Edit: There is also another option, but I don't see much of the point doing it that way.

EarthQuake said:

Edit: Also a GPL-related question... including the stock playpal and colormap files would be against the terms of the license, so how would I be able to include this vital data? As a separate download or forcing them to extract the stock lumps themselves?

I assumed your program would load them directly out of wads.

Anyway I think it is OK to incorporate the palette colors directly into your program (as a borderline GNU zealot myself). Whether palettes can be copyrighted is doubtful, and I'm sure that id software have said that they don't consider their palette to be an asset.

Regarding 16x16 versus 32x8, I think 16x16 looks much better, and is what I'm used to from other programs (like Yadex's built-in palette viewer).

Ah, thanks for your insight. I, too, was thinking the same thing, but what concerned me more was the inclusion of the Raven palettes as well as the Strife one. But if it turns out to be a problem, I can make those as a separate download. My intentions weren't to mess around with the Iwad, as that's sorta out of the scope of this project.

Anyways, I settled with the standard 16 x 16 display, and I've mostly completed the GUI. The program currently reads and writes palettes, but most of the menus and editing tools aren't functional yet, so don't expect a release any time soon. I'm pretty much working on this between other projects and when I have spare time.

Anyways, here's a teaser screenshot. :)



Some details about how the program will operate...

You will be able to load a palette and colormap simultaneously and switch back and forth using the tabs. In palette mode, you can switch between tables and generate all of the fade effects using something called a "color difference table". These files store the information needed to apply to the base palette to get each degree of fade for each effect. I will include these with the program.

You can edit any table, and any of the indexes within that table. I have various color algoritms you can apply to colors, like adjusting brightness, contrast, saturation, hue, etc. You can even automatically generate gradients from one color to another, to insert into your palette.

Cutting, copying and pasting will be very useful in this program, so I've added my own implementation of a "clipboard". It stores up to 256 colors and you can directly see what's in it. You will be able to paste a specific color, all of them one-by-one, or all at a time within a table. Think of it as some extra space for moving around color indexes. You can edit things on the clipboard too.

When on the colormap tab, the swatches are replaced with indexes from the palette and you can select from those to build your colormap by hand. There will also be tools for generating effects on the colormap, and finally, an automatic generation tool with various options you can set to affect the results of the colormap.

So yeah... there you have it. The Photoshop of Doom palettes.

Wow, this sounds pretty nifty. :)

What about a preview, what a selected sprite/texture/whatever will look like with the new palette?

Also, just reading the data from the IWAD should be no problem. Anybody using this program will have one IWAD or another anyway.

That looks great! May I suggest moving the right panes to the left though? It decreases the maximum mouse travel distance, and while this might not seem like much at first, after using a program for a while it would rack up to quite a lot of mouse movement.

Oh this is looking really awesome. Something like this really would have made my life easier a month or two ago. Good luck with this, I know lots of folks will really appreciate the effort :D

boris said:

What about a preview, what a selected sprite/texture/whatever will look like with the new palette?

I concur, that would be a useful tool. I think DeePsea's palette editor had something similar, though if I remember it was just 3 or 4 images with Doom texture and sprites scattered around. Something where you could view any sprite or graphic in the current palette/colormap would be superb.

EarthQuake said:

1) How would you immediately expect to interact with the program? Like, how would you like to go about editing the files, GUI-wise? Is there any sort of things GUI-wise, that I should not do, besides the blindingly obvious?

I never actually modified the pallete before so I have no idea what to do. But if I did know i'd probably change all the colors to brown to see how epic it looks.

Thanks for the interest guys. I really felt like it was time to contribute something useful to the community, and you all showing support really helps motivate me. Thanks.

boris said:

What about a preview, what a selected sprite/texture/whatever will look like with the new palette?

Already planned. Not quite sure how I'll go about doing it. Does XWE allow you to export raw doom-format images? Is so, they should contain not color information, but indexes to colors in the palettes. I could probably read these files quite easy, and supply samples for each game. The user could then import their own raw images if they so felt like it.

exl said:

May I suggest moving the right panes to the left though? It decreases the maximum mouse travel distance, and while this might not seem like much at first, after using a program for a while it would rack up to quite a lot of mouse movement.

This is certainly something I've accounted for. I've already planned to have context menus (right click) and keyboard functions/shortcuts to reduce the number of mouse clicks and distance needed to travel with the mouse. But you're probably right about having the swatches on the left side; the toolbar and Edit, Palette, and Colormap menus would be directly above it. Also, putting the information areas toward the bottom, and the swatches and such closer to the top would also help.

This is interesting, I very much want to see this done and am willing to help if I can (suggesting features and giving input as I am working on making my improved colormap for Doom).

Also, as a reply to your question in the other thread: Sure you can include my colormap in your prog, once I have it finished. What I posted was just a very quick test and there is much more to be improved.

I've been working on Prisma lately, and I've finished a good chunk of the low-level file and palette manipulation code. I'm stuck though, and I really don't think I can continue until I get some more feedback on the following design options. Any input is greatly appreciated.

This is a very long post for me, but it's a good peek at the development path of Prisma. This post is mostly about the user interface of Prisma. Anyways, let me get started...


Design Decision 1 - Displaying Files

After coming to the realization that a user has no real need to edit a palette and colormap at the same time, I have reverted back to the fixed-window interface with a tabbed display. Loading a palette or colormap will add a new tab to the window, and switching between the two will allow each different editor to be displayed. It makes no sense to allow the user to load a colormap without a palette loaded, so I've disabled this. Unloading a palette will also unload a loaded colormap.

Let me talk about the colormap first. When viewing a colormap, you do not need color swatches (.act files) loaded or any palette-related tools displayed (as the colormap must use only colors from the palette). Instead, I got the idea from MSPaint, that the colormap could be drawn on, using selectable colors from the loaded palette (shown as a set of swatches on the side). You can also use the margin area around the colormap to drag entire columns left or right, or entire rows up or down. This would facilitate organizing of the color ramps in the colormap.

To keep the size of the drawing area consistent with that of the palette, the colormap would need a scrollbar to move horizontally to show all color mappings. Each color would be represented as an 8x8 pixel cell, with color 255's column on the far right end of the scrollbar. This allows for the user to view 32x32 cells at a time (or roughly one-eighth of the entire colormap).

Question 1:
Is this cell too small on modern displays to be easily drawn on? Would allowing the user to zoom in (adding a vertical scrollbar) be a worthwhile endeavor? A size factor of 2 would make each cell 16x16 in size, but you would only see half of the height of the colormap (one-sixteenth of the entire colormap).

Question 2:
Is this zoomed-in area too small of an area to work with, considering that manually editing the colormap is best done when you can see how a color will fade off into darkness (e.g. seeing all 32 mappings of each color)?

Now about the palette...

When you open a palette with Prisma, it is displayed in a 16x16 grid of 16x16 pixel cells. Doom palettes actually have 14 palettes (which I call "tables"), and Hexen has 28. Each of these, aside from the first, show different fade and tinting effects. I have implemented a combobox that lists all of the tables with a short description depending on how many tables there are (e.g. is it Doom or Hexen?). Selecting another table will swap the currently viewed palette with another table in loaded palette file.

Question 3:
Is there any solid reason why a user would want to alter these additional tables on a color-by-color basis? For the fade effects to look right, these tables must use the base palette as a base for the fade effect. I already plan to implement automatic building of the fade effects (where the user can choose a color to fade to, the degree of which to fade, and what type of fade calculation to be performed), but is it really necessary to be able to manually edit all of these tables, color-by-color?


Design Decision 2 - Previewing Palettes and Colormaps

I have already written routines to load raw sprite and patch graphics. Deepsea does something similar, only the preview images are preconstructed to show all the possible colors and such. Because of the way these files are stored, the maximum image height can only be 256 pixels.

Question 4:
Is 256x256 an acceptable maximum preview size? You will be able to load any valid Doom picture format, but handling taller images requires more code and needs a scrolling viewport (like the colormap).

There will also be an option to change not only which palette table is used (e.g. to see the image while being "damaged"), but also which colormap mapping to display it in, so you can see how it looks under different light levels (such an option would be disabled if there was no colormap loaded).


Design Decision 3 - Selection System

In Prisma, I have written some basic code to handle the selection of colors when editing the palette. Clicking on a color will highlight that color. Holding CTRL and clicking a color will select or deselect it, much like icons in Windows Explorer. Holding SHIFT and clicking on a color is a bit unpredictable. It will select ranges of colors in the palette, but because of the way color ramps usually flow, the selection box may wrap around to the next line, sort of like how text is selected using SHIFT-click.

Question 5:
Because you can CTRL-click color to do an additive select, what would be the expected outcome if you SHIFT-clicked after having more than 1 colors selected? Should the SHIFT-click routine select all colors between the lowest or highest color index selected? This would mean you can't actually deselect colors using SHIFT-click, like you would with Windows Explorer or Notepad. Not sure of how to go about this one. :|

Next up is the way selected colors are stored internally. There will be a fixed array that corresponds to each color in the current palette (probably a byte array; 0 for not selected, 1 for selected). When you perform an operation like copy/cut/clear/delete or you modify the hue/saturation/brightness using filters, it will affect all palette colors of the current table, if and only if they are "selected" in the "selection array".


Design Decision 4 - Temporary Workspaces

In a program like Prisma, it's fairly obvious that moving things around in the palette can feel a bit "tight" if you're completely redoing the palette. You might want to experiment with color ramps and such without actually modifying the palette. To remedy this, I've decided to implement a clipboard system where you can view colors stored in it, copy colors to it, paste colors from it, and modify the colors within it. Colors generated with the gradient tool can also be sent here.

Now, I have an alternative to this, which is much more simple in design, but can be just as useful.

Let's call it the "Color Deck", and let's think of it as a deck of cards. When you copy something to it, the copied color gets tacked onto the end of it (like putting a card on the bottom of the deck). When you paste to a selected cell in the palette, the color can be taken from the Color Deck, much like drawing a card. The next "card" would be the next color in the deck (the previous one would have been removed from the deck). In addition to this, there can be a drawing mode, where it "draws cards from the deck" instead of selecting colors when you click on them.

Available tools could be "selection mode", "drawing mode", and maybe some helper modes like "copy mode" (the inverse of "drawing mode").`

Question 6:
Which would you prefer: a temporary workspace that resembles the palette (would require another tab), or the "color deck" idea (which can make better use of screen real-estate)? What about a combination of both? Is there a better idea?


Design Decision 5 - Miscellaneous Features

There are several special effects that the colormap can achieve. Aside from the darkness mapping, the invulnerability effect is stored as the next to the last row. You can't edit it directly, and it's only supported by more pure Doom engines, but you'll be able to build an assortment of effects in different colors. The last row in the colormap is unused (it's totally black). In Alpha versions of Doom, I believe this was used for the Radiation Suit pickup.

Question 7:
Can anyone verify this? If so, would there be any interest in Prisma supporting this?

If there is not enough interest, that means the last 256 bytes in the colormap are possibly completely unused by anything else. I could use this area for storing additional data or author comments, etc. Prisma also supports the use of 72-byte comment tags, the basis of which comes from Inkworks. If you view any palette created with Inkworks in XWE, you'll notice 24 extra oddly colored cells in a "15th palette". This is actually text that contains information about Inkworks. In Prisma you can edit these, add your own, or choose to remove them.

Question 8:
Assuming colormap row 34 is not used by any Doom-based game (other than the alpha versions) or any Doom-based utility, does it sound like a good idea to use this extra 256 bytes for something else?

Another neat colormap effect I planned on doing was supporting infrared color effects in the palette. Strife makes use of this, where certain color indexes in the palette will show as full-bright in-game. This is done by setting each color in a given colormap column to the first color index. This is a very easy operation, so expect to see it in Prisma.


I believe that wraps up most of my major concerns. I know it's a long read, but if any of you would love to see Prisma before 2020, I really need some input! Basically, I'm asking about how you, the user, would prefer to interact with the program, and what features would make the most sense to a typical user. I want Prisma to be as simple and straightforward as possible, so it can really be the most advanced palette and colormap editor for Doom-based engines!

Once again, thank you for reading, and even more thanks for providing your thoughts and opinions. :)

One word - awesome!

Great timing, I was actually thinking about bumping this last night to ask if it was still in development. Anyway, to answer your questions:

Question 1:
8x8 pixels? That's definitely way too small to draw on, even with this monitor I'm using now that tops out at 1024x768. I usually go for a 400-600% zoom level when doing pixel art on here, for example. I think you definitely need to rethink this one.

Question 2:
Similarly, I don't see any point at capping this at such a low amount. Let users maximize the program to their full resolution and zoom in as much as they want.

Question 3:
There are a lot of cool effects that could be done here but never have, probably because of the lack of a decent tool to do them. For example, what if you wanted the colors to get brighter when you picked up an item, instead of fading to another color? What if you wanted the radsuit to invert the palette like the invulnerability powerup. What if you wanted some colors to go grayscale, while others remained at their normal shade? The later would actually be easiest to do manually I'd think, while the others could be handled by an automated process. What I'm getting at is don't limit yourself to just doing fades for these palettes.

Question 4:
I guess it would be all right, but I'm not seeing any real reason to cap it there.

Question 5:
I think shift clicking should select everything between the two ranges. I don't see any reason for it to work any other way. I'm not sure why you say you couldn't deselect them in this same way, though.

Question 6:
I like the palette clipboard more, personally, but it should (optionally) be visible at all times while working on the palette, for easy access. If it's on a separate tab I'm not likely to make use of it.

Question 7:
The last row of the colormap was actually used for the light amp visor, it turned the whole screen dark green and actually made everything harder to see in most cases. Probably why they went with fullbright instead.

I'm not sure I'm understanding what you're asking here, but editing the invulnerability map is definitely something I'd like to see possible.

Question 8:
Since this row isn't usable in any port outside of MBF as far as I know, I don't see any point to utilizing it. I don't see any point in not allowing it to be edited either, though. This does give me an idea. Allow specifying the row(s) when generating the colormap. You could do some interesting effects with this, like making the rows nearly 255 brightness fade closer to white, to simulate the glare of a really bright outside area. You could even edit the brightest row separately to customize light-amp in the final version of the game.

Specifying certain palette indices that should always be drawn fullbright would be a really cool feature too. There's definitely a lot of cool things that could be done with that for a TC.

EarthQuake said:

After coming to the realization that a user has no real need to edit a palette and colormap at the same time, I have reverted back to the fixed-window interface with a tabbed display. Loading a palette or colormap will add a new tab to the window, and switching between the two will allow each different editor to be displayed. It makes no sense to allow the user to load a colormap without a palette loaded, so I've disabled this. Unloading a palette will also unload a loaded colormap.

SLADE3 uses a default greyscale palette (index i is R:i G:i V:i) if no other palette is found. Maybe this could be used too?

EarthQuake said:

Is this cell too small on modern displays to be easily drawn on? Would allowing the user to zoom in (adding a vertical scrollbar) be a worthwhile endeavor? A size factor of 2 would make each cell 16x16 in size, but you would only see half of the height of the colormap (one-sixteenth of the entire colormap).

Zooms are needed. The user needs to be able to zoom in to be sure to be precise, and to zoom out to get a better look at the result.

EarthQuake said:

Is there any solid reason why a user would want to alter these additional tables on a color-by-color basis? For the fade effects to look right, these tables must use the base palette as a base for the fade effect. I already plan to implement automatic building of the fade effects (where the user can choose a color to fade to, the degree of which to fade, and what type of fade calculation to be performed), but is it really necessary to be able to manually edit all of these tables, color-by-color?

Yes. This is needed for palette hack effects, like the one used in Strife and Harmony to have certain colors always full bright.

EarthQuake said:

There are several special effects that the colormap can achieve. Aside from the darkness mapping, the invulnerability effect is stored as the next to the last row. You can't edit it directly, and it's only supported by more pure Doom engines, but you'll be able to build an assortment of effects in different colors. The last row in the colormap is unused (it's totally black). In Alpha versions of Doom, I believe this was used for the Radiation Suit pickup.

Can anyone verify this? If so, would there be any interest in Prisma supporting this?

No, it's a bit more complicated than that.
In the Doom Press Release Beta, colormap #33 is used by the light amplification visor, and colormap #34 is used by invulnerability.
In the final version, they've changed light amp to use colormap #1 (making it full bright everywhere) , and the invulnerability colormap has been shifted to #33, leaving just blackness for #34.

EarthQuake said:

Prisma also supports the use of 72-byte comment tags, the basis of which comes from Inkworks. If you view any palette created with Inkworks in XWE, you'll notice 24 extra oddly colored cells in a "15th palette". This is actually text that contains information about Inkworks. In Prisma you can edit these, add your own, or choose to remove them.

About that. See this thread.

Personally, given that palettes and colormaps are lumps with no header or metadata, I'd prefer if such things were avoided. It makes proper identification of them in tools such as SLADE3 harder.

EarthQuake said:

Assuming colormap row 34 is not used by any Doom-based game (other than the alpha versions) or any Doom-based utility, does it sound like a good idea to use this extra 256 bytes for something else?

If there is one game community that is likely to consider creating a mod for the alpha or beta versions of the game, it is the Doom community. ;)

Reaaaaally happy to see your working on this Earthquake. I was actually considering bumping this or PMing you to see if you were going to continue working on it. I'd probably be one of many who would find it extremely useful :)

Is this the reason why you stopped appearing on IRC?

Otherwise, looks neat, will there be a port for Linux?

Sorry, late reply. I was going over and over some things said in this thread. I think by now it's pretty clear that this is new territory for me, but I'm still dedicated to finishing Prisma. When it comes to GUIs, I don't think I've ever had as many problems as I have had with Prisma. There are a lot of options, and I'm still unsure of which would work the best.

Dragonsbrethren said:

8x8 pixels? That's definitely way too small to draw on, even with this monitor I'm using now that tops out at 1024x768. I usually go for a 400-600% zoom level when doing pixel art on here, for example. I think you definitely need to rethink this one.

Similarly, I don't see any point at capping this at such a low amount. Let users maximize the program to their full resolution and zoom in as much as they want.

Having a full-screen application like XWE would be useful, but the amount of code required to handle all the control resizing and display drawing is more complex than you would expect. I've been really distraught over this, trying to find a compromise that works. I am an artist first and foremost, so as a programmer I find myself sacrificing a lot of things in order to not only make my code neat and simple, but to also make my applications look professional.

Simply put, my philosophy is to write code in as simple of a form as possible, that does what it needs to do. Else, it becomes unreadable and unmanageable.

Dragonsbrethren said:

There are a lot of cool effects that could be done here but never have, probably because of the lack of a decent tool to do them. For example, what if you wanted the colors to get brighter when you picked up an item, instead of fading to another color? What if you wanted the radsuit to invert the palette like the invulnerability powerup. What if you wanted some colors to go grayscale, while others remained at their normal shade? The later would actually be easiest to do manually I'd think, while the others could be handled by an automated process. What I'm getting at is don't limit yourself to just doing fades for these palettes.

The palette fade generation takes into account various blending styles (inversion, brightness, saturation, etc), so the things you mention are easily doable. Each palette table is configurable independently, although I will definitely add presets for each of the supported games. For the sake of maximizing the potential of Prisma, I'll stick with my original plan and allow manual editing of all colors.

Dragonsbrethren said:

I guess it would be all right, but I'm not seeing any real reason to cap it there.

It has to do with the way the columns are stored in the picture files. For more information, see here. I don't see a problem, as nearly all sprites or wall patches are no larger than 256x256, and I don't want to do anything complex with the preview window as it's not a vital function of the program.

Dragonsbrethren said:

I think shift clicking should select everything between the two ranges. I don't see any reason for it to work any other way. I'm not sure why you say you couldn't deselect them in this same way, though.

Trying shift clicking in a folder full of icons. Then try it in various text editors or your internet browser. Note how the behavior is inconsistent (even amongst text editors!). Since the selection of colors in the palette can be fragmented and they are arranged left-to-right and top-to-bottom, figuring out how to handle the shift-selection behavior isn't quite so straightforward (in other words there aren't always two colors to select a range between). By storing the last selected color, I can add some more flexibility to way it currently works. For the most part, users won't notice anything odd, since when range-selecting one normally will not have a bunch of scattered colors selected.

Dragonsbrethren said:

I'm not sure I'm understanding what you're asking here, but editing the invulnerability map is definitely something I'd like to see possible.

Again, you've made a point. Manual editing would be nice. I was going to go for the automatic approach, where the user specifies a combination of colors, similar to how it is in Inkworks. I'll have to see what I can work out here.

Dragonsbrethren said:

This does give me an idea. Allow specifying the row(s) when generating the colormap. You could do some interesting effects with this, like making the rows nearly 255 brightness fade closer to white, to simulate the glare of a really bright outside area. You could even edit the brightest row separately to customize light-amp in the final version of the game.

Not quite sure what you mean here. You mean fading to another color other than black? You can't really mess around too much with the colormap especially towards the beginning, as it will affect a lot of things, like the fuzz effect or full-bright sprites.

Gez said:

SLADE3 uses a default greyscale palette (index i is R:i G:i V:i) if no other palette is found. Maybe this could be used too?

This is what I did in my test runs to see if the pictures were actually loading correctly. I suppose it's not a bad idea, but I don't see the usefulness. There is nothing necessarily meaningful about mapping the indexes to grayscale colors.

Gez said:

Yes. This is needed for palette hack effects, like the one used in Strife and Harmony to have certain colors always full bright.

This is done in the colormap only, not the palette (if memory serves). Having "fullbright" colors throughout the palette will just exempt those colors from being affected by the fade/tint effects (which might I add, is something probably worth playing with too).

Gez said:

No, it's a bit more complicated than that.
In the Doom Press Release Beta, colormap #33 is used by the light amplification visor, and colormap #34 is used by invulnerability.
In the final version, they've changed light amp to use colormap #1 (making it full bright everywhere) , and the invulnerability colormap has been shifted to #33, leaving just blackness for #34.

Ah, thanks for the clarification. At the moment, I think this is not of high priority to implement, but it would be nice as a feature in later versions, assuming I can get this damn thing off the ground.

Gez said:

About that. See this thread.

Personally, given that palettes and colormaps are lumps with no header or metadata, I'd prefer if such things were avoided. It makes proper identification of them in tools such as SLADE3 harder.

I see. But why does SLADE have problems with reading these files? I've personally had no difficulties. It's a matter of doing various checks on the filesize and taking into account InkWork's blunder. I actually wanted to use this to the users' advantage (although disabling it by default). Is it really a sin? I mean, under rare circumstances, the user may be able to load an invalid palette or colormap file, and the program will reflect that as a jumbled display, but it should be immediately apparent they loaded something that isn't a palette or colormap. :)

Gez said:

If there is one game community that is likely to consider creating a mod for the alpha or beta versions of the game, it is the Doom community. ;)

Hehe.

GhostlyDeath said:

Is this the reason why you stopped appearing on IRC?

Otherwise, looks neat, will there be a port for Linux?

No. And no.

EarthQuake said:

I see. But why does SLADE have problems with reading these files? I've personally had no difficulties. It's a matter of doing various checks on the filesize and taking into account InkWork's blunder.

That's it. There are tons of different formats that have to be identified (image formats, sound formats, music formats, model formats, binary lump formats...) and having things taken on like this prevents the simplest methods from working, since the size, instead of being a round multiple of 768, can be arbitrary...

Wow! This would be so cool to have. As far as GUI, I don't have much to request - I feel like all I would want is to be able to select a range and make a gradient of colors.

This may be extraneous, but what about being able to view translations in the preview thing? Or even being able to have the program generate translation strings for decorate with some easy select-the-ranges option? I hate firing up the game 20 times just to see if I got that one weird pixel to change...

It would be cool if someone was able to take a couple screenshots of Doom that feature every color in the pallete's range, then be able to see those screenshots with the new pallete applied to it.

I really love the 32x8 layout much better than 16x16 as the ranges are much more apparent.

Anyway, I love that you're doing this program and I can't wait to get my hands on it.

Okay, so I finally got over myself.

I have (what I hope to be) the final design. Everyone I talked to about the program, pretty much said the same thing: the interface needs to be resizable. It's a bit more complex to work with, but it's much more flexible and should please it's users.

Here's what it looks like so far. The elements on the left are fixed in position, but everything else stretches to fill the screen or to whatever size the user wants. That should make most people happy and solve the zoom issues (and allow the possibility of 32x8 displays).

I also took the past several days to rethink the simplicity of the interface as well. I realized I was probably making the program more complex than it needed to be. You'll still have full control over everything, but I'll have less headaches at the end of the night, and you guys might actually see a release sometime before 2057.

Well, it's late. But I felt like I have made much progress. I'll have more details as I get more things working again.

By the way, does anyone know what method the Heretic, Hexen, and Strife colormaps were generated? They're very different from the Doom one in that color ramps tend to not to reference colors from other ramps. I take it the color matching algorithm only took a range of color indexes and returned the best of those (as to restrict the results to a certain range?) Any idea how I could do this for Doom, where the color ramps tend to be "fragmented"?