Emulator

debugged on irc: I guess it's likely the VI output aspect. We check for this on startup right now which is just wrong: https://github.com/dolphin-emu/dolphin/blob/master/Source/Core/Core/Core.cpp#L197
Even wrose, this doesn't use the VI registers. So we have to check which VI register sets the aspect ratio.

It seems VI registers VERTICAL_TIMING and VBLANK_TIMING_* are responsible:
(CONTROL_REGISTER just for reference/to show it's not doing anything weird)

bootup
VI_VERTICAL_TIMING 6 (EQU 6 ACV 0)
VI_CONTROL_REGISTER 1 (ENB 1 NIN 0 DLR 0 LE0 0 LE1 0 FMT 0)
VI_VBLANK_TIMING_ODD 1301e8 (PRB 488 PSB 19)
VI_VBLANK_TIMING_EVEN 1201e9 (PRB 489 PSB 18)
normal
VI_VERTICAL_TIMING e16 (EQU 6 ACV 225)
VI_CONTROL_REGISTER 1 (ENB 1 NIN 0 DLR 0 LE0 0 LE1 0 FMT 0)
VI_VBLANK_TIMING_ODD 110028 (PRB 40 PSB 17)
VI_VBLANK_TIMING_EVEN 100029 (PRB 41 PSB 16)
cinematic
VI_VERTICAL_TIMING 986 (EQU 6 ACV 152)
VI_CONTROL_REGISTER 1 (ENB 1 NIN 0 DLR 0 LE0 0 LE1 0 FMT 0)
VI_VBLANK_TIMING_ODD 5b0070 (PRB 112 PSB 91)
VI_VBLANK_TIMING_EVEN 5a0071 (PRB 113 PSB 90)

fwiw, hardcoding the "normal" value will produce a correctly-scaled but improperly placed image (as expected...).

u32 fbHeight = /m_VerticalTimingRegister.ACV/225 * (field == FIELD_PROGRESSIVE ? 1 : 2);

So the fix is just to correctly pass the pre- and post-blank pad regions to the video backend...is there functionality for that kind of thing already?

Anyways, those fields hold the answer, someone just needs to convey the info to the video backend, and I don't know how to do it :)
The minimum info needed is just that the frame should start at +PRB number of horizontal lines from the top of the frame...or -PSB lines from bottom of frame.

As tueidj pointed out:
ACV * (interlaced ? 2 : 1) + PRB + PSB + 18 = NTSC_LINE_COUNT

So that makes sense of the values, and points out there is 18 lines of slack, somewhere...

btw a picture to maybe encourage someone to implement it...(cough degasus) :D
http://i4.minus.com/iboC5CcSNM060.PNG

Before 5.0 would be good :D.

As for the name, the whole point of the issue-agnostic name was so that no matter what the source of the issue was, the title could remain the same. So eh, let's do a compromise.

If it does get fixed be prepared for the onslaught of complaints about games having letterboxing applied when they didn't before (even though that's how they're meant to look).
BTW the title is still wrong, the issue is there's a scaling effect being applied when there shouldn't be.

I think it'll be fine; we just put a progress report section on what was going on and say why, and people won't complain as much.

The complaints of bonkers shaped planets and things would be way more common and much louder than any complaints on the cropped picture. And with the cropped image, we can just point to console and say that's how it's supposed to be. With warped planets, it's just broken.

Will the fix for this also allow changing to widescreen in-game rather than forcing 16:9 as well?

@patrick: Likely

?! I DEMAND THIS FEATURE ASAP.

@MaJoRoesch Fixing this would affect dozens of other games, resulting in them being displayed with letterboxing when played in Dolphin while on real hardware the black borders are typically hidden by the TV's screen bezel. If you think there are less people that are going to care about their previously perfect games getting black borders forced upon them rather than those who care about misshapen planets in Star Wars, good luck to you.

So I found an interesting side effect. With "Auto adjust Window Size" enabled, the window shrinks during the stretched portions, then stretches back out the usual size after the stretched portion passes. I don't know if that matters, but there you go.

@tueidj - Easily fixable by making this optional, via the UI or a gameini setting.