256 Colors in a Colorset

[TristanLuigi]

Right now, colorsets can only hold 64 colors, or 2⁶. This makes no sense to me. A full byte contains 8 bits, so unless those other two bits are used to store a brick's rotation, we're letting two valuable bits of information in every brick go to waste. A full byte can store a value of 2⁸ or 0-255 (or -128 to 127, but colors shouldn't need negatives), meaning that we could have 256 colors per byte if we include 0. So why not? Obviously, no reasonable colorsets would include 256 colors, but I've faced this problem designing a colorset myself. You just need that one extra column, but you have no space for it.

I could be completely wrong about how this works, but as far as I know there's no number type in C++ that has a value of 0-63, so I assume Blockland uses bytes for this.

[Ad Bot]

[Pah1023]

If I am correct, the reason we don't have more colors is because every single color requires 5 datablocks each (Probably more), and that adds up.

Each color requires a paint can image, projectile,
emitter, explosion, and particle.
So, a full colorset requires 320 datablocks.
But I do agree that the colorset limit should be higher, to atleast 128.

[TristanLuigi]

If I am correct, the reason we don't have more colors is because every single color requires 5 datablocks each (Probably more), and that adds up.

Each color requires a paint can image, projectile,
emitter, explosion, and particle.
So, a full colorset requires 320 datablocks.
But I do agree that the colorset limit should be higher, to atleast 128.

Paint can image I get.
Particle, emitter, and explosion can all be rainbow for every color.
Projectile might have to be different.
2*256 still adds up to 512, but no colorset would have 256 colors, it's just a suitable maximum. It would help current colorsets, too - from 320 to 125.

[Pah1023]

Paint can image I get.
Particle, emitter, and explosion can all be rainbow for every color.
Projectile might have to be different.
2*256 still adds up to 512, but no colorset would have 256 colors, it's just a suitable maximum. It would help current colorsets, too - from 320 to 125.

It would be kinda silly seeing everyone spraying rainbow paint, but still, all the data sent to the client is the color information, because the client should have all the images/models.
I believe the limit for datablocks should be modified to allow a higher count for paint, because I find myself sometimes missing colors in my builds and wish I had more colors.

It would be cool if we could just have limitless colors, but that would probabily never be made.

[TristanLuigi]

It would be kinda silly seeing everyone spraying rainbow paint, but still, all the data sent to the client is the color information, because the client should have all the images/models.
I believe the limit for datablocks should be modified to allow a higher count for paint, because I find myself sometimes missing colors in my builds and wish I had more colors.

It would be cool if we could just have limitless colors, but that would probabily never be made.

Bricks would have 4 bytes of color information and colorsets would just be a set of presets.
Save files would be larger, but more colors :P

I would much prefer more colors and silly rainbows over less colors and better-looking sprays.

[Swollow]

Bricks would have 4 bytes of color information and colorsets would just be a set of presets.
Save files would be larger, but more colors :P

I would much prefer more colors and silly rainbows over less colors and better-looking sprays.

it's not a concern of size in bytes it's datablocks

[TristanLuigi]

it's not a concern of size in bytes it's datablocks

I know, I don't think you got what I was saying
If we used infinite (well, kinda) colors and found a way around datablocks, then it would be bytes.

[Zeblote]

A colorset with 256 colors would require 1792 datablocks.

[Deve111²]

A colorset with 256 colors would require 1792 datablocks.

not enuf!!

[TristanLuigi]

A colorset with 256 colors would require 1792 datablocks.

Paint can image I get.
Particle, emitter, and explosion can all be rainbow for every color.
Projectile might have to be different.
2*256 still adds up to 512, but no colorset would have 256 colors, it's just a suitable maximum. It would help current colorsets, too - from 320 to 125.

[chubaka452]

okay really..., I'm suitable with 120 max I don't think we need 256 colors. Also my internet sucks so It would take me forever to join a server

/support

[Lugnut]

i'm like really confused

why can't the client dynamically generate all the assorted colors


like, it's not like the people who make colorsets make individual models of every possible color, and badspot sure as forget didn't make models of every possible color on the planet, so it is dynamic.

i don't buy the datablocks tied to colors limitation, someone else verify it.

[Kalphiter^4]

Right now, colorsets can only hold 64 colors, or 2⁶. This makes no sense to me. A full byte contains 8 bits, so unless those other two bits are used to store a brick's rotation, we're letting two valuable bits of information in every brick go to waste.

You can use 6 bits for anything as long as you're expecting to only read 6 bits. No waste there.

i'm like really confused

why can't the client dynamically generate all the assorted colors


like, it's not like the people who make colorsets make individual models of every possible color, and badspot sure as forget didn't make models of every possible color on the planet, so it is dynamic.

i don't buy the datablocks tied to colors limitation, someone else verify it.

You need to tie every brick ghosted with a color ID, but I'm not sure what the bottleneck is.

[Zeblote]

i'm like really confused

why can't the client dynamically generate all the assorted colors


like, it's not like the people who make colorsets make individual models of every possible color, and badspot sure as forget didn't make models of every possible color on the planet, so it is dynamic.

i don't buy the datablocks tied to colors limitation, someone else verify it.

Because someone thought that sending a 1 byte id is better than sending a 4 byte color
However, even with 256000 bricks the difference would only be like 200kB...

[Port]

However, even with 256000 bricks the difference would only be like 200kB...

>"only 200KB"
this might not seem like a lot but especially on slower connections this will make it take seemingly forever to ghost

i don't buy the datablocks tied to colors limitation, someone else verify it.

color[index] and colorShiftColor are per-datablock, not per-image/projectile.