why does the gamecube have color dithering?

[vazel]

i was playing wind waker and noticed odd visual anomalies. most noticeable in the water when out at sea at night. took me some time to figure out it was color dithering. and wind waker doesn't seem to be the only gamecube game with noticeable color dithering. why is this a problem on gamecube? is this something that will be improved in revolution? will backwards compatability on the revolution improve on this? will i be able to play windwaker on revolutin without color dithering artifacts?

 

[Blade]

I think heavy dithering would imply that Wind Waker is running in 16-bit color. Which I understand given its graphical style.

 

[see colon]

the gamecube hase a framebuffer depth of 24bit including alpha. games that use alpha have less color accuracy, and thus, dithering.

 

[Fox5]

i was playing wind waker and noticed odd visual anomalies. most noticeable in the water when out at sea at night. took me some time to figure out it was color dithering. and wind waker doesn't seem to be the only gamecube game with noticeable color dithering. why is this a problem on gamecube? is this something that will be improved in revolution? will backwards compatability on the revolution improve on this? will i be able to play windwaker on revolutin without color dithering artifacts?

1. Component cables (and progressive scan) help a lot with dithering.
2. I think due to the 3MB of vram on the gamecube that most games only use 16 bit color.

 

[Apoc]

2. I think due to the 3MB of vram on the gamecube that most games only use 16 bit color.

I don't think you are correct. At 480p, it only takes 1.75 MB for the framebuffer and backbuffer at 24 bits.

 

[Barbarian]

I don't think you are correct. At 480p, it only takes 1.75 MB for the framebuffer and backbuffer at 24 bits.

IIRC GC stores the front buffer in regular ram at 16bits per pixel, so the embedded ram is used for back buffer and Z-buffer only.

 

[Fox5]

I don't think you are correct. At 480p, it only takes 1.75 MB for the framebuffer and backbuffer at 24 bits.

640x480x32 x 2 = 19660800 bits
/ 8 = 2457600 bytes
/ 1024^2 = 2.34Megabytes

Ok, you're probably correct then. Gamecube's edram definetely has the bandwidth to use a 32 bit framebuffer, so I'm guessing the dithering is just from the limitations of non-progressive output and that gamecube's shaders are likely only 6-bit to 10-bit integer precision given the time it came out. That, and devs may be using lower quality or compressed textures.

 

[Apoc]

640x480x32 x 2 = 19660800 bits
/ 8 = 2457600 bytes
/ 1024^2 = 2.34Megabytes

Ok, you're probably correct then. Gamecube's edram definetely has the bandwidth to use a 32 bit framebuffer, so I'm guessing the dithering is just from the limitations of non-progressive output and that gamecube's shaders are likely only 6-bit to 10-bit integer precision given the time it came out. That, and devs may be using lower quality or compressed textures.

Gamecube don't use 32bit color, only uses 24 bits.

 

[Fox5]

Gamecube don't use 32bit color, only uses 24 bits.

Why's that? Wouldn't that cause banding on transparencies? Or banding on everything if the bit allocation is 6bit per color channel and 6 bit alpha?

 

[darkblu]

translucencies are not affected much by the presence or absence of alpha in the destination buffer (i.e. unless multi-pass translucent techniques used). so 24 bits per pixel can easily be alpha-less and still not affect translucencies.

IIRC, the dithering in some of the GC titles comes from the 16bit framebuffer mode used during fsaa.

 

[Fox5]

translucencies are not affected much by the presence or absence of alpha in the destination buffer (i.e. unless multi-pass translucent techniques used). so 24 bits per pixel can easily be alpha-less and still not affect translucencies.

IIRC, the dithering in some of the GC titles comes from the 16bit framebuffer mode used during fsaa.

What games use FSAA? What type of FSAA does GameCube support anyhow? I remember sup-pixel anti-aliasing listed on the spec sheets, is that multi sampling?

 

[fearsomepirate]

