Emulator

please flick back and forth between the two imagur links to see the green box clearly.

I can confirm It's present in my computer aswell.
Kinda hard to notice. but it's there.

The problem outlined here is fixed in limburgerite's fork, iirc: http://code.google.com/r/limburgerite-dolphin-emu/source/list?name=xfb-fixes

Sorry for being MIA for so long.

See
http://code.google.com/r/limburgerite-dolphin-emu/source/browse/Source/Plugins/Plugin_VideoDX11/Src/Television.cpp?r=9d7a6d45985a#93
for an explanation of the issue and how I fixed it.

thanks both

@ NeoBrainX: I'm working on giving each fix its own branch, hopefully with fewer ZOMG I'M SO ST00PID commits.

In the meantime, I've made a cleaned-up fix for this issue:
http://code.google.com/r/limburgerite-dolphin-emu/source/detail?name=issue-6483&r=6ca1410bab4d34e7cff96c295d3d09934f7dec31
It's a pretty simple change that only affects Television.cpp/.h. Should I create a pull request for this specific commit?

The background is only filled in during initialization.
Will there be issues if a game starts with a 640 wide xfb and drops down to a smaller one later?
I don't know if any games do that.

Otherwise, looks fine to me.

I thought about the XFB size shrinking, but never saw any problems in my testing (the border would probably contain garbage instead of green in that case).

Perhaps there's some way to monitor size changes and clear out the unused area if it shrinks? Might be more trouble than it's worth.

@ limburgerite: I don't think a PR is necessary for that patch. Just one thing: Instead of using UpdateSubresource, ID3D11Device::CreateTexture2D allows you to specify initial texture data with the second parameter (cf. http://msdn.microsoft.com/de-de/library/windows/desktop/ff476521%28v=vs.85%29.aspx ). Could you change your patch to do that? Apart from that it should be fine for merging.

@ NeoBrainX: Done, updated fix is here:
http://code.google.com/r/limburgerite-dolphin-emu/source/detail?r=f4495ec7a4948ae158abe86ac70e776b9ef00068&name=issue-6483

"// is actually two green pixels - YCbCr black is 16,128,16,128)" Is that supposed to be ARGB or RGBA or .. ?

That line should probably read:
// is actually two green YUYV pixels - YUYV black is 16,128,16,128

YCbCr black is technically 16,128,128 (y,u,v)

Too bad DXGI_FORMAT_YUY2 is only supported in Window 8...

Right, I misunderstood the point of that comment. It makes sense now. I'll be pushing it in a minute with your new comment.

Wait, should it be YUVY in the comment above that line as well?
// (remember, the XFB is being interpreted as YCbCr, and 0,0,0,0

Yes, actually I just updated all the references to YUYV. I can push an updated version in a couple of minutes if you want to wait.

Yes, that would be nicer than me missing some reference and messing up everything :)

I think we have a winner:
http://code.google.com/r/limburgerite-dolphin-emu/source/detail?r=6c33ce20b2be7aa94e7152bfe016e2e9a3743fee&name=issue-6483

Comments should be a bit clearer now about what the fix is doing.

Would've done this sooner but Google Code seems to be having an episode at the moment.

This issue was closed by revision 649fd3d95b01.

This issue was closed by revision 649fd3d95b01.