3DO ZONE Forums

What was the 3do's color palette? And how many colors could it display simultaneously?

Believe it operates off a 24-bit True Color premise. The 3DO is capable of displaying 16 million pixels simultaneously. When it comes to color properties 3DO could give Saturn & Neo Geo a run for their money.

The NeoGeo was able to display 4096 colors at once, if I recall
correctly - and the Saturn...? Hm, I dont know.

But, is there really a difference between 16bit color and 24bit?
I mean, can one really notice it?

By the way: the 3DOs native resolution is 320x240 pixel.
That means 76.800 pixels on the screen.
So how could more than 76.800 colours at the same time be
possible, given that one pixel can have one color?

Jones wrote:But, is there really a difference between 16bit color and 24bit?
I mean, can one really notice it?

Are you serious? Ok I know most people shouldn't be able to tell the difference but does anyone who would actually care really believe that? It's kinda like the difference between 24fps and 30fps.
Anyway...
3DO can produce 16,777,216 colors (same simultaneously)
NEO-GEO can produce 65,536 colors (4,096 simultaneously)
Saturn can produce 16,777,216 colors (same simultaneously)

Jones wrote:By the way: the 3DOs native resolution is 320x240 pixel.
That means 76.800 pixels on the screen.
So how could more than 76.800 colors at the same time be
possible, given that one pixel can have one color?

It can produce an image up to 640x480.
That means 307,200 pixels on the screen.
Your question is a good one for anyone who's given it a thought. The answer is actually quite simple. Just because you don't see something doesn't mean it's not rendered. That's why even a console like the the Dreamcast gives a picture that has more colors in a single frame than it's predecessor the Saturn when they both produce 16,7 million simultaneously. The more pixels you make them more you see.

I'm coming down off a migraine so I'm sorry if some of this doesn't make sense.

3DO Experience wrote: Your question is a good one for anyone who's given it a thought. The answer is actually quite simple.

This remained as an unredeemed promise.
Anyway, I hope your headaches get better soon!

How many pixels could the 3do move per second?

Somewhere between nine to sixteen million.

How many polygons can the 3DO display per second compared to the Saturn? It seems to me that the 3DO has smoother graphics and less jaggies.

oldskool wrote:How many polygons can the 3DO display per second compared to the Saturn? It seems to me that the 3DO has smoother graphics and less jaggies.

From what I'm told, the 3DO could display 50,000 polygons per second, while the Saturn could display a whopping 200,000 texture-mapped polygons or 500,000 flat-shaded polygons per second.

oldskool wrote:How many polygons can the 3DO display per second compared to the Saturn? It seems to me that the 3DO has smoother graphics and less jaggies.

From what I can tell, polygonal-based 3DO titles tend to look uglier around the edges on a greater occurance than on the Saturn. There are exceptions, of course (for instance, Bladeforce looks pretty sharp around the edges). The texture quality between games on both systems seems pretty close though.

There was a different color palette for the background vs. for cels. Cels, I think, could have like a 1, 2, 4, 8 or 16 bit palette. The background could be 24 bits.

We figured out some cool tricks to abuse the palette structure into generating alpha blending effects.

Coolies!

The framebuffer depth was 16 bits per pixel, arranged in a XRGB1555 layout. However, each 5-bit color component indexed into a table (CLUT -- Color LookUp Table) which yielded an 8-bit output. So that's where the 16M colors figure came from. The CLUT could be reloaded at any time, which gave you a very inexpensive fade to black. You could also use the CLUT for very simplistic gamma correction.

I also dimly recall that the high-order bit could be used to select an alternate CLUT. A couple of titles used this at the sixth bit of green, yielding RGB565.

The display resolution was 320 pixels across, period. There was a mode where you could apply horizontal and vertical box fillters. Adjacent pixels would be averaged together so that you'd see pixel(N), (pixel(N) + pixel(N+1)) / 2, pixel(N+1), etc. Since there were arguably 640 discrete transitions on each line, marketing decided to say the machine had 640 x 480 resolution, and inflated all their quoted fill rates by a factor of four. When developers learned the truth, they weren't happy. There was a feature whereby you could apply per-pixel weighting to get a good approximation of a true 640x480 image, but no one I knew ever used it because it was so goofy.

The cel hardware always output 16 bits per pixel to the framebuffer. Cel input was a variety of bit depths (1, 2, 3, 4, 5, and 16 bits per pixel). The decoded value was used to index into a pixel lookup table (PLUT, not to be confused with the CLUT) to yield a 16-bit output. If you used run-length encoding, you could also use declared transparency. So if, for example, you had a 4-bit image, you could have transparency *in addition* to the available 16 colors (in other words, you didn't have to spend a color on the transparent parts of your image).

Cel rendering was source-based -- the entire source image was sampled no matter how small you scaled it on screen. Smart developers (unlike me) did MIP-map management by hand, ensuring that the scaling never fell much below 1.0 and thereby wringing optimum performance from the chip.

ewhac wrote:cel details from ewhac

ewhac's memory of the graphics capabilities of Opera supersedes mine... where we differ, he is definitely more correct.

I wish my memory was half as good. LOL