Hull colors: Would this work?

[WaffulMann]

So, what if the game had only 4 hull blocks and 4 hardened hull blocks.
If you place one down and paint it, it then has a meta ID of two numbers, like, 30 49
The game then selects a color from the coordinates of this picture:

Then overlays it on top of the block.
How would this work?

 

[Titansmasher]

Only problem with this system is that schema wants to keep the bytes per block down to 3 bytes to reduce lag. Adding this in would increase the number of bytes needed per hull block quite dramatically for the coordinates, or so I would have thought.

 

[NeonSturm]

If you place one down and paint it, it then has a meta ID of two numbers, like, 30 49

0..31 takes 5 bits, 0..64 takes 6 bits. You are basically saying that it uses at least 11 bit (that's 1.3 bytes out of 3)

So, what if the game had only 4 hull blocks and 4 hardened hull blocks.

For small ships, that would be neat once they are colour-able. But for big ships RP may suffer.

---

I've learned from past topics about hull colours that there is only 1 option which might be viable, memory wise.

1. Give each ship (or each 16^3 blocks) meta-data that contains 8 custom textures.

But http://www.raywenderlich.com/10862/...stom-shaders-in-opengl-es-2-0-and-cocos2d-2-x says:

A graphic card can execute 1 command for all pixels at once.

But maybe only with 1 texture file at a time (why else do we not have everything in one file or as single files per block?).

if 4 texture files => 4 times the same routine for jet (by previous steps) still uncoloured blocks?

This might add a 5th repeat, although if 1 file generated in memory might contain colour variations from 32 ships (as long it's only hull)

If used a variation per chunk (and it is working like this), that might blow the GPU memory.​

I keep reading http://www.raywenderlich.com/10862/...stom-shaders-in-opengl-es-2-0-and-cocos2d-2-x

(described for iOS and Cocos, but the fsh and vsh file part (fragment and vertex shaders) works the same for Java.​

 

[Reilly Reese]

Honestly I think it would cause issues simply because now all these colors are around. I would never be able to choose a color because when I think I want this one I find a new color :p

 

[Asmael]

About colors... I had a small idea about this.

Since we don't need all colors, the color bits would be simply multipliers of the above color panel, linked by Waffulmann.

We have up to 256^3 colors. Storing coordinates takes less space than storing 3 colors, thus gaining some extra space.

Instead of having a variable for storing the coordinates X and Y between 0 and 255, we store a multiplier. If we have the coordinates X=5 and Y=8 for instance, those would be coordinates multiplier. The range of X and Y multiplied by a constant can't go higher than 255 (or 256 depending on whether you start from 0 or 1).

256 / 32 = 8, which means we have 8 * 8, or 64 possible coordinates (thus colors). Here, our base multiplier is 32.

So If I have X = 5 and Y = 8, the corresponding coordinates would be [160;256] on the panel. Said panel would have to be reworked to eliminate duplicates tho (as in this case, all colors from [0;0] to [0;256] and from [256;0] to [256;256] are the same.

A multiplier of 32 means we'd need to store 6 bits (from 0 to 7, twice).

Now, that would require a big rework of blocks coloring but... Who knows :3

 

[gamesaucer]

I'm not sure what that'd do besides making things complicated. The same amount of information would still need to be stored but now it's at the cost of computing power instead of memory. At least, if I understood you correctly.