It is mostly the texture shuffle effect which is now emulated correctly on openGL
They remain in the Dx level as speedhack in particular for
* Castlevania;
* GodOfWar;
* StarOcean3;
* ValkyrieProfile2;
* RadiataStories;
Remove old commented hack: Drakengard2, ArctheLad, ReZ
Separate hacks that are only enabled in aggressive mode
It might save a couple of fps
Add a define to test the perf if we keep only the blue channel. It brokes
the code in Prince Of Persia that use the Red/Green channel... Maybe the
speed hack :( Or find a way to replace all if with a lookup table
Note: it is only supported on OpenGL currently
Code unscale the texture to ease the conversion. Quality is awful (same as before)
but I'm not sure we can support an upscaled texture
Maybe the quality loss is due to the reduction without mipmap
Maybe the best solution will be to add an hack to extract the blue channel
(with texture swizzle), and uses a "full page/screen" spirte instead.
(it would be faster too)
Note: won't be compatible with MSAA (but gl doesn't support it anyway)
// In theory new textures contain invalidated data. Still in theory a new target
// must contains the content of the GS memory.
// In practice, TC will wrongly invalidate some RT. For example due to write on the alpha
// channel but colors is still valid. Unfortunately TC doesn't support the upload of data
// in target.
//
// Cleaning the code here will likely break several games. However it might reduce
// the noise in draw call debugging. It is the main reason to enable it on debug build.
//
// From a performance point of view, it might cost a little on big upscaling
// but normally few RT are miss so it must remain reasonable.
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
"Regression" introduced in 8 bits RT support
The case appears when
1/ address of RT is the same as input texture
2/ input format is 8 bits
3/ previous lookup of RT was miss
It avoid various upscaling glitches on GS post-processing effect
// 1/ Palette is used to interpret the alpha channel of the RT as an index.
// Star Ocean 3 uses it to emulate a stencil buffer.
// 2/ Z formats are a bad idea to interpolate (discontinuties).
// 3/ 16 bits buffer is used to move data from a channel to another.
//
// I keep linear filtering for standard color even if I'm not sure that it is
// working correctly.
// Indeed, texture is reduced so you need to read all covered pixels (9 in 3x)
// to correctly interpolate the value. Linear interpolation is likely acceptable
// only in 2x scaling
//
// Src texture will still be bilinear interpolated so I'm really not sure
// that we need to do it here too.
//
// Future note: instead to do
// RT 2048x2048 -> T 1024x1024 -> RT 2048x2048
// We can maybe sample directly a bigger texture
// RT 2048x2048 -> T 2048x2048 -> RT 2048x2048
// Pro: better quality. Copy instead of StretchRect (must be faster)
// Cons: consume more memory
//
// In distant future: investigate to reuse the RT directly without any
// copy. Likely a speed boost and memory usage reduction.
It might help to fix a bit the color on a couple of games
accurate_fbmask = 1
Code uses GL4.5 extensions. So far it seems the effect is ony used a couple
of time and often in non-overlapping primitive. Speed impact will likely remain small
It seems to impacts lots of games that still have issue (VP2, MTG3, PoP)
The PSMT32 format is read a PSMT8. I think we need to convert it as PSMT8H (i.e.
unpack it to have only an alpha channel)
To clear a (W, H) RT/Depth, GS can only send a (W , H/2) primitive with
a Z (or RT) pointer in the middle of the buffer
Top-half will be cleared by the color (or the depth).
Bottom-half will be cleared by the depth (or the color).
Code isn't enabled yet but it was tested with success on GoW2.
GS doesn't supports texture shuffle/swizzle so it is emulated in a
complex way.
The idea is to read/write the 32 bits color format as a 16 bit format.
This way, RG (16 lsb bits) or BA (16 msb bits) can be read or written with
square texture that targets pixels 1-8 or pixels 8-16.
However shuffle is limited. For example you can copy the green channel
to either the alpha channel or another green channel.
Note: Partial masking of channel is not yet implemented
V2: improve logging
V3: better support of green channel in shader
V4: improve detection of destination (issue due to rounding)
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
Rework the renderer selection logic to reload the saved renderer after
it's been changed in the config panel and to properly detect whether a
renderer toggle has been requested.
If settings found in the registry, create ini, fill with settings and
then delete the settings stored in the registry.
If no settings found in registry, load from ini.
Changed the name of the Direct3D renderers so they would match the way
they are named in GSdx's Plugin Settings window. Also changed a printf
to say OpenCL instead of opencl.
Just use 1 in skip draw if you want to use it
openGL code will soon be fixed to support depth correctly (and I hope dx in the future)
Conflicts:
plugins/GSdx/GSState.cpp
plugins/GSdx/GSState.h
Old way various check boxes to configure the plugin
New way an unified drop down list
* Level 0 (dev only) => disable (mostly) all hacks and auto skip depth.
* Level 1 (dev only ) => enable oi/oo/cu hacks, others remains disabled
* Level 2 (GL) => enable most hacks except a couple of one that were fixed on openGL (speed impact)
* Level 3 (DX) => enable all hacks
* Level 4 => enable also aggresive CRC
Note: windows gui must be updated, and it will be nice to create a global tooltip
Gregory: Get all changes but keep C11 code path which will be the future
(if someone can find info on Visual Studio support)
* Keep the old posix api to use address sanitizer on gcc 4.9
Conflicts:
common/build/Utilities/utilities.vcxproj.filters
common/build/Utilities/utilities_vs2012.vcxproj.filters
common/build/Utilities/utilities_vs2013.vcxproj.filters
common/include/Utilities/MemcpyFast.h
common/include/Utilities/StringHelpers.h
common/src/Utilities/AlignedMalloc.cpp
common/src/Utilities/vssprintf.cpp
plugins/GSdx/stdafx.cpp
-Last commit broke Snowblind games again
-Width now based on output circuit
-Try to use the smallest possible while being at least the size of the screen
The idea is to easily extract bad frame from gs dump and to compare them
with the sw renderer.
Here the summary of the options:
savet => dump all input textures
save => dump the render target
savez => dump the depth buffer
savef => dump the frame
The idea will be to replace StretchRect for standard case with a framebuffer
blit. Potentially it toggles less gl state.
Worth a test on Star Ocean 3 that uses a lots this function for stencil emulation
A user on http://obsrv.org had an issue with freezing, unfreezing than
dying on other players screen, but can continue playing anyway. This
comment didn't end up fixing the issue of becoming a ghost, but he
didn't freeze.
Please test it!
GS supports 3 formats for the output:
32 bits: normal case
=> no change
24 bits: like 32 bits but without alpha channel
=> mask alpha channel (ie don't write it anymore)
=> Always uses 1.0f as blending coefficient
16 bits: RGB5A1, emulated by a 32 bits openGL texture. I think it will be more correct to use
a real 16 bits GL texture. Unfortunately it would cost several (slow) target conversions.
Anyway as a current solution
=> apply a mask of 0xF8 on color when SW blending is used (improve Castlevania shadow)
unfortunately normal blending mode still uses the full range of colors!
This commit also corrects a couple of blending factor. 128/255 is equivalent to 1.0f in PS2, whereas GPU uses 1.0f. So the blending factor must be 255/128 instead of 2
Note: disable CRC hack and enable accurate_colclip to see Castlevania shadow ^^
(issue #380).
Note2: SW renderer is darker on Castlevania. I don't know why maybe linked to the 16 bits format poorly emulated
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.
The purpose of the code is to support alpha channel
of RT uses as an index for a palette texure.
I'm afraid that code will likely break pure palette texture. Only used
if paltex is enabled
It fixes missing shadow in Star Ocean 3 (issue #374) in Native resolution
with filter = 0 (no filtering) or = 2 (normal fitering)
Rendering explanation:
The game emulates a stencil buffer with the alpha channel
The alpha channel of the RT can contains a palette texture index (format 4HH)
The idea is to have a gradient of value in the palette (16/32/48/...).
This way you can implement a +16/-16 and even wrap the alpha value every time
you hit the pixel.
Bilinear filtering breaks the rendering because it interpolates between counts
so you doesn't have the exact count
Upscaling breaks the rendering because the RT is reused as an input texture. It means
that we need to scale it down which again create some interpolations.
Still not yet enabled by default
Potentially it can be optimized with the dot product but special care
need to be taken to ensure float accuracy.
Bonus: it could work on old GPU (aka DX9)
* Dump context before the increase of s_n
=> aligned with the global call number
* Don't print colclip not supported when it is optimized away
* dettach the input texture when it is useless
=> avoid to show a wrong texture in the debugger
This way it will allow to implement all blendings operartion in FS.
Of course it will be slow, but it would be nice for debug and quickly check
game error rendering.
Currently we're trying to infer the conversion shader based on the output format
It only works if the input data is RGBA8. It might not be true in the future
The idea was to merge them later with ffmpeg or other external tool
It kinds of work but current fps is around 2 !!! So not really usable
The speed issue is related to PNG.
So either the code to store pixels data must be optimized. Or maybe it misses some MT loves :)
Currently colclip uses 2 passes to wrap the output of blending unit
However some blending mode are only a plain copy (of 0 or Cs or Cd).
So no overflow of [0:255], no need to wrap it
Note: I saw those cases in GoW.
Gregory Hainaut