76 replies to this topic

[Radien]

It's not really that hard to change them. Using them is a matter of memory, though. If your palette is easy to read, then it will be easy for people to use the colors that ZQuest's gui covers up. Like I said, though, the colors are only screwy in ZQuest. In ZC they work fine, as shown in the quest in my previous post. The only thing is, there is a weird glitch that doesnt let you select anything from palette 15 in the tile editor, and if you're using 12 and 13, you might want to avoid using boss C-Sets.

I've known this was how it works for a long time, but personally I find those extra colors far to difficult to access for it to matter. And since they're GUI colors, you can't customize them, right? If Cukeman is making his own palette intended JUST for 8-bit tiles, he will already have a huge number of colors represented.

C-set 12, 13, 14, and 15 are used for ZQuest's GUI colors. Zelda Classic and ZQuest can only display 256 colors at one time. This includes the GUI elements. However, 12, 13, and 14 are only used as GUI colors in ZQuest.
Boss C-sets get loaded into C-set 14, then if there are more than one type of monster that uses extended C-sets, 13 and 12 are filled as a result.

So THAT'S how it works. I had wondered for quite awhile how ZC handles boss palettes without overloading the 256-color limitation when multiple extra sprite palette CSets are required at once. I wonder if it's possible to overload the palette with more than four different extra sprite palette CSets on the same screen? I expect ZC would either have display flaws, or it would crash..

So if I am only using colors in the Main Palette, I won't be using boss colors anyway, right?

Yes, this is correct. Many tilesets have duplicate CSets in the extra sprite palette, for simplicity -- for instance, most tilesets have a copy of Ganon's CSet in the slot for CSet 11, even though he doesn't actually use CSet 11.

Personally, my quest's Gleeok and Aquamentus enemies use colors that aren't available in the main palette. I don't remember whether I included those CSets in the public tileset.

[Cukeman]

This post has been edited by Cukeman

Edited by Cukeman, 30 April 2012 - 10:54 PM.

[Alestance]

I think you can use those last two c-sets to add more deluded/desaturated variations of the ones above. Because of the lack of saturation, you can probably swing on reducing those color options to the 32 last color slots.

Yeah, I realized you cant select the 14th c-set late.

[Cukeman]

This post has been edited by Cukeman

Edited by Cukeman, 30 April 2012 - 10:54 PM.

[Alestance]

No, you shouldn't move any colors, add grayer shades of the most prominent colors into 12 and 13.

[Radien]

Cukeman, I forgot that you were the one who created this topic. Are you going to use your work here for the Minish Cap tileset? It would be a different approach, and I think a different approach is what a Minish Cap tileset would need the most, so I'd encourage it.

[Cukeman]

This post has been edited by Cukeman

Edited by Cukeman, 30 April 2012 - 10:55 PM.

[Radien]

Hey, that looks great. I think that screenshot comparison is proof that your 191-color palette is the way to go for a Minish Cap tileset. The colors will look a little bit different from the original, but I think it will be as close as ZC can possibly get to capturing most of the game.

As for whether it should be modified: you could possibly tweak it a little bit, or at least some parts of it. Minish Cap colors are a little more pastel, and a little less vivid (slightly lower saturation). But even if you stuck with it as-is, it would still look pretty good.

The majority of the color adjustment could even be done all at once, by using the Brightness, Contrast, Saturation, and Lightness controls on the palette in an image editor.

One thing to keep in mind, though: Minish Cap's sprites are brighter and more vivid than its stationary objects. I'm not sure how to account for that, but it's often the case in cartoonish 2D games.

[Cukeman]

This post has been edited by Cukeman

Edited by Cukeman, 30 April 2012 - 10:55 PM.

[Sheik]

Interesting approach. But you do notice that this method is messing up lot's of the initial settings for example for enemey-flash (when they are hurt) and you'll have to script around these things (along with creating sprites for every enemey coloured in a "hit-palette") which might end up being a pain in the ass? My approach of a Minish Cap palette set up was something like this:

0 - Frozen Paltette (that was due to having Ice Arrows and similar stuff in a certain project, but could be anything else)
1 - Hit Palette (for 8-bit enemies and big enemies)
2, 3, 4, 9 - Background
5, 7, 8, 10, 11 - Sprites
6- Link

