76 replies to this topic

[Sheik]

Yes, I'd also say it's an improovement. It's obviously not 100% the tMC colours but it's close enough IMO.

[Cukeman]

This post has been edited by Cukeman

Edited by Cukeman, 30 April 2012 - 11:11 PM.

[Radien]

Cool. Thanks you guys. Next I will rearrange my colors, before I think about making them lighter.
I'll have to ponder over having both vertical & horizontal gradients for a while before I can really
understand what they are all about.

That sounds great. In truth, if you're going to experiment with stuff like making the WHOLE palette lighter at once, it's perfectly fine to rearrange the colors beforehand. As long as you don't play around with individual colors too much, the gradient progression will not be messed up.

Yes, pondering is good. I pondered DoR's palette for a long time. It's very difficult to fit it all together, but it will pay off... ESPECIALLY for a Minish Cap tileset. You will feel the benefit of it far more than I did, even with the DoR tileset.

Anyone know how to rearrange a palette without making a new one?

Well, I use Paintshop Pro 5 (good luck finding anyone else who does), and when I open the palette's color-editing window, it has a series of empty slots. If I select a color, and then click "Add Custom," it will copy that color into an empty custom color slot. I can store up to 32 colors this way. Then I can copy them back into the image palette in different spots.

Does your image program have a similar feature? It might be in the color-editing window when you edit individual palette colors. It's not the fastest way a program could conceivably do it, but it is a lot faster than many of the available alternatives.

[Cukeman]

This post has been edited by Cukeman

Edited by Cukeman, 30 April 2012 - 11:11 PM.

[Radien]

Well it's very easy for me to rearrange the color in another program (I have quite a few programs for that). I just don't
know of any way to bring a palette into ZC that wasn't made in ZC.

I have tried going to the palette editor and grabbing an image file for a CSet, but the colors become arranged very differently
than intended, and sometimes are not the same colors at all. Perhaps I am doing something wrong, or there is a completely
different process I don't know about.

I was thinking I could replicate my Main Palette in an 8-bit tile (which I have done), and exporting that tile/page.
But I don't now if it is possible to bring that into a new quest file as a palette.

Oh, so THAT'S your problem. Okay, well, let me see if I can figure out how to fix it...

First of all, open up the image's "edit palette" dialog and check the color order. It should match the color order of the snapshot you showed us. It is important that you were editing the palette itself, rather than painting with individual colors in an image that had a nearly limitless palette -- in other words, creating the snapshot palette image in high-color mode (a.k.a. "millions of colors") rather than taking a 256-color image and editing its palette manually.

If you were doing the latter, that means you haven't even really created a "palette" that is viewable by ZQuest. That would mean that you'll have to take the colors in the image, use the "dropper" tool on them one-by-one, and create an ordered palette out of them.

Secondly, you need to make sure that your image editor isn't automatically rearranging the colors "for you." Actually, I'm afraid that might very well be the problem, and if so, I don't know whether there's a way to solve it. But to check whether that is the case, save a copy of your image and then reopen it in the image editor. Make sure that it is sorting the colors by palette order, rather than "by luminescence" or some other auto-sorted order like that. In other words, each color is numbered 0, 1, 2, 3, 4, etc. and they should be in that order.

If you saved and uploaded your snapshot in a rippable 256-color format -- preferably GIF, without the illustrative numbers -- I could open it up in an image editor and see what the palette looks like. Since your snapshot is in JPG format, I have no idea what order the colors would be in your rippable version.

If you plan on editing an entire 256-color palette at once, ZQuest is a VERY inefficient way to do it. Since you can't copy individual colors from one CSet to another, you'd have to write down (or remember) the exact RGB values of a certain color and enter them manually into another CSet. Not efficient at all. It's worth the trouble to figure out how to edit palettes in another program and then rip them into ZC.

[Cukeman]

This post has been edited by Cukeman

Edited by Cukeman, 30 April 2012 - 11:11 PM.

[Radien]

Thanks Radien! I figured it out.

I'll detail what I did here in case it might help anyone to know:
I exported a tile page as a .gif (from a .qst file with the palette I wanted to rearrange).
Then I opened it in Photoshop CS5. Image > Mode was already set to Indexed Color
and 8 Bits/Channel. Image > Mode > Color Table... brought me to a place where I
could view the image palette. The dropdown selection is set to Custom automatically,
so from there I just had to click on a color, copy its html hexadecimal color code,
which is highlighted by default, click cancel, and then click on another color to edit it,
and paste the color code in that slot.

And after I finish editing and saving, it loads into ZQuest properly

Okay, great! It sounds like that must have taken a good 45 minutes to an hour, but now that you've done it once, you won't have to do all that work again. You can just change colors individually or use the hue/saturation/lightness tools on the whole image!
(When you are editing an image with 256 colors or less, the only way the image editor can change the hue/saturation/lightness is to change the palette itself, so altering the hue/saturation/lightness of the image is the same as altering its palette.)

