Closed bacwyls closed 2 years ago
I cannot believe I was able to piece this together... the whole system is stored using little endian bit-ordering. when the runtime vm comes across a color, it should know it is a constant, and not reverse its order. WHAT WOULD BE NICE, would be if the runtime uses the c standard library function htons() (stands for hex to network-ordering short, where a short is more often than not 2 bytes, or 8 hex characters. network ordering is the same as big endian, and all network data is always big endian.
The hot fix solution is to say this: color = color.toString().split().reverse().replaceAll(',', '')
Why not just .padStart()
?
didnt know about that. in retrospect, this patch is more relevant to the core landscape code, right? I'm assuming the tile coloring logic is taken from there.
nice
Closing because the actual example app's tiles look correct and there's currently a merge conflict -
Re-open a PR if I'm missing something ...
arvo @ux does not support leading 0s
so leading zeros should be prepended when interpreting @ux as a hex color.
Tested using the tiles in the default create-landscape-app & the above color codes in desk.docket-0. They get correct color with this change, and an incorrect (grey / white) color without.