VideoCommon: normalize light direction

[degasus]

It seems that the lighting direction must be normalized. This fixes lots of lighting issues mostly shown in the d3d backend.

[MayImilae]

Screenshots from galop1n:

bug - http://i.imgur.com/xVYxgVl.png
correct - http://i.imgur.com/3jqdFLs.png

[neobrain]

Can we have a hwtest for this?

[OussamaDanba]

Apart from fixing the SMG2 issue this also fixes issue 6125.

[delroth]

And a fifolog please :)

On Fri, May 23, 2014 at 4:18 PM, Tony Wasserka notifications@github.comwrote:

Can we have a hwtest for this?

—
Reply to this email directly or view it on GitHubhttps://github.com//pull/394#issuecomment-44014336
.

Pierre "delroth" Bourdon delroth@gmail.com
Software Engineer @ Zürich, Switzerland
http://code.delroth.net/

[Linktothepast]

Perhaps Issue 6269 is also relevant?

[OussamaDanba]

This also seems to fix issue 6269. I can no longer reproduce it after applying the patch.

[JMC47]

It'll also fix Network Transmission, 6543

[MayImilae]

Can someone (including myself) remember to close these issues when this PR is pushed?

[degasus]

@delroth Just pick any fifo log of this issue reports ;)

@neobrain Do you think we should move this normalization to the CPU? It's easy to implement at https://github.com/dolphin-emu/dolphin/blob/master/Source/Core/VideoCommon/VertexShaderManager.cpp#L272

[delroth]

Any point to move that to the CPU? Trading CPU load for GPU load here
sounds like a fine idea.

On Mon, May 26, 2014 at 1:22 PM, Markus Wick notifications@github.comwrote:

@delroth https://github.com/delroth Just pick any fifo log of this
issue reports ;)

@neobrain https://github.com/neobrain Do you think we should move this
normalization to the CPU? It's easy to implement at
https://github.com/dolphin-emu/dolphin/blob/master/Source/Core/VideoCommon/VertexShaderManager.cpp#L272

—
Reply to this email directly or view it on GitHubhttps://github.com//pull/394#issuecomment-44180396
.

Pierre "delroth" Bourdon delroth@gmail.com
Software Engineer @ Zürich, Switzerland
http://code.delroth.net/

[degasus]

@delroth This won't be a 1:1 trade. It can be done once per vertex (or pixel) on the gpu or once per lighting parameter changes on the cpu.

[delroth]

Good point, I should think before replying :)

On Mon, May 26, 2014 at 1:52 PM, Markus Wick notifications@github.comwrote:

@delroth https://github.com/delroth This won't be a 1:1 trade. It can
be done once per vertex (or pixel) on the gpu or once per lighting
parameter changes on the cpu.

—
Reply to this email directly or view it on GitHubhttps://github.com//pull/394#issuecomment-44182296
.

Pierre "delroth" Bourdon delroth@gmail.com
Software Engineer @ Zürich, Switzerland
http://code.delroth.net/

[galop1n]

It would be possible to do the normalize on the cpu as it is bare constant, but it is not like we are suffering of gpu issues, and we cannot say the same of cpu.

[neobrain]

@degasus Should be normalized on the CPU indeed. If not for performance reasons, then for the sake of keeping the shader code a bit cleaner.

[neobrain]

By the way, is the software renderer already normalizing this properly?

[degasus]

@neobrain yeah, we need some hw test for this issue. All current fifologs should also play fine on videosw as it has the same overflow result.

[degasus]

As #439 is merged, I've updated this PR to normalize on the CPU.

[JMC47]

LGTM; the dffs of the glitchy lighting show up fine now.

[neobrain]

Please change the PR summary to be an actual summary rather than a novel squeezed into a single line.

[degasus]

PR summary and commit msg changed.

[neobrain]

LGTM, but I suggest against merging this before a hwtest is written. We have no real policy for this, but maybe we can start having one.