Colors are not just pretty, they serve a vital purpose. Our brains can look at one image and be fooled into believing something that is not there.

Take this classic 3-dimensional model to show the difference of tints in locations:

From this clear image, you can see that (A) is darker color than (B).

But now let's start to cut down the colors to see what happens. First off, let's convert it to 256-colors, black and white.

So far so good, only the pillar changed. Let's go further. Now resize it to 128x128, the standard resolution of PICO:

We lost some detail on the text of (A) and (B), but that's fine. The board can still be seen clearly.

Now let's hack it down to 16-colors, here's where problems start to develop:

Ragged edges and clear compression shades. It's not pretty, but it's still there.

Now - keep an eye on the two marks where (A) and (B) are supposed. At this point we are going to simply load IMPORT this image:

directly into PICO and let it convert it to its fixed palette set. We now have this:

Now look at points A & B. The picture got so compressed, it lost the unique tint for A & B !

However, this is not why I called you here. No, it is because those two regions =ARE= exactly the same and have been through all the pictures. I'll prove it:

Let me show you.

From here, let's cut and paste (A) and (B).

There is no trickery here. These are the actual colors of the two regions. This is why I want to stress the importance of colors in programming. With a fixed and limited palette, you cannot pull off this amazing trick.

But even with a tiny custom 16-color palette set at a resolution of 128x128 pixel-level, the illusion reappears and is maintained.

Thus, I would like to propose colors to be changeable in PICO. Now, they don't have to be anything spectacular. Not even anything more than a single byte to represent a new color. Here is a table I made in BlitzMAX to show how its possible to have a full spectrum of colors saved in a single byte:

Taking a byte, 256, you can divide it 3-ways into 6 giving you red=(0-5), green=(0-5), and blue=(0-5). The total is 216. Should additional colors beyond this be desired, the remaining values 216-255 could be programed by ZEP to flash, animate, strobe, or pulse a unique set of colors for crazy effects.

However, 0-215 is the normal color set.

Here, I wrote this to show you in a grid:

As you can see, the 216th and last item has a brightness value of red=5, green=5, and blue=5. To approximate the color for standard Red, Green, and Blue, you can multiply that single digit of 0-5 by 51 giving you a neat 255.

Okay, now let's see how these colors actually appear:

Well that doesn't look very useful - but no, it actually is. You have 6-brightness levels for each of the R G and B. While it may not look like it, you can actually find PICO's color set in here, too.

If you want to really do some 256-color palette building, there is always Visibone's amazing 256-set.

So now maybe a custom 16-color palette does not seem like such a thing to avoid.

What do you think ?

Well, if you're trying to stylize, you can do a triad as a custom palette. So... solid white, solid black, then 3 shades of grey, tan/brown, and some shade of green/blue? You could also do two tweener shades of 3 additional colors, instead of 3 tweener shades of two.

The issue is, you really have to stylize and contrast well enough so that elements "pop," and still have this kind of cohesive effect.

For me, the strict limitations in pico 8 are what make it special. Feature creep would slowly destroy that. If you want all these added features, there are many other platforms, such as Love.

Sure, if you don't want a feature just don't use it, right? That's not the point. When the community is bound by the same Spartan conditions, it's much more interesting to see what people come up with. Expectations are low, but I continue to be impressed with what everyone accomplishes here with so little.

Rytrasmi, you're a sweet kid, but guess what ? We've already received an update to PICO - and they will continue to come - despite your hanging on to older versions.

So why not stick with the version that doesn't use the mouse to be truly retro ? Oh, I see. So as long as ZEP writes it, you accept it no matter what. I see. So if he DOES write drivers for keyboard, you will accept it too and have no memory of this conversation wanting to keep things as they are.

That does make you a little fickle, does it not ? :)

LOVE cannot be posted Online in an active community. Neither could I get LOVE to actually work. I think you're already aware of this.

And don't look too hard or you may find me busily writing workarounds to the situations I've mentioned earlier in PICO. THOSE programs, using the same limitations you and I both have, those you can hate if you like. :D

Tony, I think you're talking about what I've seen on the Apple computer - I believe it was Penguinsoft when I first saw it.

I doubt zep plans to build this out to a full on c64 or Apple II simulator but only he knows. I like the vision as it stands now and if it bloats up, so be it.

Your notepad program was interesting because of how you dealt with the limitation of no keyboard. If you had a keyboard, it would be just another notepad program and less interesting to me.

Writing work arounds is also the point! You've got GPIO and a C API for that.

Glad you liked Simple Notepad. I wrote it mostly cause I missed it. I have a GBA emulator on my PSP, but the work I did on my GBA notepad was incomplete, and I wasn't about to back to Dragon.

As for compensating for PICO's lack of hardware, it won't be as difficult as all that. I think you'll be pleased (or dismayed) with what I'm working on to tackle the keyboard problem.

I'm just wanting input so it would be possible to enter in numeric values and text. My solution will fix this.

But for now, finishing up a useful PICO library called TRX, which to me from Flash Gordon means "Transmit X." I'll post it when done.