[Cukeman]

This post has been edited by Cukeman

Edited by Cukeman, 30 April 2012 - 11:12 PM.

[Gleeok]

Cukeman: I just wanted to share with you: a few years back, before your join date IIRC, someone put together a really good 8-bit color MC tileset in zc with some fantastic looking tiles and AFAIK all of the dungeon tiles. I believe it's not in the database because it was never finished, but hours of tedious work has been done already.

I cannot remember who or what it was called (someone help me out here ), or even where a DL link is XD, but it would be worth checking it out. (Might save you literally weeks of work.)

[Cukeman]

This post has been edited by Cukeman

Edited by Cukeman, 30 April 2012 - 11:12 PM.

[Radien]

Gotcha.
Now that I have a photoshop file limited to my palette, I was hoping that I could
simply paste screenshots into that file to have them instantly recolored.

Unfortunately, more than one color was used to replace each color:

Yeah. When you paste an image from a different palette into a limited palette, it has to adjust to the new palette on the fly, so it uses the quickest method possible. I think the speckling you're talking about is called "error diffusion." It looks ugly, yes, but it's Photoshop's way of ensuring that one color is not identical to another, which would result in color loss.

If you want it to look better than that, you're going to have to import the palette into an image containing the graphics you want to recolor. I suspect and hope that your Photoshop has all of the features you need somewhere, so I'm going to tell how I do it in the hopes that something similar will be doable in Photoshop. (From now on I'm going to use the word "source" to refer to the image that needs to be recolored, and "destination" for your 191-color palette and the image that holds it.)

In my editor, I have two options under the "Colors" dropdown menu: "Save Palette," and "Load Palette." Much like ZQuest, if I save (export) a palette file, I can load (import) it into another image. So I save the destination palette, and get ready to load it into the image that holds the graphics to be recolored.

Once I open the "Load Palette" dialog, I'm faced with some choices. The exact same colors may not be available, so my program needs to know what to do with the ones that don't have an exact match. Paintshop gives me three options:

• Nearest color matching
• Error diffusion dithering
• Maintain indexes

If you use "Error diffusion dithering," you get the speckly effect you mentioned above that you want to avoid. So never pick that one.

If you choose "Maintain indexes," the program will presume that all the destination colors are in the exact same order as the source image. This would be a good choice for, say, taking an image that already uses BS dungeon colors and loading a different dungeon Level Palette into it (of course, this is a lot easier to do in ZQuest, but it's the simplest example I can think of). However, if you use it for your current problem, it will result in all the wrong colors in all the wrong places.

Now, "Nearest color matching" is the one you want. However, there IS a downside to this one. If you have two source colors that SHARE the nearest destination color, it will combine them. In other words, color loss. I'm sure you really don't want that.

How do you avoid it? Well, it's not an exact science, unfortunately. At least, not for me. What I do is I increase the color depth of the source image and use the dropper and color replacer to take colors from the destination image's palette, and replace one entire color at a time until the source image is similar enough to the destination image that I can import the new palette without seeing any color loss. As you might guess, it involves a lot of use of the "Undo" button, especially to undo the "Load Palette" action (if I see color loss and need to tweak it more before importing the palette).


...Okay, I hope that helps. Now you've gotten a glimpse into my mad science method of using a photo manipulation program for something it was never designed to do.


P.S. :
The final palette looks good. It'll be difficult to try to pick out colors by hand in some cases -- particularly when you need a very large gradient -- but hopefully you'll be able to employ Photoshop to help you with that.

My only concern is that each CSet might be a little too focused on one hue. For instance, let's say you have a Rope enemy. It might be mostly one color -- say, blue -- but it might also contain some reds, pinks, or yellows. You have those colors, but they are in other CSets, so you won't be able to use them without converting the enemy tiles to 8-bit.

[Cukeman]

This post has been edited by Cukeman

Edited by Cukeman, 30 April 2012 - 11:12 PM.

[Radien]

Unfortunately, I think that only indexed color images (like 256 color .gifs) will allow
me to view and edit their palettes. Although to be honest I will have to test out a few
other formats to make certain of that.

No, you're right. You can only edit the palettes of images that use 256 colors or less. But that's because any more than that, and the image basically doesn't HAVE a palette. A high-color BMP gives the exact RGB color values of every single pixel in the image, whereas a 256-color GIF assigns a RGB value each of 256 color slots, and then assigns a color slot to every pixel.

Your image represents the potential color values of a palette, but it doesn't actually contain the 256-color palette you want (the color slots beyond the first 191 will be blank, but the file format is still 256-color).

The thing is, you said you created a 256 (191)-color palette, and you must have if you uploaded a ZPL. Aren't you going to use that 256 color image from now on, since it uses a ZQuest-compatible palette format?

Also, if you have a high-color image and you want to import a palette into it, you should first reduce it to 256 colors. To ensure that you are left with only the 256 colors you want, eliminate all instances of other colors from the image (like the window frame colors or whatever).

You brought up the subject of enemies that would use more than one color shade.
I am still ignorant of why 8-bit color is not desirable for enemies, but I do need to
point out that no matter how I arrange my colors, my enemies can't have black outlines
unless I use 8-bit color depth. If I had CSets with 'frequent' color combinations as you
suggest, and didn't use 8-bit color, I would have to add a black to each CSet, and I don't
know that I can sacrifice that many color slots.

Sorry, I thought this had been discussed. But perhaps it wasn't in your thread. Here's the problem:

In the original Zelda, when Link and enemies are hurt, they flash. Flashing is accomplished by cycling the sprite through all the CSets at high speed. For it to work, though, the sprite has to use only one CSet. Once 8-bit color was implemented, if you chose to use it on Link or an enemy, flashing would become impossible, since changing the CSet on an 8-bit tile does nothing.

A few versions ago, Link got a feature which works around this. You can choose to enable "Link flickers when hurt," which causes Link's sprite to "blink" rather than flash when hurt. So, you can use 8-bit tiles for Link, but it'll still be obvious when he has temporary invincibility.

Since enemies don't have this feature, if an 8-bit enemy is hurt, it gets knocked back, but nothing else happens visually. ZC doesn't have "hurt" animation frames for enemies, either. Without any other visual cues, fighting enemies feels a little... awkward.

Now: I noticed that every CSet still contains at least one very dark color that is just a few points away from solid black. You have a very dark green, a very dark red, etc. These COULD be used as outlines. Now, I realize that Minish Cap might use absolutely solid black outlines on sprites (albeit thin outlines), so using something other than 100% pitch black may look different. But it probably won't look bad. Like I've said in other topics, most modern 2D games employ sprite palettes that do not have a solid black. Their outlines might be dark brown, navy blue, or dark red -- a color that goes well with the sprite. And since your CSets are each themed around a specific hue, such colors are easy to come by.

I do still have the use of CSet 13, which MIGHT allow me to move a bunch of colors down
there so that I could have a vertical strip of black, giving me one black for each CSet.
But I don't think this would work either. The reason being that if I am not using 8-bit
color depth, I am going to lose the whole left column of my main palette due to transparencies.

Because of this I think I HAVE to use 8-bit color depth on the enemies.

I will try to find out some way to change the palette settings for bringing in MC screenshots.

A vertical gradient -- even just one -- might still be useful. But if you are able to use the really dark reds/blues/greens etc. in place of blacks and shades of grey, you might not need to dedicate that column just to blacks and greys.

I would actually be more concerned whether you have enough contrasting colors available in any given CSet. Take for instance the Sluggula enemy (or whatever it's called). It uses blues AND yellows. If you were to choose just one CSet in which to color those, your options would be limited. Of course, I've noticed that you have a wide variety of colors in CSet 6, but you wouldn't be doing yourself any favors to color most or all of the enemies into CSet 6, obviously.

If BS is any clue, yellow is a useful color to put in every CSet, so you could have a vertical yellow gradient. You don't need to worry about whites and blacks if you have dark enough and light enough shades of other colors. You could also have a "misc." vertical column which isn't a gradient, but provides each CSet with a different contrasting color that will be useful in that CSet. For instance, a yellow CSet could have a single cyan color in that column, whereas a red gradient could have a single neon green color. If you want a great example of this type of coloring, look at the ropes in BS. Their spots contrast the rest of their skin color no matter what CSet they're in (especially in the original BS palette).


Okay, hopefully everything I've been saying makes some sense now. To sum it up, no matter which choice you make, you are going to have to give something up. Personally, I think it would be best to give up 8-bit enemy tiles and keep hurt enemy flashing...but whether you agree is up to you.

[Cukeman]

This post has been edited by Cukeman

Edited by Cukeman, 30 April 2012 - 11:12 PM.

[Radien]

I guess that will require testing to see both how good enemies look in dark colored outlines,
as well as how much loss enemies will suffer from not having those dark colors "inside the lines"

EDIT: Just thinking out loud, but you can set enemy hurt SFX, and I wonder on
a scale of 1 to 10 how hard it would be to tell enemies to use the hurt palettes when
damaged via scripting.

Hmmm. But since an 8-bit enemy uses colors from multiple CSets, it's not as simple as just spontaneously changing the CSet the sprite uses. You'd have to cycle individual colors, if that's even possible. Wouldn't it be easier to make them flicker when hurt? I would be very happy if someone scripted that. I already have Link flicker when hurt, and it's not because I use 8-bit Link tiles. I just think it looks better.