1029 posts
Location
Missouri, United States, America, Earth, Solar System, Milky Way, Universe 42B, Life Street, Multiverse, 4th Dimension
Posted 09 April 2015 - 12:15 AM
CC's colors are limited to 16, as this means CC only has to send 2 bytes per every pixel. This is CC's strong suite, because it's why it preforms so well.
However, we are unable to customize what colors these 16 colors are. My idea is having a term function that would allow you to set what each power would equate to in a color code(ex. 0x0000). This could be sent to the client, and the client would know that, for example, 2^2 is 0x0000.
So the only additional data is sent once to the client.'
Edit: Dan had a better idea on how to implement this:
One possibility, inspired by how old OSes used to handle this: Make the first 16 colours immutable, then add another 16 "user colours", that you use with the understanding that if you're not the toplevel program in a windowed OS, you'll probably be rendered wrong.
And my ideas for that:
….
I like this idea.
Perhaps a function to get what's on the custom pallet? For example,
term.getPalletColor(17) –> returns the 1st custom pallet code, ex. 0x00000
and also possibly:
term.hasPalletPriority –> true/false weather you have control over the color pallet
And then, of course:
term.setPalletColor(17,"0x0000") –> Sets 17 to 0x0000
Edited on 10 April 2015 - 09:11 PM
7083 posts
Location
Tasmania (AU)
Posted 09 April 2015 - 10:13 AM
The "2 bytes" thing would have more to do with RedPower's bundled cables than anything else - they had a bandwidth of 16 bits, corresponding with MineCraft's 16 dyes. If you've much experience with CC's "bundled" functions, along with the functions in the colour API, you'll know exactly why the colour constants are defined the way they are.
In regards to how CC actually gets colours onto your screen, I assure you, the systems are for the most part unrelated. The interface provided to us to deal with colours is heavily abstracted.
Anyway, I'm not entirely sure what you're asking for here. Can you provide some pseudo code or something to help explain it? On the surface, it sounds like you wouldn't even need a function to apply your custom mappings (whatever they are); you could just dump them directly into the colour table (or where ever you want them)..
It might be worth pointing out that, at least within Lua, a "number" datatype is a float. Full stop. If you store the number 1 it takes the same amount of RAM as the number 24352352.342; the language doesn't use a "best pick" out of ints, bytes, etc, it simply always uses floats.
1426 posts
Location
Does anyone put something serious here?
Posted 09 April 2015 - 10:21 AM
My issue with this is it kinda breaks the fourth wall. CC's terminals can only display 16 colours. This isn't a limitation with the software, it is a limitation with the hardware (of a computer in a voxel based sandbox game :)/>). I can't go up to my hypothetical black and white monitor and get it to display colour, though I could probably change the brightness. It is a nice suggestion, I just think its a imperfect solution to an awkward problem.
Edit: I know pretty much every display related post gets shot down one way or another, and sometimes I think that is a shame. However, I think it is something we are going to have to live with.
OpenComputers implements a Colour pallet style thing, though I can't find documentation on how to use it.
Edited on 09 April 2015 - 09:10 AM
7083 posts
Location
Tasmania (AU)
Posted 09 April 2015 - 10:58 AM
Ah, I get it!
I'm not suggestion more than 16 colors
Yes you are. :P/>
524 posts
Location
Cambridge, England
Posted 09 April 2015 - 01:27 PM
I may implement this some day, I like it :)/>
7083 posts
Location
Tasmania (AU)
Posted 09 April 2015 - 10:33 PM
Getting back to the colours API, how would you reconcile the requested remappable palette with that? Take colours.magenta for example - it doesn't make much sense to have it if it suddenly maps (or even could map) to eg some obscure shade of green.
Obviously you'd want to have those constants in there anyways - backwards compatibility and redstone's bundled functions all but make them a requirement - but it strikes me as a bit… messy, when present alongside a display system that really doesn't mesh with it. :huh:/>
1140 posts
Location
Kaunas, Lithuania
Posted 10 April 2015 - 07:20 AM
The place where this would fail is multi-window desktop environments. Take LyqydOS for example. If you run multiple programs which change the colors then you'd probably have to only show the colors of the currently active window. But then, what if the window changes all colors? In what colors should the top bar be draw in?
213 posts
Posted 10 April 2015 - 11:52 AM
The window API will probably be tweaked to store map changes and adjust them when switching applications
7083 posts
Location
Tasmania (AU)
Posted 10 April 2015 - 12:09 PM
That's not a fix, sorry; remember that the
window API isn't the same thing as
multishell.
See, you can have multiple windows visible at the same time. If each window has its own palette, then by using more than one window you've got access to so many colours at once that Dan may as well scrap the palette-based system entirely and let us specify RGB values on a whim. If each window relies on the parent terminal for
its palette, then running multiple colour-altering scripts via multishell turns into a complete mess.
524 posts
Location
Cambridge, England
Posted 10 April 2015 - 01:44 PM
That's a good point. And one that gives me bad memories of running windowed games in 256 colour mode on Windows 95 and having the rest of the desktop turn technicolour.
8543 posts
Posted 10 April 2015 - 03:55 PM
Yes, if this was implemented, I'd have to ignore (in LyqydOS) the palette setting functions almost entirely to prevent programs from breaking the appearance of other programs and UI elements. The one exception would be programs running a window in full screen mode, of course. This would definitely be an interesting feature to see, though!
524 posts
Location
Cambridge, England
Posted 10 April 2015 - 05:32 PM
One possibility, inspired by how old OSes used to handle this: Make the first 16 colours immutable, then add another 16 "user colours", that you use with the understanding that if you're not the toplevel program in a windowed OS, you'll probably be rendered wrong.
1029 posts
Location
Missouri, United States, America, Earth, Solar System, Milky Way, Universe 42B, Life Street, Multiverse, 4th Dimension
Posted 10 April 2015 - 11:06 PM
One possibility, inspired by how old OSes used to handle this: Make the first 16 colours immutable, then add another 16 "user colours", that you use with the understanding that if you're not the toplevel program in a windowed OS, you'll probably be rendered wrong.
I like this idea.
Perhaps a function to get what's on the custom pallet? For example,
term.getPalletColor(17) –> returns the 1st custom pallet code, ex. 0x00000
and also possibly:
term.hasPalletPriority –> true/false weather you have control over the color pallet
And then, of course:
term.setPalletColor(17,"0x0000") –> Sets 17 to 0x0000
Edited on 10 April 2015 - 09:12 PM
1610 posts
Posted 11 April 2015 - 11:19 PM
One possibility, inspired by how old OSes used to handle this: Make the first 16 colours immutable, then add another 16 "user colours", that you use with the understanding that if you're not the toplevel program in a windowed OS, you'll probably be rendered wrong.
I feel like this would work well. It would allow up to 32 unique colors without causing other major problems - any programs in the background might look funny but switching to them or minimizing them would fix it.
7083 posts
Location
Tasmania (AU)
Posted 12 April 2015 - 12:48 AM
but switching to them or minimizing them would fix it.
Not automatically, it wouldn't.
1610 posts
Posted 12 April 2015 - 05:51 AM
but switching to them or minimizing them would fix it.
Not automatically, it wouldn't.
Should have rephrased it. It allows you to use the 16 "base" colors which are always the same and, if necessary, 16 additional colors that may or may not be what the program expects. This allows operating systems and such to keep elements presentable even while other programs are changing the 16 additional colors.