EFB - 'embedded frame buffer' Specifications

Found this information about the EFB
Maximum capacity of 640 width x 528 height x 6bytes (3 colour & 3 Z buffer) - that’s 2027520 bytes

The ogc libs also support these facts saying - "The stride of the EFB is fixed at 640 pixels"

As for antialiasing (anyone used this mode?), samples are computed for each pixel - “and the total available number of pixels in the EFB is reduced by half (640 pixels x 264 lines)”

I see mode hacks using 720 (I think this is mad!!!), this clips tones of edge on my two TV's, both old and new HD 1080p using component lead.

In this example I found you can get away with 678 to remove black borders in 16:9 (but it may still clip for others but it’s a good compromise value to use and hopefully in the worst case it will only clip a tiny bit from the edge)

if (CONF_GetAspectRatio() == CONF_ASPECT_16_9)
{	
    vmode->viWidth = 678;  // probably top limit for stretching the display onto your TV
    //    vmode->viWidth = 720;  //Not a good idea as this will crop badly on most TV’s if not all
}

VI width is NOT the same as EFB width. EFB is the internal buffer where graphics are rendered using GX. VI refers to the video signal output by video hardware. To resume, once rendering is done, EFB got copied to XFB (external frame buffer) and XFB is used by video hardware to generate video signal. XFB width can be horizontally upscaled by video hardware to increase active video width, that's what VI width is refering to.

And yes, this is known fact, the "perfect" VI scaling pretty much depends on the TV model you are displaying on, as well as the type of connection (analog or digital), and you can also use larger value than 640 in 4:3 mode, it won't hurt.

On that matter, I am starting to doubt the Video Hardware is able to really output '720' pixels as the video standard for 13.5MHz pixel clock seems to be 704 active pixels (understand, pixels that contains "visible" data),according to that link: [lipas.uwasa.fi] .

I think that when you use a scaling value of 720 with analog video output (RGB, S-Video or Composite), 16 pixels are simply lost in the blanking period and can't be seen, even on TV with minimal overscan. This might be different when using digital video.



Edited 3 time(s). Last edit at 05/06/2011 02:21PM by ekeeke.

The WII could use a different clock higher than 13.5MHz which is a standard for DVD player (see "custom video resolution" in the article you linked and the Amiga example)

In this case all the 720 pixels are shown.

ekeeke I know, that's what said!!! // probably top limit for stretching the display onto your TV
anyway the EFB maximum is 640 x 528... so thats the max resolution, it's just the way the hardware works.

oibaf 640x528 is all the Wii can offer, you just can't pump out 720 pixels per line

Just because the EFB max is 640x528, doesn't mean that's the maximum resolution. You can perform multiple copies from the EFB to the XFB to get more (unscaled) horizontal pixels.

Hi tueidj, don’t think you can squeeze more than 528 due to the hardware design.
I agree adding more scanlines does sound plausible, but how would you disable the effect of xfbHeight & efbHeight? Maybe possible for NTSC /PAL60 but Y scaling would still kick in once you pass 528, unless you drop the width to increase the height. Plus if it did work you may not see anything extra anyway. Better of using a pseudo resolution. ;)


The fact still remains 640x528 is the Wii’s designed top resolution for a good reason.

Let’s not forget most homebrew tends to use 640x480 for compatibility and the thrill of 60fps.

I'm not proposing it as a theory - it's fact, I've coded and tested it. MPlayer-CE (and also probably WiiMC) also has code to do it. It's not really a good idea though because:
a) It complicates the rendering process, from both a coding and performance standpoints
b) The EFB->XFB Y scaling isn't that bad (nowhere near as bad as GX's bilinear texture scaling)
c) At most it's only going to let you squeeze in an extra 64 horizontal pixels (640->704), which really isn't worth sacrificing the overscan area that you normally have
But having said that if you're going to proclaim a certain resolution as being the absolute max that the wii can do, you might as well use the correct values.

Thanks for the information tueidj - but I did say "the Wii’s designed top resolution" just to cover myself :)

Without tricks the Wii’s designed top resolution still stands at 640x528