Upon further thinking (and fantasizing), one pixel may also contain a long integer number (0 - 2^32 or -2^31 - 2^31) or two integers of 16 bits size. In the latter case, one pixel could contain an x,y pixeladress on a screen as large as 32K x 32k pixels (which will undoubtly come at some future moment). This in turn facilitates the idea of scattering a pixelized message all over the screen using a linked list mechanism.
Using "integer" pixels, one could write functions to add, multiply, etc. pixels. These function would not be simple as the automatic conversion to floating format in SB has to be ignored.
I will stop here, because i see a new "pixel based" programming language coming up.
Thinking about encryption: i already made an hard to crack encryption/decryption function (somewhere in this programming section). If such encrypted message (which remains within the ascii character range) is pixelized and scattered over a screen, already filled with random pixels in the same ascii range, there is a double decryption problem. The reciever needs to know the key and the starting screen adres of the pixelized message on the screen.
Time to write some basic functions now.
