Author Topic: What's the purpose of ColorIDs?  (Read 567 times)

Why do we have them? Is it a client rendering issue? Is it a network load issue? Why do we use ColorIDs instead of straight-out RGBA values?

I came across a function that 'changes' a ColorID. However, all the bricks which already had that color stay the same, so I would assume they're 'remembering' their actual RGBA value, instead of the CID value - so why use them?


I'm not saying I disagree with the concept of a colorset itself, but if the color could be changed arbitrarily, then it could be client-sided instead of server-sided - eliminating the competition between colorsets, because a client could just use the one s/he likes best.

So why do we have ColorIDs?

If you're talking about Hex color codes on "center print" and other messages, they are easier to type and remember.

Because it only requires 6 bits to represent a color id across the network and a lot more to represent an RGBA color.

Because it only requires 6 bits to represent a color id across the network and a lot more to represent an RGBA color.

One would imagine an RGBA color scheme would only be an increase of 24 bits per color - I very much doubt the extra 2 bits in that byte are used for anything else.

One would imagine an RGBA color scheme would only be an increase of 24 bits per color - I very much doubt the extra 2 bits in that byte are used for anything else.

"only"

Yes, it would only increase the number of bits by a factor of five.

Yes, it would only increase the number of bits by a factor of five.

A factor of four (again, remember, those two extra bits are virtually definitely unused), and that's beside the point. A single chat message in Blockland, assuming chat uses ASCII, would be anywhere from one byte to (maximum string length)+1 bytes. Either way, it would average out to be vastly longer than an RGBA color value.

Sure, it would technically be a larger strain on a server's bandwidth - in the same way that three ounces is a larger strain on your hand than two ounces. But have you ever seen someone keel over dead from an extra ounce of weight?

You're talking about using 32 bits to represent the color of potentially up to 256,000 bricks instead of 6 bits. That's a difference of around 817 kB. That's crazy.

A factor of four (again, remember, those two extra bits are virtually definitely unused), and that's beside the point. A single chat message in Blockland, assuming chat uses ASCII, would be anywhere from one byte to (maximum string length)+1 bytes. Either way, it would average out to be vastly longer than an RGBA color value.

Sure, it would technically be a larger strain on a server's bandwidth - in the same way that three ounces is a larger strain on your hand than two ounces. But have you ever seen someone keel over dead from an extra ounce of weight?

It's 6 bits versus the 32 bits needed for RGBA. That's over a factor of 5. You're assuming the extra 2 bits in each byte are unavailable which may or may not be true for the TGE.

In any case, a 4x increase could be significant. Your chat example has little relevance; on a bad day you might get a couple lines of text per second. When you are loading bricks you are typically working with thousands of them and you want to get them in the shortest time possible. That is where a few extra bits starts to hurt you. Not all players have the luxury of a broadband connection.

That pretty much answers your initial question "why have colorID's?". It's a tradeoff; the reduced color selection allows for more people to access the game.

Both good points; fair enough. I concede.