I don't know how feasible this would be to implement but instead of having a set number of colored cloth blocks, how about a stripped down version of this:
The MS Paint custom color palette.
You could have one generic "cloth block" and have millions of possible colors it could be. Perhaps when selecting cloth, a separate block strip would open, and you could have a strip of nine or so of your custom colored blocks stored on it.
Would it make the maps that much larger? Granted, I'm not too knowledgeable about things like this, but wouldn't it only have to store the colors actually used? Not all possible colors. Does color information really take up that much space?
Not sure where you got that number from but it depends on the serialization algorithm. It could easily be setup to only store an extra single byte (8 bit color palette) for only cloth blocks. This would make the extra size variable from 0 byte to whatever size your level is if completely full of cloth blocks.
[Edit] Not saying that this is a viable idea, just saying it won't be as bad as people think.
Rollback Post to RevisionRollBack
MineCraft Server Operator v0.3b
Votekick/voteban, remote access, automated backups, cross-platform and more.
Control your server.
It won't take up nearly that many (if I understand the idea correctly) he wants to be able to change the palette of the cloth blocks for the entire level - not have a custom colour on each block.
In which case 16 cloth blocks x 8 bit colour = 16 bytes extra - not exactly a killer is it?
If it did add an extra byte for each block then it would make it much bigger... (the number Quatroking quoted for a 256 cubed level)
The only problem is who gets to choose the colours...
It won't take up nearly that many (if I understand the idea correctly) he wants to be able to change the palette of the cloth blocks for the entire level - not have a custom colour on each block.
In which case 16 cloth blocks x 8 bit colour = 16 bytes extra - not exactly a killer is it?
If it did add an extra byte for each block then it would make it much bigger... (the number Quatroking quoted for a 256 cubed level)
The only problem is who gets to choose the colours...
No, he wants a color picker so you can have custom colored cloth blocks.
Which would be AWESOME for sprite creation :biggrin.gif:
It won't take up nearly that many (if I understand the idea correctly) he wants to be able to change the palette of the cloth blocks for the entire level - not have a custom colour on each block.
In which case 16 cloth blocks x 8 bit colour = 16 bytes extra - not exactly a killer is it?
If it did add an extra byte for each block then it would make it much bigger... (the number Quatroking quoted for a 256 cubed level)
The only problem is who gets to choose the colours...
No, he wants a color picker so you can have custom colored cloth blocks.
Which would be AWESOME for sprite creation :biggrin.gif:
So It would have to save the specific colour for EVERY cloth block in the map.
Better idea: Add a new type of cloth block selectable from the B menu, which is shown as a rainbow block. When put on the build bar, it pops up the color selector.
While I may not do Java coding, I do code outside of it, and I'm pretty sure that storing a 6-character hexadecimal code for each Rainbow Cloth on the map wouldn't be that big of a change.
I'm not sure how much space a block ID takes (I'm guessing 1 byte since we don't have more than 256 blocks right now), so a normal map with normal blocks can take up to 4,194,304 bytes which is ~4MB
A map filled with color picker blocks would take 4x as much (3 extra bytes for RGB), therefore: 16,777,216 bytes which is ~17MB
This is the worst situation possible, it's also interesting that the amount of blocks a normal map can store is also the same amount of colors in the palette, so it would be possible to fill a map with every possible color using RGB.
Of course compression can save a lot of trouble in terms of map size, Minecraft doesn't seem to like maps bigger than 512x512x128 and those can use up to 33,554,432 bytes = ~34MB so having a map using 17MB wouldn't be a problem, I just doubt that huge maps with colored cloth would work anymore (since their size would be brought up to 100,663,296 bytes which is ~101MB)
Not sure where you got that number from but it depends on the serialization algorithm. It could easily be setup to only store an extra single byte (8 bit color palette) for only cloth blocks. This would make the extra size variable from 0 byte to whatever size your level is if completely full of cloth blocks.
[Edit] Not saying that this is a viable idea, just saying it won't be as bad as people think.
I could be wrong, but what I did was 256^3 which should cover up all colors. (Not 255, because the 0 also has value)
I still think it would work with a "rainbow" block and ONLY the rainbow blocks would have the color data stored in them. The normal cloth blocks would be just how they are now.
I'm pretty big on file junk. It wouldn't be too hard, but notch'd need to pull some tricks. You'd increase the file size by an average of a quarter of a kilobyte for a colorable block pallet, and give the ability to use 24bit turecolor blocks, up to around 240 variations of them. (total depends on # of normal blocks: 256 - # of blocks) This format would also severly decrease total size thanks to an easy-to-implement compresssion algoritm for arrays of info with lots of repetition. Each player gets ~10 colors to call their own. depends on max. players in server.
DISCLAIMER: People who are ignorant to the less basic workings of files and compression (which a suprisingly sizable number of you all seem to be :/) and comment about how this doesn't work for some nonsensical reason, your comment will be completely ignored.
file format would be like this -
File header (3-4 bytes)
# of block color pallets used on map (240 or so maximum) - 1 byte
For every pallet - (3 bytes each)
1 byte red
1 byte green
1 byte blue
[POSSIBLY] 1 byte Alpha transparency - would be neat
one 2 byte short integer per map dimension - 6 bytes total (sets maximum map size at 65536*65536*65536)
For every relevant tile -
1 byte for # of consecutive tiles following this one of same type (max would have to be 256)
1 byte for what type of tile it is
Illustration, each number in brackets being the content of a byte:
goes from e.g [1][1][1][1][1][1] [2][2][2] [3]
to [6][1] [3][2] [1][3]
(End of File)
And presto, not only do we have colorable blocks with 240 24 or maybe 32 bit colors, but file size would become appx. 1/200th of what it is now using a very simple compression algo.
The MS Paint custom color palette.
You could have one generic "cloth block" and have millions of possible colors it could be. Perhaps when selecting cloth, a separate block strip would open, and you could have a strip of nine or so of your custom colored blocks stored on it.
P.S.: Lol @ paint :biggrin.gif:
What's it at now?
[Edit] Not saying that this is a viable idea, just saying it won't be as bad as people think.
Votekick/voteban, remote access, automated backups, cross-platform and more.
Control your server.
In which case 16 cloth blocks x 8 bit colour = 16 bytes extra - not exactly a killer is it?
If it did add an extra byte for each block then it would make it much bigger... (the number Quatroking quoted for a 256 cubed level)
The only problem is who gets to choose the colours...
No, he wants a color picker so you can have custom colored cloth blocks.
Which would be AWESOME for sprite creation :biggrin.gif:
So It would have to save the specific colour for EVERY cloth block in the map.
While I may not do Java coding, I do code outside of it, and I'm pretty sure that storing a 6-character hexadecimal code for each Rainbow Cloth on the map wouldn't be that big of a change.
A map filled with color picker blocks would take 4x as much (3 extra bytes for RGB), therefore: 16,777,216 bytes which is ~17MB
This is the worst situation possible, it's also interesting that the amount of blocks a normal map can store is also the same amount of colors in the palette, so it would be possible to fill a map with every possible color using RGB.
Of course compression can save a lot of trouble in terms of map size, Minecraft doesn't seem to like maps bigger than 512x512x128 and those can use up to 33,554,432 bytes = ~34MB so having a map using 17MB wouldn't be a problem, I just doubt that huge maps with colored cloth would work anymore (since their size would be brought up to 100,663,296 bytes which is ~101MB)
http://en.wikipedia.org/wiki/8-bit_color
Votekick/voteban, remote access, automated backups, cross-platform and more.
Control your server.
That's true, we probably don't need that many.
Either way, Minecraft could handle it.
I could be wrong, but what I did was 256^3 which should cover up all colors. (Not 255, because the 0 also has value)
(zomg paradox)
DISCLAIMER: People who are ignorant to the less basic workings of files and compression (which a suprisingly sizable number of you all seem to be :/) and comment about how this doesn't work for some nonsensical reason, your comment will be completely ignored.
file format would be like this -
File header (3-4 bytes)
# of block color pallets used on map (240 or so maximum) - 1 byte
For every pallet - (3 bytes each)
1 byte red
1 byte green
1 byte blue
[POSSIBLY] 1 byte Alpha transparency - would be neat
one 2 byte short integer per map dimension - 6 bytes total (sets maximum map size at 65536*65536*65536)
For every relevant tile -
1 byte for # of consecutive tiles following this one of same type (max would have to be 256)
1 byte for what type of tile it is
Illustration, each number in brackets being the content of a byte:
goes from e.g [1][1][1][1][1][1] [2][2][2] [3]
to [6][1] [3][2] [1][3]
(End of File)
And presto, not only do we have colorable blocks with 240 24 or maybe 32 bit colors, but file size would become appx. 1/200th of what it is now using a very simple compression algo.
(Yay for file compression!)