Move CRC hack to Partial that fix the half screen
bottom issue since the effect is not rendered correctly.
Move CRC hack to Aggressive. These hacks are only
needed when running upscaled resolution. They skip the
blur effect which cause ghosting and some other screen issues.
Side effect is they also remove the channel effect on OpenGL
which is emulated correctly so let's put them on Aggressive.
Comment out a hack, it's unknown what the hack does atm.
If there are new issues then it will be added back.
Added comments what the hacks do.
Partial port for channel shuffle effect to Direct3D for Tekken5.
The effect is skipped and not rendered but now the top left
screen glitch has been resolved.
Note: At least Minimum CRC level is required for this to work.
Adds merge sprite hack to GSDx hacks dialog
And ports merge sprite hack to Direct3D renderers.
Special thanks to my keyboards Ctrl, c and v buttons for all their hard
work in porting this hack.
Ports the "Unscale Point and Line" hack to the Direct3D11 Hardware renderer.
And enables the "Unscale Point and Line" hack for Custom Resolutions with Direct3D11 and OpenGL.
Alpha test should only be disabled when writes to all of the alpha bits in the Framebuffer are masked. Fixes a regression in Dragon Ball Z: Budokai 3 scouter image rendering.
Bilinear applies to all renderer
* Common code done in GSVertexTrace
* Extend it with forced but sprite (trade-off between linear/upscale glitches)
* Linux GUI option was moved at the top with the renderer selection
Trilinear is moved to OGL hack
close#1837
Thanks to Flatout for the review and feedback.
It will take care to update the Window GUI :)
mipmap option 3. Actually maybe a separate tri-linear option will be better
m_mipmap == 2 => use manual PS2 trilinear/mipmap
Otherwise
m_filter == 3 => always use full automatic trilinear interpolation
m_filter == 4 => use automatic trilinear interpolation when PS2 uses mipmap
m_filter == 5 => like 4 but force bilinear interpolation inside layer
WMS/WMT 2 is the region clamping mode.
Hw unit can't emulate it right so it can give you bad filtering (Fix#1025)
Note: I only did the fix because I wanted to remove the TEXA hack. Otherwise
it is still recommended to use openGL
It must work fine without it now.
From the google code comments:
It would be nice to test those games
* Ar Tonelico 2 (line in sprite regression?)
* breath of fire dragon quarter (overlayed user interface in the game)
v2: update Dx code to use the good format
* As sw renderer, don't bother to bypass it when it is ATST_ALWAYS
* Don't update the ATE register value
=> It is a really bad idea. Next draw call will be wrong if TEST register isn't written.
The TryAlphaTest context could have been updated
Gow uses 24 bits buffer, so only color is updated but blending is configured as Cd
so it is a NOP
In this case, we don't lookup the target in the texture cache. It reduces the complexity
to handle depth which can be located at same address as RT
Note: please test DX renderer
It is replacement of the previous hack (UserHacks_stretch_sprite). Don't enable both in the same time!
The idea of the hack is to move the sprite to the pixel boundary. It
avoids most of rounding issue. It also rescales verticaly the sprite (avoid horizontal line on ace combat).
I don't like this rescaling maybe we can limit it to only 1 pixels.
On my limited testcase, results are much better with any upscaling factor.
I still have a bad line in Kingdom heart. If you have issue with others
game please provide us a GS dump.
2x upscaling is pixel perfects. Bigger upscaling is better but not yet perfect
Feedbacks are welcomes (note it doesn't solve all upscaling issue, only wrong texture sampling)
For the history:
If you have a texture of [0;16[ texels and draws a primitive [0;16[
The formulae to sample last pixels of texture is
0.5 + (16*s-1)/(16*s) * 16
Native (s==1): 15.5 (good)
2x (s==2): 16 (bad, outside of the texture)
4x (s==4): 16.25 (bad, really outside of the texure))
- changed the KH2 fix in GetTextureMinMax to my taste, should give the same results, when the used texture rect is to the left/above the clamped area, it returns [min, min+1], and [max-1, max] for right/below
- m_mem.m_clut.Read32 was returned to its original place from GetAlphaMinMax
- UserHacks_WildHack was moved up to GSState, special UV handlers are only used when this setting is active
- updated xbyak to the latest available (avx2 seems incomplete, the 256-bit promoted old instructions are missing)
- changed vtune's include path to the 2013 edition
Some other not yet commited changes from a year ago:
- WriteImageX overflow crash-fix
- moved colclamp after dithering (sw mode), it makes more sense, no visible changes noticed
- Gif_Tag::analyzeTag(), there was a conditional I didn't like, split the loop into two parts
git-svn-id: http://pcsx2.googlecode.com/svn/trunk@5649 96395faa-99c1-11dd-bbfe-3dabce05a288
Now, a note about the actual issue. Destination alpha tests can be used on the GS as one of the workarounds for a lack of stencils. If you use a destination alpha test and leave alpha writing on, the GS will only write each pixel until you write an alpha value which would fail the test. This works to a point in gsdx without further hacking, but that point is when within a single batch of primitives the same pixels are written multiple times and the destination alpha test is expected to update. I did experimentally make a tight loop updating the stencil with a draw then drawing for one primitive at a time, but it was prohibitively slow (over 80% fps loss, you really don't want to know).
Destination alpha testing cannot be directly implemented in D3D9 or D3D10, but (probably) can in D3D11 (with a speed hit for sure, but I doubt it'll be 80%). I'll be getting a new graphics card and looking into that.
And before some idiot says it, the answer is no. OpenGL does not help.
git-svn-id: http://pcsx2.googlecode.com/svn/trunk@5346 96395faa-99c1-11dd-bbfe-3dabce05a288
This may make gsdx slightly slower for everyone (I don't know an easy way to restrict this to affected systems), especially if using 8-bit textures.
git-svn-id: http://pcsx2.googlecode.com/svn/trunk@5341 96395faa-99c1-11dd-bbfe-3dabce05a288
So, in the end I only properly understood the old code after finding all the problems with my version. I'm not sure whether any changes I've made are improvements any more, I'll need to review it with what I've learned in mind. This effort might've been a big waste of time.
git-svn-id: http://pcsx2.googlecode.com/svn/trunk@5329 96395faa-99c1-11dd-bbfe-3dabce05a288
Jonathan Li