12-30-2012, 07:07 PM
(This post was last modified: 12-30-2012, 11:08 PM by Bombshell93.)
actually 8-bit has little to do with console, when you talk about that your talking about the general processor, typically in graphics the X-bit is referring to the colour resolution, i you want it to be in a style specifically aimed at a console thats a whole other constraint in itself.
that said 8-bit colour is typically R3 G3 B2
meaning Red and Green can have the following values (0 - 255 format) 0, 36, 73, 109, 146, 182, 218, 255
and blue can have the following values (0 - 255 format) 0, 85, 170, 255
Thats the closest you can get to 8-bit colour (processable by an 8-bit processor and held within an 8 bits of memory)
Without doing my research I think the NES limitations of colour may have been due to lack of graphical memory, the 3 colours which would have actually been 4 colours including transparency, would mean 2-bits per pixel in an 8x8 square each square assigned 3 colours and a reserved transparency (likely transparency relating to, do not draw).
EDIT: I major goofed my math and some of my logic!
at the native resolution (256 x 240) 60 KB would be the raw, each pixel 8 bits of colour.
compressed however it would be 15KB for the screen and 3.75KB index, however changing index per 8 x 8 square and printing directly to the front buffer so likely memory use at a time was along the lines of 16 Bytes for the 8x8 values and 4 Bytes for the colour buffer.
... sorry for the tangent, misleading ambiguity of the phrase "8-bit" is a touchy subject for me XD
that said 8-bit colour is typically R3 G3 B2
meaning Red and Green can have the following values (0 - 255 format) 0, 36, 73, 109, 146, 182, 218, 255
and blue can have the following values (0 - 255 format) 0, 85, 170, 255
Thats the closest you can get to 8-bit colour (processable by an 8-bit processor and held within an 8 bits of memory)
Without doing my research I think the NES limitations of colour may have been due to lack of graphical memory, the 3 colours which would have actually been 4 colours including transparency, would mean 2-bits per pixel in an 8x8 square each square assigned 3 colours and a reserved transparency (likely transparency relating to, do not draw).
EDIT: I major goofed my math and some of my logic!
at the native resolution (256 x 240) 60 KB would be the raw, each pixel 8 bits of colour.
compressed however it would be 15KB for the screen and 3.75KB index, however changing index per 8 x 8 square and printing directly to the front buffer so likely memory use at a time was along the lines of 16 Bytes for the 8x8 values and 4 Bytes for the colour buffer.
... sorry for the tangent, misleading ambiguity of the phrase "8-bit" is a touchy subject for me XD