This adds xfb support to the videosoftware backend, which increases it's
accuracy and more imporantly, enables the usage of many homebrew apps
which write directly to the xfb on the videosoftware backend.
Conflicts:
Source/Core/VideoBackends/Software/SWRenderer.cpp
Source/Core/VideoBackends/Software/SWmain.cpp
This fixes Real XFB Jaggies in OpenGL on games which use yscaling, such
as most PAL games.
This fixes the last of the "Real XFB Macroblocking" issues for opengl,
see issue #6503
Seems OpenGL ES 3 Requires you must have an lod argument, while Desktop
versions require you must not have a lod argument if you are using a
Sampler2DRect (which doesn't do Mipmapping).
The pal version of SSBB has a 640x568 xfb, which is larger than the efb.
Increase the size of the static textures and put in some runtime checks
to prevent buffer overruns.
* Don't force a frame to be progressive if it's already progressive.
* Don't assume the framebuffer will be 640 pixels wide
* Remember to offset the Luma channel by 16.
This commit fixes issues with PAL games which use the incorrect feild
ordering.
We move all code that deals with indivudal fields from the indivudal
video plugins and VideoCommon and make VideoInterface always pass in
the start address of the whole XFB into VideoCommon.
Massivly increases the accuracy of VideoSoftware, if it's going to be slow, it
might as well be accurate.
* Fixes flickering issues in games which double render to get Hardware AA, like the Peach's Castle tech demo.
* Rouge Squadren 2's Cantina Intro doesn't flicker anymore, but it duplicates the top half of the screen onto the bottom.
* Any games which need RealXFB support should now work in Video Software
They were named incorrectly in VideoInterface.h, but because nobody used
them outside of VideoInterface.cpp where they were decleared until now, this
hasn't been an issue.
Scott Mansell