Rejected Change Coloured Hull System

[Blaza612]

At the moment, hulls/armour are taking up a massive amount of the limited block IDs that we have, and people are still demanding more colours. The solution is rather simple: have the colour stored within the hull/armour itself rather than having an entirely different set of IDs taken up for each colour.

Here's how it would work:

- Get your block, pick the colour via some method (possibly with a colour wheel?)

- The block then changes it's colour to the one selected, using the standard colour code system that is used everywhere for digital colouring.

- You place the block with it's fancy colour that you picked. :D

- This would free up the majority of IDs, allowing for more of any block, for both mods and future updates!

- This would also allow for more creativity from the players on their ship designs, creating more diversity among ships.

- YOU CAN MAKE THE PINK SWAG SHIP! :D
​

All in all, this system would provide a multitude of great bonuses to the game, from technical improvements to aesthetic improvements. Enjoy the advanced colouring! \o/

 

[Titansmasher]

This has already been requested multiple times, and has been rejected each time due to the amount of data that would need to be stored.
IIRC there is currently 3 bytes of data per block, relating to its position, ID, health etc. There isnt room within the current data structure to add this, and to add selectable colours would mean the bytes per block would have to increase, in turn causing a drop in performance.
For example, a full 255,255,255 R,G,B colour slider would require a byte per colour, doubling the space needed per entity effectively.

 

[Megacrafter127]

As Titansmasher said, if something needs to be stored on a per-block basis, and isn't dependant on something already stored on a per-block basis, it needs to be stored within those 3 bytes, all bits of which are already used. By having the color be determined by the blockID space is actually saved.
Hence I will apply the 'Rejected' tag, until Schine states otherwise.

 

[Blaza612]

This has already been requested multiple times, and has been rejected each time due to the amount of data that would need to be stored.
IIRC there is currently 3 bytes of data per block, relating to its position, ID, health etc. There isnt room within the current data structure to add this, and to add selectable colours would mean the bytes per block would have to increase, in turn causing a drop in performance.
For example, a full 255,255,255 R,G,B colour slider would require a byte per colour, doubling the space needed per entity effectively.

As Titansmasher said, if something needs to be stored on a per-block basis, and isn't dependant on something already stored on a per-block basis, it needs to be stored within those 3 bytes, all bits of which are already used. By having the color be determined by the blockID space is actually saved.
Hence I will apply the 'Rejected' tag, until Schine states otherwise.

If having three variables to figure out the colour doesn't work, what about a hex value? from 0 to f, which is what I was originally thinking for colour code system, just didn't know the name. :P

I read up a bit on the More Block Colours in regard to my idea on a colour wheel and I came upon the knowledge of a hex value. According to the ones discussing the hex value idea, one byte is eight bits, and the hex values (ranging from 0 to f, or 0000,0000 to 1111,1111) takes a single byte, and from previous threads, there have been requests for a block to store 4 bytes rather than 3 bytes, the colour could make up that fourth single byte, allowing for the storage to be aligned, making Starmade run significantly faster as well as having the fancy colour system for the swagship.

Now to learn how I'm wrong! :D

 

[Titansmasher]

