Color codes

Code:


You can use these as numbers. So, for example:

Code:

works fine. It also means that BLUE*2=WHITE, which is a bit strange.

Please feel free to add additional facts for the 84+CSE below, an Admin will tack them up in to this post.

Doing operations with the colors uses the color values.

LTGRAY*2 = the answer to life the universe and everything

Are those 2-bytes tokens? If they're 1 byte large, they could possibly be used for some minor optimizations

They are two bytes, $EF41-$EF4F.

This morning, I found evidence that the Text( command DOES support background colors. Though it only seems to be from 3 colors that I found, 19, 20 and 21. It'd be great if Kerm could follow up with TI on the why this is only set up for 3 colors, and not all of them.

It'd be nice to have TextColor(<text>,<background> as a set up.

Can you give more details on how to do it?

Can you do 2LTGRAY to get 42? I think that that may be faster than saying 42 because LTGRAY is already equated to 2A in hex? maybe??

Just set TextColor( to those values and display Text( with whatever you want. It changes the background color, but the text color itself is wonky.

Forty-Two: yes, it seems you can use them as numerical constants.

TIFreak8x: Those background seem to be fixed. We still don't know of a way to control them.

Maybe so, but I'd love to hear from TI on why they did it that way. Out of 14 colors, 3 of them have backgrounds with colors way off text wise than what you were trying to shoot for. Plus I'd love them to implement my idea on how to set the background color for the text :p

The other colors of text have white rather than transparent backgrounds. I think they just tried to pick contrasting colors so that text of any color would be visible on any color background.

Also I don't get why they chose THAT color as background for light gray, yellow and white text. They should have chosen black or something, because light gray on medium gray is definitively not very easy to read.

Which means that, technically, it's already all set up and ready to go in there for us to be able to choose our own backgrounds for Text(. That's all I'm getting at, and they can do it within TextColor(, which wouldn't kill compatibility at all using the Text( command.

Ahh, gotcha, then I agree. And I bet once we start delving into things like _Vputs some more, we'll find flags for text foreground and background colors, which will at least make an ASM stub or Hybrid BASIC library available. As you say, though, it would be even cleaner if they would expose the background color somehow.

I really want my dual layer ASCII back D:

Unless we convince TI to give us more Text( modes and settings, or until someone makes a proper set of hybrid BASIC libraries, I'm afraid you're SOL. That certainly sounds like something that needs to be added to the list of functions programmers would want in a hybrid library, though.

Via hybrid libraries it would be nice. Oh well, for now there are always text sprites (although they'll obviously be slower and look blocky)

For values 10 to 24, since those would require 2 bytes anyways, we won't get a size optimisation, but it won't cost us any bytes and it might be faster to use these than other methods. Has anybody tested the speeds of these tokens compared to using an equivalent number?

For those interested in RGB colors for the indexed colors, here they are (thanks to SourceCoder 3). Note that these are decimal and in (R5,G6,B5) format; to get (R8,G8,B8), multiply by (8,4,8).
Code:

I'm new to this calculator.

Are 10 to 24, the only colours accessible for this calculator in TI-BASIC? Does it have no way to access the 16-bit colours which the screen can display?

IS the graphing portion of the screen (265x165) the only place that TI-BASIC can write a colour pixel
to the screen?

Is there a way to completely clear the screen, and make a program that used colour pixel on or off commands to draw everywhere on the screen?