For the sake of argument, let's say your screen is set to 24-bit color. Full RGB.
If it was set to one-bit color, you'd only see two colors - on and off, usually black and white.
The bitmap uses one BIT (not byte) per pixel to determine if it draws or doesn't draw. The mixture of on and off bits is what gives you an image (albeit a one-color image, like black on white). With a one-bit image you cannot do a mix of, say, red lines and blue lines, because all you can tell is whether or not the pixel is "on" or not.
You get an image representation in a nice small package. Teeny, tiny little bitmaps.
HOWEVER, when they display, the "on" portion can display in any color you want, assuming you're in a multi-color video mode. In 16-color mode (not 16 bits, 16 colors - or 4 bits), that bitmap could have its "on" pixels displayed in your choice of 16 colors. Having engineered many 16-color games in my day, I can assure you that the default 16-color palette sucks for animation. Be that as it may, any given 1-bit bitmap can render in your choice of color, but only one for the whole bitmap (because how else can you tell what pixel gets what color?).
So, if you have a forecolor of #FFFF00, you can do that because you're on a 24-bit system, but within the bitmap itself, you only get the one color, not a mix of colors. Got it?
On a 256-color bitmap (one BYTE or 8 bits per pixel) you get to use any 256 colors of your choice to make up the image. You can get photo-realistic pictures with 256-colors and a custom palette.
256-colors with a custom palette animates well, because it's quick to index to any given pixel (400 pixels into the row is 400 bytes into the row). The images are small, but if properly done, performance is great.
32-bit, which is really 24-bit with an alpha channel, is quick to calculate, because the 32-bit processors like to think in 32-bit chunks. But it makes a given image really big, space-wise, so it's not all that desirable if memory is an issue.
1-bits, which are tiny, are a pain to animate, because every time you move the image, you have to look at all the edge pixels, then figure out which byte they're in, then figure out where the bit is in relation to the coordinates, and it's just a lot more overhead. If you're blitting out to a 24-bit color space anyway, all you've done is increase your calculations, but probably conserved more memory than necessary. You could probably get much better performance without a damaging impact on memory by using 256-color (1 byte) images; thus giving you a broad range of color instead of just one, but still fast access and animation.
One day, over a beer, I'll tell you about the joys of rotating a TIFF image on a machine with 512K bytes of memory. You get to understand pixels Real Quick. :)
- Tab
At 05:06 PM 9/12/03, [EMAIL PROTECTED] wrote:
> Other than that, 32-bit would be fastest from the point of view of
> accessing (quickest to access a 32-bit offset) but it's a pig when it comes
> to space.
Space isn't an issue. Performance definitely is.
Now, here's the kicker. We're setting the forecolor of the sprite to #FFFF00 (yellow). Yet the member itself is a 1-bit bitmap.
Is it possible we're changing the member's depth at runtime?
Definitely going to try some tests.
Cordially,
Kerry Thompson
[To remove yourself from this list, or to change to digest mode, go to http://www.penworks.com/lingo-l.cgi To post messages to the list, email [EMAIL PROTECTED] (Problems, email [EMAIL PROTECTED]). Lingo-L is for learning and helping with programming Lingo. Thanks!]
