Project

General

Profile

Actions

Emulator Issues #7948

closed

Rogue Leader is Missing a Scaling Effect (VI)

Added by MayImilae over 9 years ago.

Status:
Fixed
Priority:
Normal
Assignee:
-
Category:
GFX
% Done:

0%

Operating system:
N/A
Issue type:
Bug
Milestone:
Regression:
No
Relates to usability:
No
Relates to performance:
No
Easy:
No
Relates to maintainability:
No
Regression start:
Fixed in:

Description

Star Wars Rogue Squadron II: Rogue Leader (GSWE64) has a scaling effect that it uses in various places of the game, used to create a cinematic aspect ratio. Without this effect, Dolphin shows these areas as being stretched super tall.

Long Ago Text
Console - http://i.imgur.com/A9XBSK8.jpg
Dolphin - http://i.imgur.com/41cQHIz.jpg

Star Wars Logo
Console - http://i.imgur.com/1ArniDX.jpg
Dolphin - http://i.imgur.com/hT3T1fc.jpg

Blue Planet
Console - http://i.imgur.com/VVsmhmG.jpg
Dolphin - http://i.imgur.com/n9Q7axk.jpg

Death Star
Console - http://i.imgur.com/AwJu3y9.jpg
Dolphin - http://i.imgur.com/RV2e6P7.jpg

I've tried OpenGL, D3D, RealXFB, software (didn't work), JITIL (didn't work), and a ton of other settings. Nothing had any effect.

To reproduce it, simply go to any of the areas shown in the above screenshots on console and in dolphin. It's an opening area so it's extremely easy to get to and look at. I used Phire's custom build for this so the planets could be seen, but it is present in master and can easily be identified with the text examples.

Tested on revisions:
4.0 win64 - Pfft, didn't even run.
4.0-4603 win64 - Bug is present
Phire's special 4.0-4654 win64 - Bug is present

Test on system:
Core i5 3570K @ 4.7ghz
Nvidia GeForce GTX 760
Windows 7 x64

Actions #2

Updated by degasus over 9 years ago

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.

Actions #3

Updated by Anonymous over 9 years ago

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)

Actions #4

Updated by Anonymous over 9 years ago

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?

Actions #5

Updated by Anonymous over 9 years ago

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...

Actions #6

Updated by Anonymous over 9 years ago

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

Actions #7

Updated by JMC4789 about 9 years ago

  • Status changed from New to Accepted

We can always riot if degasus doesn't implement it.

Actions #8

Updated by MayImilae about 9 years ago

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.

Actions #9

Updated by tueidj about 9 years ago

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.

Actions #10

Updated by JMC4789 about 9 years ago

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.

Actions #11

Updated by MayImilae about 9 years ago

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.

Actions #12

Updated by ZephyrSurfer about 9 years ago

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

Actions #13

Updated by degasus about 9 years ago

@patrick: Likely

Actions #14

Updated by JMC4789 about 9 years ago

?! I DEMAND THIS FEATURE ASAP.

Actions #15

Updated by tueidj about 9 years ago

@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.

Actions #16

Updated by MayImilae about 9 years ago

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.

Actions #17

Updated by MayImilae over 8 years ago

  • Status changed from Accepted to Fixed
Actions

Also available in: Atom PDF