User:CarstenK/Screen aspect-ratio

From WiiBrew
Jump to: navigation, search

Wrong aspect ratio... 16:9 widescreen or normal.... PAL black borders?

Maybe libogc and GX is just at a low level where it actually doesn't handle non-square pixel aspect ratio, either that or there is a bug in it? This maybe might explain the black border issue some PAL users are reporting too.

I thought the lib provided a 640x480 surface so I was surprised when I could never draw a perfect square or circle on my LCD. In standard mode everything was always too tall and almost looked correct in 16:9 but not quite.

Some PAL users reported black borders on the edges of the HBC and independently for other programs too. The circles containing arrows at the left and right of the HBC don't look circular to me but that could be by design? In the HBC source were those arrows really originally circles and not tall ovals?

For many Wiibrew this ultimately doesn't matter one iota. I do play MahJongg stretched full-screen to 16:9 to avoid black borders and enjoy it fine yet this aspect ratio thing deeply troubles me.


Update: After experimenting with GRRLIB 3.01a and patching it, I found how to draw perfect (correct) circles on an NTSC LCD TV in both 16:9 widescreen and standard mode. This method can also be applied to programs directly accessing GX without GRRLIB but needs to be calibrated for PAL.

It probably has only to be tweaked a little for PAL, please let me know how my patch works for you in the EU. The patch is in the GRRLIB forums, you should also try the other great patches by Wil which were used during my experiments.

My numbers may be slightly off because I just used a 16ths inch ruler pressed against the screen (albeit flat LCD) to measure the centre lines of the width and height of circles, then fudged numbers in GRRLIB until the width the height looked the same. Keep in mind if you have a CRT the values you need may be slightly off due to calibration, but still would be interested to hear whether PAL users can use the same numbers as I used and have things look right, but I suspect not....

NTSC TVs use non-square pixels, I think 11/10 and PAL uses 1.094:1 yet I can't figure those numbers into any calculation to arrive at the values I found experimentally to get a correct aspect ratio with GX using GRRLIB.

If anyone can demonstrate a calculation to arrive at something close to my numbers or the numbers Pepsiman used for PAL I would be very interested.

I should note here I suspect emulators will not benefit from or should even be considering any of this at this time, this discussion probably will only benefit Homebrew apps, unless there turns out to be a bug or something in libogc that should be patched. Most console emulators probably already output images at non-square pixel ratios true to the originals because a TV was the original expected output.

Microsoft provides some video test files at various pixel aspect ratios which may come in handy (below).

I have a test program for drawing various circles and squares on the screen if anyone is interested. If people even care about this and there is enough interest this page can be moved.

The goal here is to provide:

  • a consistant output no matter what display PAL/NTSC
  • an easy, standard way of coding whether directly with GX or a library like GRRLIB
  • an easy way to optionally implement widescreen 16:9 for homebrew while maintaining correct aspect ratio

It doesn't have to be perfect but to me currently aspect ratio seems "broken" as-is and it would be nice to have simple examples and code to encourage homebrew developers to implement optional widescreen capabilities.

Please add responses at the very bottom. CarstenK 08:08, 12 August 2008 (CEST)

External Links

Discussion

Mr_Alert reports that NTSC System Menu uses these framebuffer sizes:

  • 670x456 4:3
  • 686x456 16:9

(Don't know yet how these figures were arrived at.)

Are these EFB or XFB framebuffer sizes, or what the XFB is scaled to by VI? --Pepsiman 12:48, 18 August 2008 (UTC)
I'll ask for clarification. We do need to know whether this comes from a video capture board (and which model) or from studying code, before working out any baselines for making calculations. Measurements are needed from PAL users too even if it is just video captures for now. The video card model is important to determine how many scanlines are being discarded and so on. CarstenK 01:29, 19 August 2008 (UTC)