Add HW Hack that enables Framebuffer Conversion on the CPU instead of the GPU.
Can fix broken textures on games but at the cost of slower performance.
List of games: Harry Potter games, FIFA Street games.
Games like Call of Duty, Kung fu Panda might also be affected as well as others
especially on Direct3D.
Add HW Hack GUI option on Windows/Linux for 4-bit and 8-bit Framebuffer conversion hack
named "Frame Buffer Conversion".
Using range loops where possible (correctly).
Using auto where possible (minimize code changes whenever it's decided to change back to a std container).
Use more efficient erase pattern (where possible).
Minor code tweaks.
The code is now a mirror of the ::add. So 1 insert == 1 erase
This way it won't crash on future update. And it will support future GS
memory wrapping improvement.
ZoE2:
RemoveAt overhead plummet to 0.5%. It was 17% !
However insertion is a bit slower. Due to the begin() after the push_front
v2: use std:: for lists and arrays
Previously the dedicated custom resolution scaling equation was ignored for the second SetScale() call, generalizing the equations will also fix the DMC scaling issue on custom resolution. Also remove unnecessary checks for null on scale factors. The possibility for having a null scale factor value only exists on custom resolution and it will only happen on cases where the output circuit isn't ready yet. So the ideal way would be to handle all the required conditions of output circuit on "m_renderer->CanUpscale()" itself.
GSOffset is already based on a lookup of PSM/BP/BW. Coverage only adds
the size parameters (so only 256 possibilities)
It replaces the hash lookup with a free array access.
The hypothesis is that game will use a depth (aka Z32/Z24/Z16/Z16S)
format when sampling depth texture as color. Technically one could use
a standard color format but block/pixel order won't be the same.
(otherwise I'm screwed)
=> Hypothesis invalid on GoW. They just do a scrambled rendering...
Lookup info:
* The first searched list is the depth pool as we search a depth
texture.
* 2nd one is the render target pool (if a depth was converted to a
render target already)
To avoid any CPU overhead, the source will be a pointer to the real texture
* Conversion (if float texture) will be done on the fly by the shader (GPU).
* Relative rescaling won't be supported. Texture must be fetched with
integral coordinate
Cache page coverage of texture into a hash map
Test done on Champion of Norrath (paltex + DisablePartialInvalidation)
Profiler:
Self of GSTextureCache::SourceMap::Add 5.39% => 0.23%
Self of GSTextureCache::LookupSource 15.27% => 10.82%
Hard to measure on CoN as it depends on memory transfer. Seem to be 5-10 fps faster.
It often happens the game try to upload the FMV directly which typically
gave a black screen.
Commit fix rules of roses and I hope various black screen FMV
Performance impact must be tested, and I'm afraid of strange texture cache behavior.
V2: check the size of the transfer too
V3: add support of 16 bits format
V4: avoid division by 0
It actually removes the previous hack that read the full target.
Unfortunately snowblind engine game uses big target so the read is very big too (1280x448)
which is killer for the perf. Whereas the game requires only 24x12 texels
Give a 2x speed boost on Champion of Norrath !!!
Games uses very special texture with a lots of repeating.
It is much faster to send the full texture rather than trying to partially invalidate it.
On my gs dump:
FPS: 29 => 68 !
* Greatly reduce the number of clut read (factor 10x)
* Avoid to get wrong TEXA texture in the cache.
* Fix "jump depends on uninitialized variable" Valgrind warning.
Fix#748
I try my best to avoid any breakage of DX but please test it too.
Game can directly uploads a background or the full image in
"CTRC" buffer. Previous code was a full black screen.
It will also avoid various black screen issue in gs dump.
hidden option: preload_frame_with_gs_data
Note: impact on upscaling was not tested and it's likely broken
Improve the rendering in MGS3 (even if the game is still broken
due to others TC issues)
// Typical bug (MGS3 blue cloud):
// 1/ RT used as 32 bits => alpha channel written
// 2/ RT used as 24 bits => no update of alpha channel
// 3/ Lookup of texture that used alpha channel as index, HasSharedBits will return false
// because of the previous draw call format
//
// Solution: consider the RT as 32 bits if the alpha was used in the past
When the RT is used as an input texture, we need to rescale it.
Previous behavior was to always uses a linear filtering (more smooth).
Unfortunately it broke some games that expected an exact value like Star Ocean 3
This commit will disable the linear filtering in normal filtering mode (filter = 0
or filter = 2)
This way, shadow of Star Ocean 3 will appear correctly in upscaling (not
100% perfect but can't do better)
Note: SO3 only requires a nearest sampling of the alpha channel but
I don't know the behavior for others games.
lightningterror