Hex (base 16) is simply a shortened way of representing binary numbers. It is another number system that you can convert values to and from, the same as with denary (base 10) and binary (base 2). While the hex values do seem shorter than binary values (e.g. #ff6613) that is infact just a more human readable form of something that is interpreted by the computer in binary. To be long and boring, the hex value I just gave is the same as 1111 1111 0110 0110 0001 0011, 24 bits of data and thus 3 bytes to store the colour code. This is also the same as 255,104,19 on a denary system.

In short the number system you use to represent the data to humans does not matter, because at the end of the day it is all stored in binary[/COLOR]

 

[Blaza612]

Hex (base 16) is simply a shortened way of representing binary numbers. It is another number system that you can convert values to and from, the same as with denary (base 10) and binary (base 2). While the hex values do seem shorter than binary values (e.g. [COLOUR=#ff6613]#ff6613[\COLOUR]) that is infact just a more human readable form of something that is interpreted by the computer in binary. To be long and boring, the hex value I just gave is the same as 1111 1111 0110 0110 0001 0011, 24 bits of data and thus 3 bytes to store the colour code. This is also the same as 255,104,19 on a denary system.

In short the number system you use to represent the data to humans does not matter, because at the end of the day it is all stored in binary

I am aware as to how everything is simply a humanly understandable form of binary, however I was misinformed on how beg the hex values go to. But the same principle can be used, just with a bit more limited colours. That extra byte will allow for alignment, as even numbers are significantly easier to access. There will still be a large amount of colours to choose from, even if it ain't all of them. :P

 

[Titansmasher]

True, you could use 6 bits for colours, but then that would mean you could only have 64 possible colours, and half of them would be ugly shades xD to have a properly effective colour system, you really need 4 bits per colour, 12 in total (16^3 different colours) but that then means you have to add 2 bytes due to memory allocation, and that is nearly as bad as adding 3 bytes

Having said that, I have just thought of another possible solution. Have 1 byte reserved for a 'colour index' which references a colour on a separate database. This would mean you could have up to 256 different colours saved per world (or even per entity but that might get a bit too much). This would add extra data into the entity headers, but the size of each block would only increase by 1 byte.

Just a thought anyway

 

[Blaza612]

True, you could use 6 bits for colours, but then that would mean you could only have 27 possible colours, and half of them would be ugly shades xD to have a properly effective colour system, you really need 4 bits per colour, 12 in total (16^3 different colours) but that then means you have to add 2 bytes due to memory allocation, and that is nearly as bad as adding 3 bytes

Having said that, I have just thought of another possible solution. Have 1 byte reserved for a 'colour index' which references a colour on a separate database. This would mean you could have up to 256 different colours saved per world (or even per entity but that might get a bit too much). This would add extra data into the entity headers, but the size of each block would only increase by 1 byte.

Just a thought anyway

That is another possibility, one that seems better than the one I've proposed. 256 colours AND alignment is better than just 27 colours and alignment. :P

 

[Titansmasher]

My bad, with a 6 bit system there are 64 colours available. For some reason I did 3^3 rather than 4^3 hehe

 

[alterintel]

having a byte size index of 256 colors would take up just as much space as the actual 256 colors would. The number of possible colors would be limited to the number of unique indexes you could get in a single byte of data IE 256. I know I'm probably not making any sense here. But in all actuality a color code is pretty much already an index.

The only way that an index would help is if you were using 6 bit 64 colors and you wanted to replace the ugly shades with prettier colors.

IMHO if it was possible to spare 6 bits in the block coding, 6 bit 64 colors would be the way to go. But from what I'm gathering, it seems as if there is no extra space for 6 bits of data as it is. Also, if that block isn't a block that would support different colors (like a logic block or something), then you could use those bits for something else.

What if:
Colored blocks already don't support link blocks such as "C" and "V". you can't link an armored block to anything. So if the block is armor, then use the linking data space to store color information instead.... Just an idea.

 

[Titansmasher]

having a byte size index of 256 colors would take up just as much space as the actual 256 colors would. The number of possible colors would be limited to the number of unique indexes you could get in a single byte of data IE 256. I know I'm probably not making any sense here. But in all actuality a color code is pretty much already an index.

The only way that an index would help is if you were using 6 bit 64 colors and you wanted to replace the ugly shades with prettier colors.

IMHO if it was possible to spare 6 bits in the block coding, 6 bit 64 colors would be the way to go. But from what I'm gathering, it seems as if there is no extra space for 6 bits of data as it is. Also, if that block isn't a block that would support different colors (like a logic block or something), then you could use those bits for something else.

What if:
Colored blocks already don't support link blocks such as "C" and "V". you can't link an armored block to anything. So if the block is armor, then use the linking data space to store color information instead.... Just an idea.

Yes, I know it would take up the same amount of space as a 256 scale of RGB colours, however for RGB you need equal bits for each colour, meaning it has to be a multiple of 3 bits. This would be either 9 bits (512 colours) or 6 bits (64 colours). And due to how data is stored, it would really need to be stored in a whole number of bytes, so you could add 2 bytes and have 7 bits that mean nothing, or 1 byte and have 2 bits that mean nothing. Using RGB in 1 byte basically doesnt work. Its less efficent in every way than using a colour index system

Using an index you could have 3 bytes to define the colour, giving you a full true colour spectrum, effectively giving you the same level of detail as a 3 byte RGB system, but the number of bits needed is reduced thanks to the reduced flexability of the system (16777216 available colours reduced to picking 256 of them)

And yes, the current data structure is packed, there is no more room for additional data. So this is all based on the block system being updated to accomodate 4 bytes per block.

And yeah, using linking of designated colour blocks to hull and such could allow for the same effect. I hadnt thought of that

 

[Blaza612]

having a byte size index of 256 colors would take up just as much space as the actual 256 colors would. The number of possible colors would be limited to the number of unique indexes you could get in a single byte of data IE 256. I know I'm probably not making any sense here. But in all actuality a color code is pretty much already an index.

The only way that an index would help is if you were using 6 bit 64 colors and you wanted to replace the ugly shades with prettier colors.

IMHO if it was possible to spare 6 bits in the block coding, 6 bit 64 colors would be the way to go. But from what I'm gathering, it seems as if there is no extra space for 6 bits of data as it is. Also, if that block isn't a block that would support different colors (like a logic block or something), then you could use those bits for something else.

What if:
Colored blocks already don't support link blocks such as "C" and "V". you can't link an armored block to anything. So if the block is armor, then use the linking data space to store color information instead.... Just an idea.

The game would run faster if we just added the fourth byte rather than replacing one, again, the alignment would mean a significant increase in calling the data. :P

 

[Titansmasher]

The game would run faster if we just added the fourth byte

Not really.. adding a fourth byte would slow down the game significantly, loading of entities could be as much a 33% slower by adding a 4th byte.

rather than replacing one, again

But we cant really replace a byte anywhere, as the current data structure is full :P

 

[Blaza612]

Not really.. adding a fourth byte would slow down the game significantly, loading of entities could be as much a 33% slower by adding a 4th byte.



But we cant really replace a byte anywhere, as the current data structure is full :p

Again, alignment. That is how it would speed up, even size numbers (for example, 4) are much easier to find and load up than odd size numbers, the blocks may take up more space, but they compensate by being able to be loaded easier.

 

[Megacrafter127]

Again, alignment. That is how it would speed up, even size numbers (for example, 4) are much easier to find and load up than odd size numbers, the blocks may take up more space, but they compensate by being able to be loaded easier.

Except that the game likely decompresses and loads a bulk of 12288 bytes at once [4096 blocks]