Thread:BBB.Myles/@comment-24577221-20150628221620/@comment-12740090-20150814145542

BunsenH wrote: I understand that you're not doing anything official here, so I appreciate your getting back to me on these things. And I appreciate the straight answers.

I can infer more than a bit about how the Glowbe tinting works from observation of how they look when given various proportions of R/Y/B. (That's a weird colour space to work in for graphic stuff, though I know that the analogy with paints is much more familiar to most of the game's players than RGB or HSV or ...)  The way the Glowbe's bodies darken to near-black as the proportions of R/Y/B become nearly-equal -- frankly, that seems wrong to me, and I've played around with translating colour spaces, for writing software for converting pictures to cross-stitch patterns. And a few years back, I had to deal with the really ugly problem of trying to get a colour menu on an LCD screen to approximately match the colours of full-colour LED buttons on a console. So I'd like to make a suggestion about how the Glowbes look, and I do know something about the subject. :-)

Don't get me wrong. This is probably only impossible in the (literal sense) insofar as the current Glowbe tinting system might not support it. Reworking the system to get it to work and generating new assets to display that information could just be too difficult/high a cost. That said it might also just take up too much memory. It probably wouldn't be too hard to get the same code that tints the Glowbes to dictate which R/Y/B scale to show our players, but we'd suddenly need to add a whole bunch of new assets to the game to report this info and a new menu to display it in. The Glowbes are actually really low memory because of the way they're implemented, this is part of what makes them tricky to rework.

-Myles