It worked fairly well in it's baby steps. I think James uses it for the BS/MC tileset I started and let him took over after I lost interest. But it obviously doesn't work without palette changing (which isn't such a bad thing).

Still, good luck with your method! This is looking quite promising so far.

[Cukeman]

This post has been edited by Cukeman

Edited by Cukeman, 30 April 2012 - 10:55 PM.

[Radien]

Well, here's an idea, although I freely admit it's not an easy one to manage:

Rather than having the entire palette be a series of ordered gradients, you could divide the existing colors up and reorganize them into CSets that each contain a wide enough variety of colors to serve as an enemy CSet (and possibly a Link CSet). That way, for each enemy you could pick the most appropriate CSet and hopefully recolor it in a manner that is faithful to the original.

If you simply reordered the existing colors, you might not have to sacrifice much to do this, but the color organization would have to be completely different. Also, depending on how you do it, you might have to pick and choose colors from different CSets to achieve one color gradient (for instance, "to get a shade of green that's halfway between these two colors in CSet 8, I'll have to borrow a green from CSet 0..." and stuff like that).

The upside to this method is that being able to select which CSet an enemy uses makes them muuuuuuuuuch more flexible. But you do have to organize colors into CSets in order to take advantage of "hurt" flashing for enemies.

It's fortunate that there's an option to make Link flicker when hurt, but not so fortunate that the same feature is not yet available for enemies. I have been hoping ever since 8-bit color was introduced that this feature would someday be implemented.

[Sheik]

EDIT 3: BTW, Sheik91 how did you get your hurt palette to work in CSet 1?
The default hurt palette flashes CSets 7, 8, and 9

I'll admit I haven't. I think it's quite possible with scripting, though, and I used to work together with probably the best scripter (one of the best at least) on this board so would I've used the palette I had in mind I'm quite sure he would've made it work. I have next to no clue about how the engine exactly works and I always have/had a hard time getting the roll of it. Which is why at some point I decided that I only work on "creative aspects" of my projects and someone else was handling the set-ups.

[Cukeman]

This post has been edited by Cukeman

Edited by Cukeman, 30 April 2012 - 10:55 PM.

[Radien]

That would be, say a CSet of reddish colors, a CSet of Bluish colors etc?
I was already going to rearrange the colors I have now in that way (but not change any colors) so that
palette swapping could happen.

Yes, that's totally what I would suggest. Sounds great! But to take it one small step further...

Rather than put all the bluish colors in one CSet, you could have a few columns of colors which span across several CSets and contain VERTICAL gradients. Unsure of how to do this? Well, see below.

I can't think of a way in which they would be more flexible... For instance...?

Are you familiar with Linkus' Project Chromosome? Perhaps you won't want to imitate his idea exactly, but you may be able to draw some inspiration from it.

Even if you don't make it so that every hue has a vertical AND a horizontal gradient, you could throw in a few vertical gradients. Those might serve a purpose similar to the colors in Pure that don't change between CSets. Remember how Pure (and BS, for that matter) had a red and a yellow which served solely as "belt" colors for the enemies? It wasn't efficient, but BS wasn't designed for 8-bit color, so it was a necessary step. What if all those identical reds and yellows were instead a red vertical gradient and a yellow vertical gradient?...

EDIT:
An example image ought to help a lot here. Below is the BS main palette (I'm using it as an example just because I'm really familiar with it). To illustrate, I circled the "belt colors" that remain identical (or at least similar) through several BS sprite CSets.



Now, imagine if that series of identical yellows and somewhat similar reds were, instead, two vertical gradients. See?... (In fact, the reds are already almost a gradient, though I'm sure that was an accident.)

P.S. Did I improve my palette above or make it worse?

I think your change was an improvement. The saturation level seems to be just right, at first glance anyway. If anything, I think you might want to just simply lighten it a little bit without changing any of the hue or saturation values. That's all.

You may be right about the "no-backlight friendly" idea, but I really couldn't say. Minish Cap's colors looked so appropriate that if they were compensating for any GBA problems, they really hid it well.