i was playing wind waker and noticed odd visual anomalies. most noticeable in the water when out at sea at night. took me some time to figure out it was color dithering. and wind waker doesn't seem to be the only gamecube game with noticeable color dithering. why is this a problem on gamecube? is this something that will be improved in revolution? will backwards compatability on the revolution improve on this? will i be able to play windwaker on revolutin without color dithering artifacts?

Are you talking about the vertical lines in the water at night? I always thought that was something my TV was doing, because I'd never seen before. At least I know it's not just me.

 

[Iron Tiger]

Are you talking about the vertical lines in the water at night? I always thought that was something my TV was doing, because I'd never seen before. At least I know it's not just me.

There's a static shaded rectangle on the lower part of the screen that I've noticed in a lot of GC games, on various TVs and GCs, but when I brought it up here and on other forums, nobody else could confirm they were seeing it or what could be the cause of it.

 

[Fox5]

Are you talking about the vertical lines in the water at night? I always thought that was something my TV was doing, because I'd never seen before. At least I know it's not just me.

Nintendo has confirmed that those vertical lines are something that happens on HDTV, though I guess they're just a part of the rendering that isn't visible on most TVs.

 

[Shompola]

They are dithering, color banding issues. Has nothing to do with component, hdtv and progressive scan. A shitty tv can display those so nice artifacts just fine.

 

[Fafalada]

IIRC GC stores the front buffer in regular ram at 16bits per pixel, so the embedded ram is used for back buffer and Z-buffer only.

Frontbuffer is converted to 16bit YUV and stored in main mem yes.
However - 640x480P will run you 1.8MB at 24bit - and MOST games out there render to more then one render target, so unless all your offscreen targets fit inside 200KB, you will need to drop the resolution of either Z or Frame to 16bit.

 

[Fox5]

Frontbuffer is converted to 16bit YUV and stored in main mem yes.
However - 640x480P will run you 1.8MB at 24bit - and MOST games out there render to more then one render target, so unless all your offscreen targets fit inside 200KB, you will need to drop the resolution of either Z or Frame to 16bit.

Gamecube uses a YUV color space instead of RGB?

 

[ector]

Frontbuffer is converted to 16bit YUV and stored in main mem yes.
However - 640x480P will run you 1.8MB at 24bit - and MOST games out there render to more then one render target, so unless all your offscreen targets fit inside 200KB, you will need to drop the resolution of either Z or Frame to 16bit.

Really? All "render to texture" we've seen in Gamecube games running them in Dolphin is rendering as usual, copy to texture from main framebuffer, then render the main image, possibly using that texture. Didn't even know it was possible to render anywhere else than offset #0 in the video ram. Doubt it is.

 

[Fafalada]

Didn't even know it was possible to render anywhere else than offset #0 in the video ram. Doubt it is.

From what I recall it's possible - but it's been a long time since I read the docs, so I could remember wrong.
Anyway all "render to texture" has to pass through main memory of course, there's no way around that on GC, but I was under impression that it ought to be be more efficient to process render targets concurrently rather then sequentially on GC (in case of stuff like reflections where you get a lot of texture sharing across targets).

Gamecube uses a YUV color space instead of RGB?

No, just stores the frontbuffer in YUV (saves main memory and bandwith) - because YUV is the output you send to TV anyhow.
Other machines use CRT controller to convert to YUV on scanout.

 

[darkblu]

Really? All "render to texture" we've seen in Gamecube games running them in Dolphin is rendering as usual, copy to texture from main framebuffer, then render the main image, possibly using that texture. Didn't even know it was possible to render anywhere else than offset #0 in the video ram. Doubt it is.

technically, whether your framebuffer is fixed at an address or it's relocatable does not matter much as long as you have control over the viewport (which AFAIK flipper has). so what you say does not contradict to what Faf says - you may have multiple (viewport) targets within the EFB, which itself is at a fixed address (of course any secondary render tagets need to pass through main memory). nevertheless it's curious to know the statistics on the usage/non-usage of that, so your observations are most interesting.

speaking of frambuffes, something interesting about the XFB - it seems to be able to hold other pixel fromats than the YUV too - so i was thinking would the GC still output to YUV XFB when he console outputs RGB signal through the digital out. or was RGB output never an option?