I often find that the colours you can use in creative are kind of limited, especially when making pixel art. I suggest that Notch implements a hex code colouring system for creative mode, and perhaps in survival using dyes
For those of you who are unfamiliar with hex colouring, this is how it works:
there are 6 characters in th code, the first two represent red, the next two represent green and the last two represent blue (RRGGBB). For each colour slot there are two numbers or letters ranging from 0 to F (F being the highest value), the letters A-F act as extra numbers which are higher than nine, so in two characters there are 256 combinations rather than 99. Using different amounts of red blue and green, you can crate virtually any colour.
Instead of having so many different types of coloured blocks, there can be one universal coloured block which holds a piece of code to decide it's colour; the player can use an interface to decide the colour for the blocks before placing them (you would place the same colour block untill you change it, you wouldn't need to constantly reset the colour after placing each block).
I am not entirely sure how practical it would be to implement this, 6 digit codes for potentially hundreds of thousands of blocks could be quite memory consuming, but it would be a lot better than having only a handfull of colours.
Edit: the word "colour" appears 14 times in this post lol
I don't think we actually need all 16777216 colors. It would just complicate it for pixel artists.
Instead of going for 24-bit colors, why not go for 16-bit colors, or perhaps even 8-bit colors?
For two bytes, you have 16 bits at your disposal, instead of the 24 you would have used. So, how could we divide them into three? Simple. Throw away one bit, and you have 15 bits, meaning 5 bits per color.
With 8 bits per color, you would have had 256 gradients for each color. With 5 bits, however, you would have 32. In total, you could create 32768 colors, more than enough colors people would ever use. In fact, if we just use 8 bits for the three colors, we could end up with, for example, two bits per color, meaning four gradients per color and a total of 64 colors. We'd throw away two bits if we'd go for an 8-bit solution, sure, but the point is, why use a lot of colors when the basic pixel artist would only ever need about 16 colors at a time anyway, perhaps a max of 256?
Alternatively, dye mixing. I might come up with a mock-up for it.
I don't think we actually need all 16777216 colors. It would just complicate it for pixel artists.
Instead of going for 24-bit colors, why not go for 16-bit colors, or perhaps even 8-bit colors?
For two bytes, you have 16 bits at your disposal, instead of the 24 you would have used. So, how could we divide them into three? Simple. Throw away one bit, and you have 15 bits, meaning 5 bits per color.
With 8 bits per color, you would have had 256 gradients for each color. With 5 bits, however, you would have 32. In total, you could create 32768 colors, more than enough colors people would ever use. In fact, if we just use 8 bits for the three colors, we could end up with, for example, two bits per color, meaning four gradients per color and a total of 64 colors. We'd throw away two bits if we'd go for an 8-bit solution, sure, but the point is, why use a lot of colors when the basic pixel artist would only ever need about 16 colors at a time anyway, perhaps a max of 256?
Alternatively, dye mixing. I might come up with a mock-up for it.
ya I guess a simpler code would be more practical; most pixel art is based off of 8 and 16 bit games anyways.
it'd be better working off indexed colours for regional block customisation.
Hex colour tinting would be more processor intensive and prevents you recolouring different parts of the texture.
For example take the grass. You have the original palette which contains the browns of soil and the greens of grass.
You could make another one which has lighter redder soil and dried yellowy green grass for deserts.
the same palette also contains information to recolour cobble mined in that biome, ores, sand and gravel.
So each biome would have a palette which could recolour the base blocks.
For those of you who are unfamiliar with hex colouring, this is how it works:
there are 6 characters in th code, the first two represent red, the next two represent green and the last two represent blue (RRGGBB). For each colour slot there are two numbers or letters ranging from 0 to F (F being the highest value), the letters A-F act as extra numbers which are higher than nine, so in two characters there are 256 combinations rather than 99. Using different amounts of red blue and green, you can crate virtually any colour.
|red = ff0000|orange = ff9900|yellow = ffff00|green = 00ff00|blue = 0000ff|purple = ff00ff|
Instead of having so many different types of coloured blocks, there can be one universal coloured block which holds a piece of code to decide it's colour; the player can use an interface to decide the colour for the blocks before placing them (you would place the same colour block untill you change it, you wouldn't need to constantly reset the colour after placing each block).
I am not entirely sure how practical it would be to implement this, 6 digit codes for potentially hundreds of thousands of blocks could be quite memory consuming, but it would be a lot better than having only a handfull of colours.
Edit: the word "colour" appears 14 times in this post lol
here's a visual representation for those who prefer seeing things to reading about them
The writing is a bit sloppy, but I'm sure you get the idea.
Instead of going for 24-bit colors, why not go for 16-bit colors, or perhaps even 8-bit colors?
For two bytes, you have 16 bits at your disposal, instead of the 24 you would have used. So, how could we divide them into three? Simple. Throw away one bit, and you have 15 bits, meaning 5 bits per color.
With 8 bits per color, you would have had 256 gradients for each color. With 5 bits, however, you would have 32. In total, you could create 32768 colors, more than enough colors people would ever use. In fact, if we just use 8 bits for the three colors, we could end up with, for example, two bits per color, meaning four gradients per color and a total of 64 colors. We'd throw away two bits if we'd go for an 8-bit solution, sure, but the point is, why use a lot of colors when the basic pixel artist would only ever need about 16 colors at a time anyway, perhaps a max of 256?
Alternatively, dye mixing. I might come up with a mock-up for it.
THREAD
http://www.minecraftforum.net/viewtopic.php?f=1&t=22468
this is a suggestion for creative mode!
ya I guess a simpler code would be more practical; most pixel art is based off of 8 and 16 bit games anyways.
Hex colour tinting would be more processor intensive and prevents you recolouring different parts of the texture.
For example take the grass. You have the original palette which contains the browns of soil and the greens of grass.
You could make another one which has lighter redder soil and dried yellowy green grass for deserts.
the same palette also contains information to recolour cobble mined in that biome, ores, sand and gravel.
So each biome would have a palette which could recolour the base blocks.