2015-05-24 04:55:12 +00:00
|
|
|
// Copyright 2014 Dolphin Emulator Project
|
2021-07-05 01:22:19 +00:00
|
|
|
// SPDX-License-Identifier: GPL-2.0-or-later
|
2014-07-29 16:47:56 +00:00
|
|
|
|
2019-07-17 00:18:48 +00:00
|
|
|
#include "VideoCommon/PostProcessing.h"
|
|
|
|
|
2016-01-17 21:54:31 +00:00
|
|
|
#include <sstream>
|
2014-07-29 16:47:56 +00:00
|
|
|
#include <string>
|
2019-07-08 11:35:53 +00:00
|
|
|
#include <string_view>
|
2014-07-29 16:47:56 +00:00
|
|
|
|
2019-11-22 22:10:41 +00:00
|
|
|
#include <fmt/format.h>
|
|
|
|
|
2019-02-15 01:59:50 +00:00
|
|
|
#include "Common/Assert.h"
|
2014-07-29 16:47:56 +00:00
|
|
|
#include "Common/CommonPaths.h"
|
2016-01-17 21:54:31 +00:00
|
|
|
#include "Common/CommonTypes.h"
|
2017-04-21 13:59:45 +00:00
|
|
|
#include "Common/FileSearch.h"
|
2014-07-29 16:47:56 +00:00
|
|
|
#include "Common/FileUtil.h"
|
|
|
|
#include "Common/IniFile.h"
|
2016-01-17 21:54:31 +00:00
|
|
|
#include "Common/Logging/Log.h"
|
2019-02-15 01:59:50 +00:00
|
|
|
#include "Common/MsgHandler.h"
|
2014-07-29 16:47:56 +00:00
|
|
|
#include "Common/StringUtil.h"
|
|
|
|
|
2019-02-15 01:59:50 +00:00
|
|
|
#include "VideoCommon/AbstractFramebuffer.h"
|
2023-01-26 22:34:59 +00:00
|
|
|
#include "VideoCommon/AbstractGfx.h"
|
2019-02-15 01:59:50 +00:00
|
|
|
#include "VideoCommon/AbstractPipeline.h"
|
|
|
|
#include "VideoCommon/AbstractShader.h"
|
|
|
|
#include "VideoCommon/AbstractTexture.h"
|
|
|
|
#include "VideoCommon/FramebufferManager.h"
|
2023-01-27 04:03:15 +00:00
|
|
|
#include "VideoCommon/Present.h"
|
2019-02-15 01:59:50 +00:00
|
|
|
#include "VideoCommon/ShaderCache.h"
|
|
|
|
#include "VideoCommon/VertexManagerBase.h"
|
2019-12-22 18:40:40 +00:00
|
|
|
#include "VideoCommon/VideoCommon.h"
|
2014-07-29 16:47:56 +00:00
|
|
|
#include "VideoCommon/VideoConfig.h"
|
|
|
|
|
2019-02-15 01:59:50 +00:00
|
|
|
namespace VideoCommon
|
2017-04-21 13:59:45 +00:00
|
|
|
{
|
Video: implement color correction to match the NTSC and PAL color spaces (and gamma) that GC and Wii targeted.
To further increase the accuracy of the post process phase, I've added (scRGB) HDR support, which is necessary
to fully display the PAL and NTSC-J color spaces, and also to improve the quality of post process texture samplings and
do them in linear space instead of gamma space (which is very important when playing at low resolutions).
For SDR, the quality is also slightly increased, at least if any post process runs, as the buffer is now
R10G10B10A2 (on Vulkan, DX11 and DX12) if supported; previously it was R8G8B8A8 but the alpha bits were wasted.
Gamma correction is arguably the most important thing as Dolphin on Windows outputted in "sRGB" (implicitly)
as that's what Windows expects by default, though sRGB gamma is very different from the gamma commonly used
by video standards dating to the pre HDR era (roughly gamma 2.35).
Additionally, the addition of HDR support (which is pretty straight forward and minimal), added support for
our own custom AutoHDR shaders, which would allow us to achieve decent looking HDR in Dolphin games without
having to use SpecialK or Windows 11 AutoHDR. Both of which don't necessarily play nice with older games
with strongly different and simpler lighting. HDR should also be supported in Linux.
Development of my own AutoHDR shader is almost complete and will come next.
This has been carefully tested and there should be no regression in any of the different features that Dolphin
offers, like multisampling, stereo rendering, other post processes, etc etc.
Fixes: https://bugs.dolphin-emu.org/issues/8941
Co-authored-by: EndlesslyFlowering <EndlesslyFlowering@protonmail.com>
Co-authored-by: Dogway <lin_ares@hotmail.com>
2023-06-10 08:48:05 +00:00
|
|
|
static const char s_empty_pixel_shader[] = "void main() { SetOutput(Sample()); }\n";
|
|
|
|
static const char s_default_pixel_shader_name[] = "default_pre_post_process";
|
|
|
|
// Keep the highest quality possible to avoid losing quality on subtle gamma conversions.
|
|
|
|
// RGBA16F should have enough quality even if we store colors in gamma space on it.
|
|
|
|
static const AbstractTextureFormat s_intermediary_buffer_format = AbstractTextureFormat::RGBA16F;
|
|
|
|
|
2023-12-11 22:07:56 +00:00
|
|
|
static bool LoadShaderFromFile(const std::string& shader, const std::string& sub_dir,
|
|
|
|
std::string& out_code)
|
Video: implement color correction to match the NTSC and PAL color spaces (and gamma) that GC and Wii targeted.
To further increase the accuracy of the post process phase, I've added (scRGB) HDR support, which is necessary
to fully display the PAL and NTSC-J color spaces, and also to improve the quality of post process texture samplings and
do them in linear space instead of gamma space (which is very important when playing at low resolutions).
For SDR, the quality is also slightly increased, at least if any post process runs, as the buffer is now
R10G10B10A2 (on Vulkan, DX11 and DX12) if supported; previously it was R8G8B8A8 but the alpha bits were wasted.
Gamma correction is arguably the most important thing as Dolphin on Windows outputted in "sRGB" (implicitly)
as that's what Windows expects by default, though sRGB gamma is very different from the gamma commonly used
by video standards dating to the pre HDR era (roughly gamma 2.35).
Additionally, the addition of HDR support (which is pretty straight forward and minimal), added support for
our own custom AutoHDR shaders, which would allow us to achieve decent looking HDR in Dolphin games without
having to use SpecialK or Windows 11 AutoHDR. Both of which don't necessarily play nice with older games
with strongly different and simpler lighting. HDR should also be supported in Linux.
Development of my own AutoHDR shader is almost complete and will come next.
This has been carefully tested and there should be no regression in any of the different features that Dolphin
offers, like multisampling, stereo rendering, other post processes, etc etc.
Fixes: https://bugs.dolphin-emu.org/issues/8941
Co-authored-by: EndlesslyFlowering <EndlesslyFlowering@protonmail.com>
Co-authored-by: Dogway <lin_ares@hotmail.com>
2023-06-10 08:48:05 +00:00
|
|
|
{
|
|
|
|
std::string path = File::GetUserPath(D_SHADERS_IDX) + sub_dir + shader + ".glsl";
|
|
|
|
|
|
|
|
if (!File::Exists(path))
|
|
|
|
{
|
|
|
|
// Fallback to shared user dir
|
|
|
|
path = File::GetSysDirectory() + SHADERS_DIR DIR_SEP + sub_dir + shader + ".glsl";
|
|
|
|
}
|
|
|
|
|
|
|
|
if (!File::ReadFileToString(path, out_code))
|
|
|
|
{
|
|
|
|
out_code = "";
|
|
|
|
ERROR_LOG_FMT(VIDEO, "Post-processing shader not found: {}", path);
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
|
|
|
return true;
|
|
|
|
}
|
2017-04-21 13:59:45 +00:00
|
|
|
|
2019-02-15 01:59:50 +00:00
|
|
|
PostProcessingConfiguration::PostProcessingConfiguration() = default;
|
2018-05-21 15:54:53 +00:00
|
|
|
|
2019-02-15 01:59:50 +00:00
|
|
|
PostProcessingConfiguration::~PostProcessingConfiguration() = default;
|
2018-05-21 15:54:53 +00:00
|
|
|
|
2019-02-15 01:59:50 +00:00
|
|
|
void PostProcessingConfiguration::LoadShader(const std::string& shader)
|
2014-07-29 16:47:56 +00:00
|
|
|
{
|
|
|
|
// Load the shader from the configuration if there isn't one sent to us.
|
|
|
|
m_current_shader = shader;
|
2019-02-15 01:59:50 +00:00
|
|
|
if (shader.empty())
|
|
|
|
{
|
|
|
|
LoadDefaultShader();
|
|
|
|
return;
|
|
|
|
}
|
2016-06-24 08:43:46 +00:00
|
|
|
|
2019-05-02 02:47:50 +00:00
|
|
|
std::string sub_dir = "";
|
|
|
|
|
|
|
|
if (g_Config.stereo_mode == StereoMode::Anaglyph)
|
|
|
|
{
|
|
|
|
sub_dir = ANAGLYPH_DIR DIR_SEP;
|
|
|
|
}
|
|
|
|
else if (g_Config.stereo_mode == StereoMode::Passive)
|
|
|
|
{
|
|
|
|
sub_dir = PASSIVE_DIR DIR_SEP;
|
|
|
|
}
|
2016-06-24 08:43:46 +00:00
|
|
|
|
2014-07-29 16:47:56 +00:00
|
|
|
std::string code;
|
Video: implement color correction to match the NTSC and PAL color spaces (and gamma) that GC and Wii targeted.
To further increase the accuracy of the post process phase, I've added (scRGB) HDR support, which is necessary
to fully display the PAL and NTSC-J color spaces, and also to improve the quality of post process texture samplings and
do them in linear space instead of gamma space (which is very important when playing at low resolutions).
For SDR, the quality is also slightly increased, at least if any post process runs, as the buffer is now
R10G10B10A2 (on Vulkan, DX11 and DX12) if supported; previously it was R8G8B8A8 but the alpha bits were wasted.
Gamma correction is arguably the most important thing as Dolphin on Windows outputted in "sRGB" (implicitly)
as that's what Windows expects by default, though sRGB gamma is very different from the gamma commonly used
by video standards dating to the pre HDR era (roughly gamma 2.35).
Additionally, the addition of HDR support (which is pretty straight forward and minimal), added support for
our own custom AutoHDR shaders, which would allow us to achieve decent looking HDR in Dolphin games without
having to use SpecialK or Windows 11 AutoHDR. Both of which don't necessarily play nice with older games
with strongly different and simpler lighting. HDR should also be supported in Linux.
Development of my own AutoHDR shader is almost complete and will come next.
This has been carefully tested and there should be no regression in any of the different features that Dolphin
offers, like multisampling, stereo rendering, other post processes, etc etc.
Fixes: https://bugs.dolphin-emu.org/issues/8941
Co-authored-by: EndlesslyFlowering <EndlesslyFlowering@protonmail.com>
Co-authored-by: Dogway <lin_ares@hotmail.com>
2023-06-10 08:48:05 +00:00
|
|
|
if (!LoadShaderFromFile(shader, sub_dir, code))
|
2014-07-29 16:47:56 +00:00
|
|
|
{
|
2019-02-15 01:59:50 +00:00
|
|
|
LoadDefaultShader();
|
|
|
|
return;
|
2014-07-29 16:47:56 +00:00
|
|
|
}
|
2016-06-24 08:43:46 +00:00
|
|
|
|
2014-07-29 16:47:56 +00:00
|
|
|
LoadOptions(code);
|
Video: implement color correction to match the NTSC and PAL color spaces (and gamma) that GC and Wii targeted.
To further increase the accuracy of the post process phase, I've added (scRGB) HDR support, which is necessary
to fully display the PAL and NTSC-J color spaces, and also to improve the quality of post process texture samplings and
do them in linear space instead of gamma space (which is very important when playing at low resolutions).
For SDR, the quality is also slightly increased, at least if any post process runs, as the buffer is now
R10G10B10A2 (on Vulkan, DX11 and DX12) if supported; previously it was R8G8B8A8 but the alpha bits were wasted.
Gamma correction is arguably the most important thing as Dolphin on Windows outputted in "sRGB" (implicitly)
as that's what Windows expects by default, though sRGB gamma is very different from the gamma commonly used
by video standards dating to the pre HDR era (roughly gamma 2.35).
Additionally, the addition of HDR support (which is pretty straight forward and minimal), added support for
our own custom AutoHDR shaders, which would allow us to achieve decent looking HDR in Dolphin games without
having to use SpecialK or Windows 11 AutoHDR. Both of which don't necessarily play nice with older games
with strongly different and simpler lighting. HDR should also be supported in Linux.
Development of my own AutoHDR shader is almost complete and will come next.
This has been carefully tested and there should be no regression in any of the different features that Dolphin
offers, like multisampling, stereo rendering, other post processes, etc etc.
Fixes: https://bugs.dolphin-emu.org/issues/8941
Co-authored-by: EndlesslyFlowering <EndlesslyFlowering@protonmail.com>
Co-authored-by: Dogway <lin_ares@hotmail.com>
2023-06-10 08:48:05 +00:00
|
|
|
// Note that this will build the shaders with the custom options values users
|
|
|
|
// might have set in the settings
|
2014-07-29 16:47:56 +00:00
|
|
|
LoadOptionsConfiguration();
|
2019-02-15 01:59:50 +00:00
|
|
|
m_current_shader_code = code;
|
|
|
|
}
|
2016-06-24 08:43:46 +00:00
|
|
|
|
2019-02-15 01:59:50 +00:00
|
|
|
void PostProcessingConfiguration::LoadDefaultShader()
|
|
|
|
{
|
|
|
|
m_options.clear();
|
|
|
|
m_any_options_dirty = false;
|
Video: implement color correction to match the NTSC and PAL color spaces (and gamma) that GC and Wii targeted.
To further increase the accuracy of the post process phase, I've added (scRGB) HDR support, which is necessary
to fully display the PAL and NTSC-J color spaces, and also to improve the quality of post process texture samplings and
do them in linear space instead of gamma space (which is very important when playing at low resolutions).
For SDR, the quality is also slightly increased, at least if any post process runs, as the buffer is now
R10G10B10A2 (on Vulkan, DX11 and DX12) if supported; previously it was R8G8B8A8 but the alpha bits were wasted.
Gamma correction is arguably the most important thing as Dolphin on Windows outputted in "sRGB" (implicitly)
as that's what Windows expects by default, though sRGB gamma is very different from the gamma commonly used
by video standards dating to the pre HDR era (roughly gamma 2.35).
Additionally, the addition of HDR support (which is pretty straight forward and minimal), added support for
our own custom AutoHDR shaders, which would allow us to achieve decent looking HDR in Dolphin games without
having to use SpecialK or Windows 11 AutoHDR. Both of which don't necessarily play nice with older games
with strongly different and simpler lighting. HDR should also be supported in Linux.
Development of my own AutoHDR shader is almost complete and will come next.
This has been carefully tested and there should be no regression in any of the different features that Dolphin
offers, like multisampling, stereo rendering, other post processes, etc etc.
Fixes: https://bugs.dolphin-emu.org/issues/8941
Co-authored-by: EndlesslyFlowering <EndlesslyFlowering@protonmail.com>
Co-authored-by: Dogway <lin_ares@hotmail.com>
2023-06-10 08:48:05 +00:00
|
|
|
m_current_shader = "";
|
|
|
|
m_current_shader_code = s_empty_pixel_shader;
|
2014-07-29 16:47:56 +00:00
|
|
|
}
|
|
|
|
|
2019-02-15 01:59:50 +00:00
|
|
|
void PostProcessingConfiguration::LoadOptions(const std::string& code)
|
2014-07-29 16:47:56 +00:00
|
|
|
{
|
|
|
|
const std::string config_start_delimiter = "[configuration]";
|
|
|
|
const std::string config_end_delimiter = "[/configuration]";
|
|
|
|
size_t configuration_start = code.find(config_start_delimiter);
|
|
|
|
size_t configuration_end = code.find(config_end_delimiter);
|
2016-06-24 08:43:46 +00:00
|
|
|
|
2014-07-29 16:47:56 +00:00
|
|
|
m_options.clear();
|
|
|
|
m_any_options_dirty = true;
|
2016-06-24 08:43:46 +00:00
|
|
|
|
2014-07-29 16:47:56 +00:00
|
|
|
if (configuration_start == std::string::npos || configuration_end == std::string::npos)
|
|
|
|
{
|
|
|
|
// Issue loading configuration or there isn't one.
|
|
|
|
return;
|
|
|
|
}
|
2016-06-24 08:43:46 +00:00
|
|
|
|
2014-07-29 16:47:56 +00:00
|
|
|
std::string configuration_string =
|
|
|
|
code.substr(configuration_start + config_start_delimiter.size(),
|
|
|
|
configuration_end - configuration_start - config_start_delimiter.size());
|
2016-06-24 08:43:46 +00:00
|
|
|
|
2014-07-29 16:47:56 +00:00
|
|
|
std::istringstream in(configuration_string);
|
2016-06-24 08:43:46 +00:00
|
|
|
|
2014-07-29 16:47:56 +00:00
|
|
|
struct GLSLStringOption
|
|
|
|
{
|
|
|
|
std::string m_type;
|
|
|
|
std::vector<std::pair<std::string, std::string>> m_options;
|
|
|
|
};
|
2016-06-24 08:43:46 +00:00
|
|
|
|
2014-07-29 16:47:56 +00:00
|
|
|
std::vector<GLSLStringOption> option_strings;
|
|
|
|
GLSLStringOption* current_strings = nullptr;
|
|
|
|
while (!in.eof())
|
|
|
|
{
|
2019-07-08 11:35:53 +00:00
|
|
|
std::string line_str;
|
|
|
|
if (std::getline(in, line_str))
|
2014-07-29 16:47:56 +00:00
|
|
|
{
|
2019-07-08 11:35:53 +00:00
|
|
|
std::string_view line = line_str;
|
|
|
|
|
2014-07-29 16:47:56 +00:00
|
|
|
#ifndef _WIN32
|
|
|
|
// Check for CRLF eol and convert it to LF
|
|
|
|
if (!line.empty() && line.at(line.size() - 1) == '\r')
|
2019-07-08 11:35:53 +00:00
|
|
|
line.remove_suffix(1);
|
2014-07-29 16:47:56 +00:00
|
|
|
#endif
|
|
|
|
|
2019-02-12 22:47:17 +00:00
|
|
|
if (!line.empty())
|
2014-07-29 16:47:56 +00:00
|
|
|
{
|
|
|
|
if (line[0] == '[')
|
|
|
|
{
|
|
|
|
size_t endpos = line.find("]");
|
2016-06-24 08:43:46 +00:00
|
|
|
|
2014-07-29 16:47:56 +00:00
|
|
|
if (endpos != std::string::npos)
|
|
|
|
{
|
|
|
|
// New section!
|
2019-07-08 11:35:53 +00:00
|
|
|
std::string_view sub = line.substr(1, endpos - 1);
|
|
|
|
option_strings.push_back({std::string(sub)});
|
2014-07-29 16:47:56 +00:00
|
|
|
current_strings = &option_strings.back();
|
|
|
|
}
|
|
|
|
}
|
|
|
|
else
|
|
|
|
{
|
|
|
|
if (current_strings)
|
|
|
|
{
|
|
|
|
std::string key, value;
|
2023-04-13 13:38:09 +00:00
|
|
|
Common::IniFile::ParseLine(line, &key, &value);
|
2016-06-24 08:43:46 +00:00
|
|
|
|
2019-02-12 22:47:17 +00:00
|
|
|
if (!(key.empty() && value.empty()))
|
2015-02-04 15:36:42 +00:00
|
|
|
current_strings->m_options.emplace_back(key, value);
|
2014-07-29 16:47:56 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
2016-06-24 08:43:46 +00:00
|
|
|
}
|
|
|
|
|
2014-07-29 16:47:56 +00:00
|
|
|
for (const auto& it : option_strings)
|
|
|
|
{
|
|
|
|
ConfigurationOption option;
|
|
|
|
option.m_dirty = true;
|
2016-06-24 08:43:46 +00:00
|
|
|
|
2014-07-29 16:47:56 +00:00
|
|
|
if (it.m_type == "OptionBool")
|
2022-02-17 17:54:07 +00:00
|
|
|
option.m_type = ConfigurationOption::OptionType::Bool;
|
2014-07-29 16:47:56 +00:00
|
|
|
else if (it.m_type == "OptionRangeFloat")
|
2022-02-17 17:54:07 +00:00
|
|
|
option.m_type = ConfigurationOption::OptionType::Float;
|
2014-07-29 16:47:56 +00:00
|
|
|
else if (it.m_type == "OptionRangeInteger")
|
2022-02-17 17:54:07 +00:00
|
|
|
option.m_type = ConfigurationOption::OptionType::Integer;
|
2016-06-24 08:43:46 +00:00
|
|
|
|
2014-07-29 16:47:56 +00:00
|
|
|
for (const auto& string_option : it.m_options)
|
|
|
|
{
|
|
|
|
if (string_option.first == "GUIName")
|
|
|
|
{
|
|
|
|
option.m_gui_name = string_option.second;
|
|
|
|
}
|
|
|
|
else if (string_option.first == "OptionName")
|
|
|
|
{
|
|
|
|
option.m_option_name = string_option.second;
|
|
|
|
}
|
|
|
|
else if (string_option.first == "DependentOption")
|
|
|
|
{
|
|
|
|
option.m_dependent_option = string_option.second;
|
|
|
|
}
|
|
|
|
else if (string_option.first == "MinValue" || string_option.first == "MaxValue" ||
|
|
|
|
string_option.first == "DefaultValue" || string_option.first == "StepAmount")
|
|
|
|
{
|
|
|
|
std::vector<s32>* output_integer = nullptr;
|
|
|
|
std::vector<float>* output_float = nullptr;
|
2016-06-24 08:43:46 +00:00
|
|
|
|
2014-07-29 16:47:56 +00:00
|
|
|
if (string_option.first == "MinValue")
|
|
|
|
{
|
|
|
|
output_integer = &option.m_integer_min_values;
|
|
|
|
output_float = &option.m_float_min_values;
|
|
|
|
}
|
|
|
|
else if (string_option.first == "MaxValue")
|
|
|
|
{
|
|
|
|
output_integer = &option.m_integer_max_values;
|
|
|
|
output_float = &option.m_float_max_values;
|
|
|
|
}
|
|
|
|
else if (string_option.first == "DefaultValue")
|
|
|
|
{
|
|
|
|
output_integer = &option.m_integer_values;
|
|
|
|
output_float = &option.m_float_values;
|
|
|
|
}
|
|
|
|
else if (string_option.first == "StepAmount")
|
|
|
|
{
|
|
|
|
output_integer = &option.m_integer_step_values;
|
|
|
|
output_float = &option.m_float_step_values;
|
|
|
|
}
|
2016-06-24 08:43:46 +00:00
|
|
|
|
2022-02-17 17:54:07 +00:00
|
|
|
if (option.m_type == ConfigurationOption::OptionType::Bool)
|
2014-07-29 16:47:56 +00:00
|
|
|
{
|
|
|
|
TryParse(string_option.second, &option.m_bool_value);
|
|
|
|
}
|
2022-02-17 17:54:07 +00:00
|
|
|
else if (option.m_type == ConfigurationOption::OptionType::Integer)
|
2014-07-29 16:47:56 +00:00
|
|
|
{
|
|
|
|
TryParseVector(string_option.second, output_integer);
|
|
|
|
if (output_integer->size() > 4)
|
|
|
|
output_integer->erase(output_integer->begin() + 4, output_integer->end());
|
|
|
|
}
|
2022-02-17 17:54:07 +00:00
|
|
|
else if (option.m_type == ConfigurationOption::OptionType::Float)
|
2014-07-29 16:47:56 +00:00
|
|
|
{
|
|
|
|
TryParseVector(string_option.second, output_float);
|
|
|
|
if (output_float->size() > 4)
|
|
|
|
output_float->erase(output_float->begin() + 4, output_float->end());
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
m_options[option.m_option_name] = option;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2019-02-15 01:59:50 +00:00
|
|
|
void PostProcessingConfiguration::LoadOptionsConfiguration()
|
2014-07-29 16:47:56 +00:00
|
|
|
{
|
2023-04-13 13:38:09 +00:00
|
|
|
Common::IniFile ini;
|
2014-07-29 16:47:56 +00:00
|
|
|
ini.Load(File::GetUserPath(F_DOLPHINCONFIG_IDX));
|
|
|
|
std::string section = m_current_shader + "-options";
|
2016-06-24 08:43:46 +00:00
|
|
|
|
Video: implement color correction to match the NTSC and PAL color spaces (and gamma) that GC and Wii targeted.
To further increase the accuracy of the post process phase, I've added (scRGB) HDR support, which is necessary
to fully display the PAL and NTSC-J color spaces, and also to improve the quality of post process texture samplings and
do them in linear space instead of gamma space (which is very important when playing at low resolutions).
For SDR, the quality is also slightly increased, at least if any post process runs, as the buffer is now
R10G10B10A2 (on Vulkan, DX11 and DX12) if supported; previously it was R8G8B8A8 but the alpha bits were wasted.
Gamma correction is arguably the most important thing as Dolphin on Windows outputted in "sRGB" (implicitly)
as that's what Windows expects by default, though sRGB gamma is very different from the gamma commonly used
by video standards dating to the pre HDR era (roughly gamma 2.35).
Additionally, the addition of HDR support (which is pretty straight forward and minimal), added support for
our own custom AutoHDR shaders, which would allow us to achieve decent looking HDR in Dolphin games without
having to use SpecialK or Windows 11 AutoHDR. Both of which don't necessarily play nice with older games
with strongly different and simpler lighting. HDR should also be supported in Linux.
Development of my own AutoHDR shader is almost complete and will come next.
This has been carefully tested and there should be no regression in any of the different features that Dolphin
offers, like multisampling, stereo rendering, other post processes, etc etc.
Fixes: https://bugs.dolphin-emu.org/issues/8941
Co-authored-by: EndlesslyFlowering <EndlesslyFlowering@protonmail.com>
Co-authored-by: Dogway <lin_ares@hotmail.com>
2023-06-10 08:48:05 +00:00
|
|
|
// We already expect all the options to be marked as "dirty" when we reach here
|
2014-07-29 16:47:56 +00:00
|
|
|
for (auto& it : m_options)
|
|
|
|
{
|
|
|
|
switch (it.second.m_type)
|
|
|
|
{
|
2022-02-17 17:54:07 +00:00
|
|
|
case ConfigurationOption::OptionType::Bool:
|
2014-07-29 16:47:56 +00:00
|
|
|
ini.GetOrCreateSection(section)->Get(it.second.m_option_name, &it.second.m_bool_value,
|
|
|
|
it.second.m_bool_value);
|
|
|
|
break;
|
2022-02-17 17:54:07 +00:00
|
|
|
case ConfigurationOption::OptionType::Integer:
|
2014-07-29 16:47:56 +00:00
|
|
|
{
|
|
|
|
std::string value;
|
|
|
|
ini.GetOrCreateSection(section)->Get(it.second.m_option_name, &value);
|
2019-02-12 22:47:17 +00:00
|
|
|
if (!value.empty())
|
2023-06-07 23:54:46 +00:00
|
|
|
{
|
|
|
|
auto integer_values = it.second.m_integer_values;
|
|
|
|
if (TryParseVector(value, &integer_values))
|
|
|
|
{
|
|
|
|
it.second.m_integer_values = integer_values;
|
|
|
|
}
|
|
|
|
}
|
2014-07-29 16:47:56 +00:00
|
|
|
}
|
|
|
|
break;
|
2022-02-17 17:54:07 +00:00
|
|
|
case ConfigurationOption::OptionType::Float:
|
2014-07-29 16:47:56 +00:00
|
|
|
{
|
|
|
|
std::string value;
|
|
|
|
ini.GetOrCreateSection(section)->Get(it.second.m_option_name, &value);
|
2019-02-12 22:47:17 +00:00
|
|
|
if (!value.empty())
|
2023-06-07 23:54:46 +00:00
|
|
|
{
|
|
|
|
auto float_values = it.second.m_float_values;
|
|
|
|
if (TryParseVector(value, &float_values))
|
|
|
|
{
|
|
|
|
it.second.m_float_values = float_values;
|
|
|
|
}
|
|
|
|
}
|
2014-07-29 16:47:56 +00:00
|
|
|
}
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2019-02-15 01:59:50 +00:00
|
|
|
void PostProcessingConfiguration::SaveOptionsConfiguration()
|
2014-07-29 16:47:56 +00:00
|
|
|
{
|
2023-04-13 13:38:09 +00:00
|
|
|
Common::IniFile ini;
|
2014-07-29 16:47:56 +00:00
|
|
|
ini.Load(File::GetUserPath(F_DOLPHINCONFIG_IDX));
|
|
|
|
std::string section = m_current_shader + "-options";
|
2016-06-24 08:43:46 +00:00
|
|
|
|
2014-07-29 16:47:56 +00:00
|
|
|
for (auto& it : m_options)
|
|
|
|
{
|
|
|
|
switch (it.second.m_type)
|
|
|
|
{
|
2022-02-17 17:54:07 +00:00
|
|
|
case ConfigurationOption::OptionType::Bool:
|
2014-07-29 16:47:56 +00:00
|
|
|
{
|
|
|
|
ini.GetOrCreateSection(section)->Set(it.second.m_option_name, it.second.m_bool_value);
|
|
|
|
}
|
|
|
|
break;
|
2022-02-17 17:54:07 +00:00
|
|
|
case ConfigurationOption::OptionType::Integer:
|
2014-07-29 16:47:56 +00:00
|
|
|
{
|
2019-03-02 18:42:25 +00:00
|
|
|
std::string value;
|
2014-07-29 16:47:56 +00:00
|
|
|
for (size_t i = 0; i < it.second.m_integer_values.size(); ++i)
|
2019-11-22 22:10:41 +00:00
|
|
|
{
|
|
|
|
value += fmt::format("{}{}", it.second.m_integer_values[i],
|
|
|
|
i == (it.second.m_integer_values.size() - 1) ? "" : ", ");
|
|
|
|
}
|
2014-07-29 16:47:56 +00:00
|
|
|
ini.GetOrCreateSection(section)->Set(it.second.m_option_name, value);
|
|
|
|
}
|
|
|
|
break;
|
2022-02-17 17:54:07 +00:00
|
|
|
case ConfigurationOption::OptionType::Float:
|
2014-07-29 16:47:56 +00:00
|
|
|
{
|
2015-01-20 22:40:46 +00:00
|
|
|
std::ostringstream value;
|
|
|
|
value.imbue(std::locale("C"));
|
2016-06-24 08:43:46 +00:00
|
|
|
|
2014-07-29 16:47:56 +00:00
|
|
|
for (size_t i = 0; i < it.second.m_float_values.size(); ++i)
|
2015-01-20 22:40:46 +00:00
|
|
|
{
|
|
|
|
value << it.second.m_float_values[i];
|
|
|
|
if (i != (it.second.m_float_values.size() - 1))
|
|
|
|
value << ", ";
|
|
|
|
}
|
|
|
|
ini.GetOrCreateSection(section)->Set(it.second.m_option_name, value.str());
|
2014-07-29 16:47:56 +00:00
|
|
|
}
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
ini.Save(File::GetUserPath(F_DOLPHINCONFIG_IDX));
|
|
|
|
}
|
|
|
|
|
2019-02-15 01:59:50 +00:00
|
|
|
void PostProcessingConfiguration::SetOptionf(const std::string& option, int index, float value)
|
2014-07-29 16:47:56 +00:00
|
|
|
{
|
|
|
|
auto it = m_options.find(option);
|
|
|
|
|
|
|
|
it->second.m_float_values[index] = value;
|
|
|
|
it->second.m_dirty = true;
|
|
|
|
m_any_options_dirty = true;
|
|
|
|
}
|
|
|
|
|
2019-02-15 01:59:50 +00:00
|
|
|
void PostProcessingConfiguration::SetOptioni(const std::string& option, int index, s32 value)
|
2014-07-29 16:47:56 +00:00
|
|
|
{
|
|
|
|
auto it = m_options.find(option);
|
|
|
|
|
|
|
|
it->second.m_integer_values[index] = value;
|
|
|
|
it->second.m_dirty = true;
|
|
|
|
m_any_options_dirty = true;
|
|
|
|
}
|
|
|
|
|
2019-02-15 01:59:50 +00:00
|
|
|
void PostProcessingConfiguration::SetOptionb(const std::string& option, bool value)
|
2014-07-29 16:47:56 +00:00
|
|
|
{
|
|
|
|
auto it = m_options.find(option);
|
|
|
|
|
|
|
|
it->second.m_bool_value = value;
|
|
|
|
it->second.m_dirty = true;
|
|
|
|
m_any_options_dirty = true;
|
|
|
|
}
|
2019-02-15 01:59:50 +00:00
|
|
|
|
|
|
|
PostProcessing::PostProcessing()
|
|
|
|
{
|
|
|
|
m_timer.Start();
|
|
|
|
}
|
|
|
|
|
|
|
|
PostProcessing::~PostProcessing()
|
|
|
|
{
|
|
|
|
m_timer.Stop();
|
|
|
|
}
|
|
|
|
|
|
|
|
static std::vector<std::string> GetShaders(const std::string& sub_dir = "")
|
|
|
|
{
|
|
|
|
std::vector<std::string> paths =
|
|
|
|
Common::DoFileSearch({File::GetUserPath(D_SHADERS_IDX) + sub_dir,
|
|
|
|
File::GetSysDirectory() + SHADERS_DIR DIR_SEP + sub_dir},
|
|
|
|
{".glsl"});
|
|
|
|
std::vector<std::string> result;
|
|
|
|
for (std::string path : paths)
|
|
|
|
{
|
|
|
|
std::string name;
|
|
|
|
SplitPath(path, nullptr, &name, nullptr);
|
Video: implement color correction to match the NTSC and PAL color spaces (and gamma) that GC and Wii targeted.
To further increase the accuracy of the post process phase, I've added (scRGB) HDR support, which is necessary
to fully display the PAL and NTSC-J color spaces, and also to improve the quality of post process texture samplings and
do them in linear space instead of gamma space (which is very important when playing at low resolutions).
For SDR, the quality is also slightly increased, at least if any post process runs, as the buffer is now
R10G10B10A2 (on Vulkan, DX11 and DX12) if supported; previously it was R8G8B8A8 but the alpha bits were wasted.
Gamma correction is arguably the most important thing as Dolphin on Windows outputted in "sRGB" (implicitly)
as that's what Windows expects by default, though sRGB gamma is very different from the gamma commonly used
by video standards dating to the pre HDR era (roughly gamma 2.35).
Additionally, the addition of HDR support (which is pretty straight forward and minimal), added support for
our own custom AutoHDR shaders, which would allow us to achieve decent looking HDR in Dolphin games without
having to use SpecialK or Windows 11 AutoHDR. Both of which don't necessarily play nice with older games
with strongly different and simpler lighting. HDR should also be supported in Linux.
Development of my own AutoHDR shader is almost complete and will come next.
This has been carefully tested and there should be no regression in any of the different features that Dolphin
offers, like multisampling, stereo rendering, other post processes, etc etc.
Fixes: https://bugs.dolphin-emu.org/issues/8941
Co-authored-by: EndlesslyFlowering <EndlesslyFlowering@protonmail.com>
Co-authored-by: Dogway <lin_ares@hotmail.com>
2023-06-10 08:48:05 +00:00
|
|
|
if (name == s_default_pixel_shader_name)
|
|
|
|
continue;
|
2019-02-15 01:59:50 +00:00
|
|
|
result.push_back(name);
|
|
|
|
}
|
|
|
|
return result;
|
|
|
|
}
|
|
|
|
|
|
|
|
std::vector<std::string> PostProcessing::GetShaderList()
|
|
|
|
{
|
|
|
|
return GetShaders();
|
|
|
|
}
|
|
|
|
|
|
|
|
std::vector<std::string> PostProcessing::GetAnaglyphShaderList()
|
|
|
|
{
|
|
|
|
return GetShaders(ANAGLYPH_DIR DIR_SEP);
|
|
|
|
}
|
|
|
|
|
2019-05-02 02:47:50 +00:00
|
|
|
std::vector<std::string> PostProcessing::GetPassiveShaderList()
|
|
|
|
{
|
|
|
|
return GetShaders(PASSIVE_DIR DIR_SEP);
|
|
|
|
}
|
|
|
|
|
2019-02-15 01:59:50 +00:00
|
|
|
bool PostProcessing::Initialize(AbstractTextureFormat format)
|
|
|
|
{
|
|
|
|
m_framebuffer_format = format;
|
2023-08-06 00:11:19 +00:00
|
|
|
// CompilePixelShader() must be run first if configuration options are used.
|
2021-07-07 19:26:46 +00:00
|
|
|
// Otherwise the UBO has a different member list between vertex and pixel
|
2023-08-06 00:11:19 +00:00
|
|
|
// shaders, which is a link error on some backends.
|
2021-07-07 19:26:46 +00:00
|
|
|
if (!CompilePixelShader() || !CompileVertexShader() || !CompilePipeline())
|
2019-02-15 01:59:50 +00:00
|
|
|
return false;
|
|
|
|
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
|
|
|
void PostProcessing::RecompileShader()
|
|
|
|
{
|
Video: implement color correction to match the NTSC and PAL color spaces (and gamma) that GC and Wii targeted.
To further increase the accuracy of the post process phase, I've added (scRGB) HDR support, which is necessary
to fully display the PAL and NTSC-J color spaces, and also to improve the quality of post process texture samplings and
do them in linear space instead of gamma space (which is very important when playing at low resolutions).
For SDR, the quality is also slightly increased, at least if any post process runs, as the buffer is now
R10G10B10A2 (on Vulkan, DX11 and DX12) if supported; previously it was R8G8B8A8 but the alpha bits were wasted.
Gamma correction is arguably the most important thing as Dolphin on Windows outputted in "sRGB" (implicitly)
as that's what Windows expects by default, though sRGB gamma is very different from the gamma commonly used
by video standards dating to the pre HDR era (roughly gamma 2.35).
Additionally, the addition of HDR support (which is pretty straight forward and minimal), added support for
our own custom AutoHDR shaders, which would allow us to achieve decent looking HDR in Dolphin games without
having to use SpecialK or Windows 11 AutoHDR. Both of which don't necessarily play nice with older games
with strongly different and simpler lighting. HDR should also be supported in Linux.
Development of my own AutoHDR shader is almost complete and will come next.
This has been carefully tested and there should be no regression in any of the different features that Dolphin
offers, like multisampling, stereo rendering, other post processes, etc etc.
Fixes: https://bugs.dolphin-emu.org/issues/8941
Co-authored-by: EndlesslyFlowering <EndlesslyFlowering@protonmail.com>
Co-authored-by: Dogway <lin_ares@hotmail.com>
2023-06-10 08:48:05 +00:00
|
|
|
// Note: for simplicity we already recompile all the shaders
|
|
|
|
// and pipelines even if there might not be need to.
|
|
|
|
|
|
|
|
m_default_pipeline.reset();
|
2019-02-15 01:59:50 +00:00
|
|
|
m_pipeline.reset();
|
Video: implement color correction to match the NTSC and PAL color spaces (and gamma) that GC and Wii targeted.
To further increase the accuracy of the post process phase, I've added (scRGB) HDR support, which is necessary
to fully display the PAL and NTSC-J color spaces, and also to improve the quality of post process texture samplings and
do them in linear space instead of gamma space (which is very important when playing at low resolutions).
For SDR, the quality is also slightly increased, at least if any post process runs, as the buffer is now
R10G10B10A2 (on Vulkan, DX11 and DX12) if supported; previously it was R8G8B8A8 but the alpha bits were wasted.
Gamma correction is arguably the most important thing as Dolphin on Windows outputted in "sRGB" (implicitly)
as that's what Windows expects by default, though sRGB gamma is very different from the gamma commonly used
by video standards dating to the pre HDR era (roughly gamma 2.35).
Additionally, the addition of HDR support (which is pretty straight forward and minimal), added support for
our own custom AutoHDR shaders, which would allow us to achieve decent looking HDR in Dolphin games without
having to use SpecialK or Windows 11 AutoHDR. Both of which don't necessarily play nice with older games
with strongly different and simpler lighting. HDR should also be supported in Linux.
Development of my own AutoHDR shader is almost complete and will come next.
This has been carefully tested and there should be no regression in any of the different features that Dolphin
offers, like multisampling, stereo rendering, other post processes, etc etc.
Fixes: https://bugs.dolphin-emu.org/issues/8941
Co-authored-by: EndlesslyFlowering <EndlesslyFlowering@protonmail.com>
Co-authored-by: Dogway <lin_ares@hotmail.com>
2023-06-10 08:48:05 +00:00
|
|
|
m_default_pixel_shader.reset();
|
2019-02-15 01:59:50 +00:00
|
|
|
m_pixel_shader.reset();
|
Video: implement color correction to match the NTSC and PAL color spaces (and gamma) that GC and Wii targeted.
To further increase the accuracy of the post process phase, I've added (scRGB) HDR support, which is necessary
to fully display the PAL and NTSC-J color spaces, and also to improve the quality of post process texture samplings and
do them in linear space instead of gamma space (which is very important when playing at low resolutions).
For SDR, the quality is also slightly increased, at least if any post process runs, as the buffer is now
R10G10B10A2 (on Vulkan, DX11 and DX12) if supported; previously it was R8G8B8A8 but the alpha bits were wasted.
Gamma correction is arguably the most important thing as Dolphin on Windows outputted in "sRGB" (implicitly)
as that's what Windows expects by default, though sRGB gamma is very different from the gamma commonly used
by video standards dating to the pre HDR era (roughly gamma 2.35).
Additionally, the addition of HDR support (which is pretty straight forward and minimal), added support for
our own custom AutoHDR shaders, which would allow us to achieve decent looking HDR in Dolphin games without
having to use SpecialK or Windows 11 AutoHDR. Both of which don't necessarily play nice with older games
with strongly different and simpler lighting. HDR should also be supported in Linux.
Development of my own AutoHDR shader is almost complete and will come next.
This has been carefully tested and there should be no regression in any of the different features that Dolphin
offers, like multisampling, stereo rendering, other post processes, etc etc.
Fixes: https://bugs.dolphin-emu.org/issues/8941
Co-authored-by: EndlesslyFlowering <EndlesslyFlowering@protonmail.com>
Co-authored-by: Dogway <lin_ares@hotmail.com>
2023-06-10 08:48:05 +00:00
|
|
|
m_default_vertex_shader.reset();
|
|
|
|
m_vertex_shader.reset();
|
2019-02-15 01:59:50 +00:00
|
|
|
if (!CompilePixelShader())
|
|
|
|
return;
|
2021-07-18 03:03:26 +00:00
|
|
|
if (!CompileVertexShader())
|
|
|
|
return;
|
2019-02-15 01:59:50 +00:00
|
|
|
|
|
|
|
CompilePipeline();
|
|
|
|
}
|
|
|
|
|
|
|
|
void PostProcessing::RecompilePipeline()
|
|
|
|
{
|
Video: implement color correction to match the NTSC and PAL color spaces (and gamma) that GC and Wii targeted.
To further increase the accuracy of the post process phase, I've added (scRGB) HDR support, which is necessary
to fully display the PAL and NTSC-J color spaces, and also to improve the quality of post process texture samplings and
do them in linear space instead of gamma space (which is very important when playing at low resolutions).
For SDR, the quality is also slightly increased, at least if any post process runs, as the buffer is now
R10G10B10A2 (on Vulkan, DX11 and DX12) if supported; previously it was R8G8B8A8 but the alpha bits were wasted.
Gamma correction is arguably the most important thing as Dolphin on Windows outputted in "sRGB" (implicitly)
as that's what Windows expects by default, though sRGB gamma is very different from the gamma commonly used
by video standards dating to the pre HDR era (roughly gamma 2.35).
Additionally, the addition of HDR support (which is pretty straight forward and minimal), added support for
our own custom AutoHDR shaders, which would allow us to achieve decent looking HDR in Dolphin games without
having to use SpecialK or Windows 11 AutoHDR. Both of which don't necessarily play nice with older games
with strongly different and simpler lighting. HDR should also be supported in Linux.
Development of my own AutoHDR shader is almost complete and will come next.
This has been carefully tested and there should be no regression in any of the different features that Dolphin
offers, like multisampling, stereo rendering, other post processes, etc etc.
Fixes: https://bugs.dolphin-emu.org/issues/8941
Co-authored-by: EndlesslyFlowering <EndlesslyFlowering@protonmail.com>
Co-authored-by: Dogway <lin_ares@hotmail.com>
2023-06-10 08:48:05 +00:00
|
|
|
m_default_pipeline.reset();
|
2019-02-15 01:59:50 +00:00
|
|
|
m_pipeline.reset();
|
|
|
|
CompilePipeline();
|
|
|
|
}
|
|
|
|
|
Video: implement color correction to match the NTSC and PAL color spaces (and gamma) that GC and Wii targeted.
To further increase the accuracy of the post process phase, I've added (scRGB) HDR support, which is necessary
to fully display the PAL and NTSC-J color spaces, and also to improve the quality of post process texture samplings and
do them in linear space instead of gamma space (which is very important when playing at low resolutions).
For SDR, the quality is also slightly increased, at least if any post process runs, as the buffer is now
R10G10B10A2 (on Vulkan, DX11 and DX12) if supported; previously it was R8G8B8A8 but the alpha bits were wasted.
Gamma correction is arguably the most important thing as Dolphin on Windows outputted in "sRGB" (implicitly)
as that's what Windows expects by default, though sRGB gamma is very different from the gamma commonly used
by video standards dating to the pre HDR era (roughly gamma 2.35).
Additionally, the addition of HDR support (which is pretty straight forward and minimal), added support for
our own custom AutoHDR shaders, which would allow us to achieve decent looking HDR in Dolphin games without
having to use SpecialK or Windows 11 AutoHDR. Both of which don't necessarily play nice with older games
with strongly different and simpler lighting. HDR should also be supported in Linux.
Development of my own AutoHDR shader is almost complete and will come next.
This has been carefully tested and there should be no regression in any of the different features that Dolphin
offers, like multisampling, stereo rendering, other post processes, etc etc.
Fixes: https://bugs.dolphin-emu.org/issues/8941
Co-authored-by: EndlesslyFlowering <EndlesslyFlowering@protonmail.com>
Co-authored-by: Dogway <lin_ares@hotmail.com>
2023-06-10 08:48:05 +00:00
|
|
|
bool PostProcessing::IsColorCorrectionActive() const
|
|
|
|
{
|
|
|
|
// We can skip the color correction pass if none of these settings are on
|
|
|
|
// (it might have still helped with gamma correct sampling, but it's not worth running it).
|
|
|
|
return g_ActiveConfig.color_correction.bCorrectColorSpace ||
|
|
|
|
g_ActiveConfig.color_correction.bCorrectGamma ||
|
|
|
|
m_framebuffer_format == AbstractTextureFormat::RGBA16F;
|
|
|
|
}
|
|
|
|
|
|
|
|
bool PostProcessing::NeedsIntermediaryBuffer() const
|
|
|
|
{
|
|
|
|
// If we have no user selected post process shader,
|
|
|
|
// there's no point in having an intermediary buffer doing nothing.
|
|
|
|
return !m_config.GetShader().empty();
|
|
|
|
}
|
|
|
|
|
2019-02-15 01:59:50 +00:00
|
|
|
void PostProcessing::BlitFromTexture(const MathUtil::Rectangle<int>& dst,
|
|
|
|
const MathUtil::Rectangle<int>& src,
|
|
|
|
const AbstractTexture* src_tex, int src_layer)
|
|
|
|
{
|
2023-01-26 22:34:59 +00:00
|
|
|
if (g_gfx->GetCurrentFramebuffer()->GetColorFormat() != m_framebuffer_format)
|
2019-02-15 01:59:50 +00:00
|
|
|
{
|
2023-01-26 22:34:59 +00:00
|
|
|
m_framebuffer_format = g_gfx->GetCurrentFramebuffer()->GetColorFormat();
|
2019-02-15 01:59:50 +00:00
|
|
|
RecompilePipeline();
|
|
|
|
}
|
|
|
|
|
Video: implement color correction to match the NTSC and PAL color spaces (and gamma) that GC and Wii targeted.
To further increase the accuracy of the post process phase, I've added (scRGB) HDR support, which is necessary
to fully display the PAL and NTSC-J color spaces, and also to improve the quality of post process texture samplings and
do them in linear space instead of gamma space (which is very important when playing at low resolutions).
For SDR, the quality is also slightly increased, at least if any post process runs, as the buffer is now
R10G10B10A2 (on Vulkan, DX11 and DX12) if supported; previously it was R8G8B8A8 but the alpha bits were wasted.
Gamma correction is arguably the most important thing as Dolphin on Windows outputted in "sRGB" (implicitly)
as that's what Windows expects by default, though sRGB gamma is very different from the gamma commonly used
by video standards dating to the pre HDR era (roughly gamma 2.35).
Additionally, the addition of HDR support (which is pretty straight forward and minimal), added support for
our own custom AutoHDR shaders, which would allow us to achieve decent looking HDR in Dolphin games without
having to use SpecialK or Windows 11 AutoHDR. Both of which don't necessarily play nice with older games
with strongly different and simpler lighting. HDR should also be supported in Linux.
Development of my own AutoHDR shader is almost complete and will come next.
This has been carefully tested and there should be no regression in any of the different features that Dolphin
offers, like multisampling, stereo rendering, other post processes, etc etc.
Fixes: https://bugs.dolphin-emu.org/issues/8941
Co-authored-by: EndlesslyFlowering <EndlesslyFlowering@protonmail.com>
Co-authored-by: Dogway <lin_ares@hotmail.com>
2023-06-10 08:48:05 +00:00
|
|
|
// By default all source layers will be copied into the respective target layers
|
|
|
|
const bool copy_all_layers = src_layer < 0;
|
|
|
|
src_layer = std::max(src_layer, 0);
|
2019-02-15 01:59:50 +00:00
|
|
|
|
Video: implement color correction to match the NTSC and PAL color spaces (and gamma) that GC and Wii targeted.
To further increase the accuracy of the post process phase, I've added (scRGB) HDR support, which is necessary
to fully display the PAL and NTSC-J color spaces, and also to improve the quality of post process texture samplings and
do them in linear space instead of gamma space (which is very important when playing at low resolutions).
For SDR, the quality is also slightly increased, at least if any post process runs, as the buffer is now
R10G10B10A2 (on Vulkan, DX11 and DX12) if supported; previously it was R8G8B8A8 but the alpha bits were wasted.
Gamma correction is arguably the most important thing as Dolphin on Windows outputted in "sRGB" (implicitly)
as that's what Windows expects by default, though sRGB gamma is very different from the gamma commonly used
by video standards dating to the pre HDR era (roughly gamma 2.35).
Additionally, the addition of HDR support (which is pretty straight forward and minimal), added support for
our own custom AutoHDR shaders, which would allow us to achieve decent looking HDR in Dolphin games without
having to use SpecialK or Windows 11 AutoHDR. Both of which don't necessarily play nice with older games
with strongly different and simpler lighting. HDR should also be supported in Linux.
Development of my own AutoHDR shader is almost complete and will come next.
This has been carefully tested and there should be no regression in any of the different features that Dolphin
offers, like multisampling, stereo rendering, other post processes, etc etc.
Fixes: https://bugs.dolphin-emu.org/issues/8941
Co-authored-by: EndlesslyFlowering <EndlesslyFlowering@protonmail.com>
Co-authored-by: Dogway <lin_ares@hotmail.com>
2023-06-10 08:48:05 +00:00
|
|
|
MathUtil::Rectangle<int> src_rect = src;
|
2023-01-26 22:34:59 +00:00
|
|
|
g_gfx->SetSamplerState(0, RenderState::GetLinearSamplerState());
|
2023-06-27 00:23:08 +00:00
|
|
|
g_gfx->SetSamplerState(1, RenderState::GetPointSamplerState());
|
Video: implement color correction to match the NTSC and PAL color spaces (and gamma) that GC and Wii targeted.
To further increase the accuracy of the post process phase, I've added (scRGB) HDR support, which is necessary
to fully display the PAL and NTSC-J color spaces, and also to improve the quality of post process texture samplings and
do them in linear space instead of gamma space (which is very important when playing at low resolutions).
For SDR, the quality is also slightly increased, at least if any post process runs, as the buffer is now
R10G10B10A2 (on Vulkan, DX11 and DX12) if supported; previously it was R8G8B8A8 but the alpha bits were wasted.
Gamma correction is arguably the most important thing as Dolphin on Windows outputted in "sRGB" (implicitly)
as that's what Windows expects by default, though sRGB gamma is very different from the gamma commonly used
by video standards dating to the pre HDR era (roughly gamma 2.35).
Additionally, the addition of HDR support (which is pretty straight forward and minimal), added support for
our own custom AutoHDR shaders, which would allow us to achieve decent looking HDR in Dolphin games without
having to use SpecialK or Windows 11 AutoHDR. Both of which don't necessarily play nice with older games
with strongly different and simpler lighting. HDR should also be supported in Linux.
Development of my own AutoHDR shader is almost complete and will come next.
This has been carefully tested and there should be no regression in any of the different features that Dolphin
offers, like multisampling, stereo rendering, other post processes, etc etc.
Fixes: https://bugs.dolphin-emu.org/issues/8941
Co-authored-by: EndlesslyFlowering <EndlesslyFlowering@protonmail.com>
Co-authored-by: Dogway <lin_ares@hotmail.com>
2023-06-10 08:48:05 +00:00
|
|
|
g_gfx->SetTexture(0, src_tex);
|
2023-06-27 00:23:08 +00:00
|
|
|
g_gfx->SetTexture(1, src_tex);
|
Video: implement color correction to match the NTSC and PAL color spaces (and gamma) that GC and Wii targeted.
To further increase the accuracy of the post process phase, I've added (scRGB) HDR support, which is necessary
to fully display the PAL and NTSC-J color spaces, and also to improve the quality of post process texture samplings and
do them in linear space instead of gamma space (which is very important when playing at low resolutions).
For SDR, the quality is also slightly increased, at least if any post process runs, as the buffer is now
R10G10B10A2 (on Vulkan, DX11 and DX12) if supported; previously it was R8G8B8A8 but the alpha bits were wasted.
Gamma correction is arguably the most important thing as Dolphin on Windows outputted in "sRGB" (implicitly)
as that's what Windows expects by default, though sRGB gamma is very different from the gamma commonly used
by video standards dating to the pre HDR era (roughly gamma 2.35).
Additionally, the addition of HDR support (which is pretty straight forward and minimal), added support for
our own custom AutoHDR shaders, which would allow us to achieve decent looking HDR in Dolphin games without
having to use SpecialK or Windows 11 AutoHDR. Both of which don't necessarily play nice with older games
with strongly different and simpler lighting. HDR should also be supported in Linux.
Development of my own AutoHDR shader is almost complete and will come next.
This has been carefully tested and there should be no regression in any of the different features that Dolphin
offers, like multisampling, stereo rendering, other post processes, etc etc.
Fixes: https://bugs.dolphin-emu.org/issues/8941
Co-authored-by: EndlesslyFlowering <EndlesslyFlowering@protonmail.com>
Co-authored-by: Dogway <lin_ares@hotmail.com>
2023-06-10 08:48:05 +00:00
|
|
|
|
2023-06-27 00:23:08 +00:00
|
|
|
const bool needs_color_correction = IsColorCorrectionActive();
|
|
|
|
// Rely on the default (bi)linear sampler with the default mode
|
|
|
|
// (it might not be gamma corrected).
|
|
|
|
const bool needs_resampling =
|
|
|
|
g_ActiveConfig.output_resampling_mode > OutputResamplingMode::Default;
|
Video: implement color correction to match the NTSC and PAL color spaces (and gamma) that GC and Wii targeted.
To further increase the accuracy of the post process phase, I've added (scRGB) HDR support, which is necessary
to fully display the PAL and NTSC-J color spaces, and also to improve the quality of post process texture samplings and
do them in linear space instead of gamma space (which is very important when playing at low resolutions).
For SDR, the quality is also slightly increased, at least if any post process runs, as the buffer is now
R10G10B10A2 (on Vulkan, DX11 and DX12) if supported; previously it was R8G8B8A8 but the alpha bits were wasted.
Gamma correction is arguably the most important thing as Dolphin on Windows outputted in "sRGB" (implicitly)
as that's what Windows expects by default, though sRGB gamma is very different from the gamma commonly used
by video standards dating to the pre HDR era (roughly gamma 2.35).
Additionally, the addition of HDR support (which is pretty straight forward and minimal), added support for
our own custom AutoHDR shaders, which would allow us to achieve decent looking HDR in Dolphin games without
having to use SpecialK or Windows 11 AutoHDR. Both of which don't necessarily play nice with older games
with strongly different and simpler lighting. HDR should also be supported in Linux.
Development of my own AutoHDR shader is almost complete and will come next.
This has been carefully tested and there should be no regression in any of the different features that Dolphin
offers, like multisampling, stereo rendering, other post processes, etc etc.
Fixes: https://bugs.dolphin-emu.org/issues/8941
Co-authored-by: EndlesslyFlowering <EndlesslyFlowering@protonmail.com>
Co-authored-by: Dogway <lin_ares@hotmail.com>
2023-06-10 08:48:05 +00:00
|
|
|
const bool needs_intermediary_buffer = NeedsIntermediaryBuffer();
|
2023-06-27 00:23:08 +00:00
|
|
|
const bool needs_default_pipeline = needs_color_correction || needs_resampling;
|
Video: implement color correction to match the NTSC and PAL color spaces (and gamma) that GC and Wii targeted.
To further increase the accuracy of the post process phase, I've added (scRGB) HDR support, which is necessary
to fully display the PAL and NTSC-J color spaces, and also to improve the quality of post process texture samplings and
do them in linear space instead of gamma space (which is very important when playing at low resolutions).
For SDR, the quality is also slightly increased, at least if any post process runs, as the buffer is now
R10G10B10A2 (on Vulkan, DX11 and DX12) if supported; previously it was R8G8B8A8 but the alpha bits were wasted.
Gamma correction is arguably the most important thing as Dolphin on Windows outputted in "sRGB" (implicitly)
as that's what Windows expects by default, though sRGB gamma is very different from the gamma commonly used
by video standards dating to the pre HDR era (roughly gamma 2.35).
Additionally, the addition of HDR support (which is pretty straight forward and minimal), added support for
our own custom AutoHDR shaders, which would allow us to achieve decent looking HDR in Dolphin games without
having to use SpecialK or Windows 11 AutoHDR. Both of which don't necessarily play nice with older games
with strongly different and simpler lighting. HDR should also be supported in Linux.
Development of my own AutoHDR shader is almost complete and will come next.
This has been carefully tested and there should be no regression in any of the different features that Dolphin
offers, like multisampling, stereo rendering, other post processes, etc etc.
Fixes: https://bugs.dolphin-emu.org/issues/8941
Co-authored-by: EndlesslyFlowering <EndlesslyFlowering@protonmail.com>
Co-authored-by: Dogway <lin_ares@hotmail.com>
2023-06-10 08:48:05 +00:00
|
|
|
const AbstractPipeline* final_pipeline = m_pipeline.get();
|
|
|
|
std::vector<u8>* uniform_staging_buffer = &m_default_uniform_staging_buffer;
|
|
|
|
bool default_uniform_staging_buffer = true;
|
2023-06-27 00:23:08 +00:00
|
|
|
const MathUtil::Rectangle<int> present_rect = g_presenter->GetTargetRectangle();
|
Video: implement color correction to match the NTSC and PAL color spaces (and gamma) that GC and Wii targeted.
To further increase the accuracy of the post process phase, I've added (scRGB) HDR support, which is necessary
to fully display the PAL and NTSC-J color spaces, and also to improve the quality of post process texture samplings and
do them in linear space instead of gamma space (which is very important when playing at low resolutions).
For SDR, the quality is also slightly increased, at least if any post process runs, as the buffer is now
R10G10B10A2 (on Vulkan, DX11 and DX12) if supported; previously it was R8G8B8A8 but the alpha bits were wasted.
Gamma correction is arguably the most important thing as Dolphin on Windows outputted in "sRGB" (implicitly)
as that's what Windows expects by default, though sRGB gamma is very different from the gamma commonly used
by video standards dating to the pre HDR era (roughly gamma 2.35).
Additionally, the addition of HDR support (which is pretty straight forward and minimal), added support for
our own custom AutoHDR shaders, which would allow us to achieve decent looking HDR in Dolphin games without
having to use SpecialK or Windows 11 AutoHDR. Both of which don't necessarily play nice with older games
with strongly different and simpler lighting. HDR should also be supported in Linux.
Development of my own AutoHDR shader is almost complete and will come next.
This has been carefully tested and there should be no regression in any of the different features that Dolphin
offers, like multisampling, stereo rendering, other post processes, etc etc.
Fixes: https://bugs.dolphin-emu.org/issues/8941
Co-authored-by: EndlesslyFlowering <EndlesslyFlowering@protonmail.com>
Co-authored-by: Dogway <lin_ares@hotmail.com>
2023-06-10 08:48:05 +00:00
|
|
|
|
|
|
|
// Intermediary pass.
|
2023-06-27 00:23:08 +00:00
|
|
|
// We draw to a high quality intermediary texture for a couple reasons:
|
|
|
|
// -Consistently do high quality gamma corrected resampling (upscaling/downscaling)
|
Video: implement color correction to match the NTSC and PAL color spaces (and gamma) that GC and Wii targeted.
To further increase the accuracy of the post process phase, I've added (scRGB) HDR support, which is necessary
to fully display the PAL and NTSC-J color spaces, and also to improve the quality of post process texture samplings and
do them in linear space instead of gamma space (which is very important when playing at low resolutions).
For SDR, the quality is also slightly increased, at least if any post process runs, as the buffer is now
R10G10B10A2 (on Vulkan, DX11 and DX12) if supported; previously it was R8G8B8A8 but the alpha bits were wasted.
Gamma correction is arguably the most important thing as Dolphin on Windows outputted in "sRGB" (implicitly)
as that's what Windows expects by default, though sRGB gamma is very different from the gamma commonly used
by video standards dating to the pre HDR era (roughly gamma 2.35).
Additionally, the addition of HDR support (which is pretty straight forward and minimal), added support for
our own custom AutoHDR shaders, which would allow us to achieve decent looking HDR in Dolphin games without
having to use SpecialK or Windows 11 AutoHDR. Both of which don't necessarily play nice with older games
with strongly different and simpler lighting. HDR should also be supported in Linux.
Development of my own AutoHDR shader is almost complete and will come next.
This has been carefully tested and there should be no regression in any of the different features that Dolphin
offers, like multisampling, stereo rendering, other post processes, etc etc.
Fixes: https://bugs.dolphin-emu.org/issues/8941
Co-authored-by: EndlesslyFlowering <EndlesslyFlowering@protonmail.com>
Co-authored-by: Dogway <lin_ares@hotmail.com>
2023-06-10 08:48:05 +00:00
|
|
|
// -Keep quality for gamma and gamut conversions, and HDR output
|
|
|
|
// (low bit depths lose too much quality with gamma conversions)
|
2023-06-27 00:23:08 +00:00
|
|
|
// -Keep the post process phase in linear space, to better operate with colors
|
|
|
|
if (m_default_pipeline && needs_default_pipeline && needs_intermediary_buffer)
|
Video: implement color correction to match the NTSC and PAL color spaces (and gamma) that GC and Wii targeted.
To further increase the accuracy of the post process phase, I've added (scRGB) HDR support, which is necessary
to fully display the PAL and NTSC-J color spaces, and also to improve the quality of post process texture samplings and
do them in linear space instead of gamma space (which is very important when playing at low resolutions).
For SDR, the quality is also slightly increased, at least if any post process runs, as the buffer is now
R10G10B10A2 (on Vulkan, DX11 and DX12) if supported; previously it was R8G8B8A8 but the alpha bits were wasted.
Gamma correction is arguably the most important thing as Dolphin on Windows outputted in "sRGB" (implicitly)
as that's what Windows expects by default, though sRGB gamma is very different from the gamma commonly used
by video standards dating to the pre HDR era (roughly gamma 2.35).
Additionally, the addition of HDR support (which is pretty straight forward and minimal), added support for
our own custom AutoHDR shaders, which would allow us to achieve decent looking HDR in Dolphin games without
having to use SpecialK or Windows 11 AutoHDR. Both of which don't necessarily play nice with older games
with strongly different and simpler lighting. HDR should also be supported in Linux.
Development of my own AutoHDR shader is almost complete and will come next.
This has been carefully tested and there should be no regression in any of the different features that Dolphin
offers, like multisampling, stereo rendering, other post processes, etc etc.
Fixes: https://bugs.dolphin-emu.org/issues/8941
Co-authored-by: EndlesslyFlowering <EndlesslyFlowering@protonmail.com>
Co-authored-by: Dogway <lin_ares@hotmail.com>
2023-06-10 08:48:05 +00:00
|
|
|
{
|
|
|
|
AbstractFramebuffer* const previous_framebuffer = g_gfx->GetCurrentFramebuffer();
|
|
|
|
|
|
|
|
// We keep the min number of layers as the render target,
|
|
|
|
// as in case of OpenGL, the source FBX will have two layers,
|
|
|
|
// but we will render onto two separate frame buffers (one by one),
|
|
|
|
// so it would be a waste to allocate two layers (see "bUsesExplictQuadBuffering").
|
|
|
|
const u32 target_layers = copy_all_layers ? src_tex->GetLayers() : 1;
|
|
|
|
|
2023-06-27 00:23:08 +00:00
|
|
|
const u32 target_width =
|
|
|
|
needs_resampling ? present_rect.GetWidth() : static_cast<u32>(src_rect.GetWidth());
|
|
|
|
const u32 target_height =
|
|
|
|
needs_resampling ? present_rect.GetHeight() : static_cast<u32>(src_rect.GetHeight());
|
|
|
|
|
Video: implement color correction to match the NTSC and PAL color spaces (and gamma) that GC and Wii targeted.
To further increase the accuracy of the post process phase, I've added (scRGB) HDR support, which is necessary
to fully display the PAL and NTSC-J color spaces, and also to improve the quality of post process texture samplings and
do them in linear space instead of gamma space (which is very important when playing at low resolutions).
For SDR, the quality is also slightly increased, at least if any post process runs, as the buffer is now
R10G10B10A2 (on Vulkan, DX11 and DX12) if supported; previously it was R8G8B8A8 but the alpha bits were wasted.
Gamma correction is arguably the most important thing as Dolphin on Windows outputted in "sRGB" (implicitly)
as that's what Windows expects by default, though sRGB gamma is very different from the gamma commonly used
by video standards dating to the pre HDR era (roughly gamma 2.35).
Additionally, the addition of HDR support (which is pretty straight forward and minimal), added support for
our own custom AutoHDR shaders, which would allow us to achieve decent looking HDR in Dolphin games without
having to use SpecialK or Windows 11 AutoHDR. Both of which don't necessarily play nice with older games
with strongly different and simpler lighting. HDR should also be supported in Linux.
Development of my own AutoHDR shader is almost complete and will come next.
This has been carefully tested and there should be no regression in any of the different features that Dolphin
offers, like multisampling, stereo rendering, other post processes, etc etc.
Fixes: https://bugs.dolphin-emu.org/issues/8941
Co-authored-by: EndlesslyFlowering <EndlesslyFlowering@protonmail.com>
Co-authored-by: Dogway <lin_ares@hotmail.com>
2023-06-10 08:48:05 +00:00
|
|
|
if (!m_intermediary_frame_buffer || !m_intermediary_color_texture ||
|
2023-06-27 00:23:08 +00:00
|
|
|
m_intermediary_color_texture.get()->GetWidth() != target_width ||
|
|
|
|
m_intermediary_color_texture.get()->GetHeight() != target_height ||
|
Video: implement color correction to match the NTSC and PAL color spaces (and gamma) that GC and Wii targeted.
To further increase the accuracy of the post process phase, I've added (scRGB) HDR support, which is necessary
to fully display the PAL and NTSC-J color spaces, and also to improve the quality of post process texture samplings and
do them in linear space instead of gamma space (which is very important when playing at low resolutions).
For SDR, the quality is also slightly increased, at least if any post process runs, as the buffer is now
R10G10B10A2 (on Vulkan, DX11 and DX12) if supported; previously it was R8G8B8A8 but the alpha bits were wasted.
Gamma correction is arguably the most important thing as Dolphin on Windows outputted in "sRGB" (implicitly)
as that's what Windows expects by default, though sRGB gamma is very different from the gamma commonly used
by video standards dating to the pre HDR era (roughly gamma 2.35).
Additionally, the addition of HDR support (which is pretty straight forward and minimal), added support for
our own custom AutoHDR shaders, which would allow us to achieve decent looking HDR in Dolphin games without
having to use SpecialK or Windows 11 AutoHDR. Both of which don't necessarily play nice with older games
with strongly different and simpler lighting. HDR should also be supported in Linux.
Development of my own AutoHDR shader is almost complete and will come next.
This has been carefully tested and there should be no regression in any of the different features that Dolphin
offers, like multisampling, stereo rendering, other post processes, etc etc.
Fixes: https://bugs.dolphin-emu.org/issues/8941
Co-authored-by: EndlesslyFlowering <EndlesslyFlowering@protonmail.com>
Co-authored-by: Dogway <lin_ares@hotmail.com>
2023-06-10 08:48:05 +00:00
|
|
|
m_intermediary_color_texture.get()->GetLayers() != target_layers)
|
|
|
|
{
|
|
|
|
const TextureConfig intermediary_color_texture_config(
|
2023-06-27 00:23:08 +00:00
|
|
|
target_width, target_height, 1, target_layers, src_tex->GetSamples(),
|
Video: implement color correction to match the NTSC and PAL color spaces (and gamma) that GC and Wii targeted.
To further increase the accuracy of the post process phase, I've added (scRGB) HDR support, which is necessary
to fully display the PAL and NTSC-J color spaces, and also to improve the quality of post process texture samplings and
do them in linear space instead of gamma space (which is very important when playing at low resolutions).
For SDR, the quality is also slightly increased, at least if any post process runs, as the buffer is now
R10G10B10A2 (on Vulkan, DX11 and DX12) if supported; previously it was R8G8B8A8 but the alpha bits were wasted.
Gamma correction is arguably the most important thing as Dolphin on Windows outputted in "sRGB" (implicitly)
as that's what Windows expects by default, though sRGB gamma is very different from the gamma commonly used
by video standards dating to the pre HDR era (roughly gamma 2.35).
Additionally, the addition of HDR support (which is pretty straight forward and minimal), added support for
our own custom AutoHDR shaders, which would allow us to achieve decent looking HDR in Dolphin games without
having to use SpecialK or Windows 11 AutoHDR. Both of which don't necessarily play nice with older games
with strongly different and simpler lighting. HDR should also be supported in Linux.
Development of my own AutoHDR shader is almost complete and will come next.
This has been carefully tested and there should be no regression in any of the different features that Dolphin
offers, like multisampling, stereo rendering, other post processes, etc etc.
Fixes: https://bugs.dolphin-emu.org/issues/8941
Co-authored-by: EndlesslyFlowering <EndlesslyFlowering@protonmail.com>
Co-authored-by: Dogway <lin_ares@hotmail.com>
2023-06-10 08:48:05 +00:00
|
|
|
s_intermediary_buffer_format, AbstractTextureFlag_RenderTarget);
|
|
|
|
m_intermediary_color_texture = g_gfx->CreateTexture(intermediary_color_texture_config,
|
|
|
|
"Intermediary post process texture");
|
|
|
|
|
|
|
|
m_intermediary_frame_buffer =
|
|
|
|
g_gfx->CreateFramebuffer(m_intermediary_color_texture.get(), nullptr);
|
|
|
|
}
|
|
|
|
|
|
|
|
g_gfx->SetFramebuffer(m_intermediary_frame_buffer.get());
|
|
|
|
|
|
|
|
FillUniformBuffer(src_rect, src_tex, src_layer, g_gfx->GetCurrentFramebuffer()->GetRect(),
|
2023-08-06 00:11:19 +00:00
|
|
|
present_rect, uniform_staging_buffer->data(), !default_uniform_staging_buffer,
|
|
|
|
true);
|
Video: implement color correction to match the NTSC and PAL color spaces (and gamma) that GC and Wii targeted.
To further increase the accuracy of the post process phase, I've added (scRGB) HDR support, which is necessary
to fully display the PAL and NTSC-J color spaces, and also to improve the quality of post process texture samplings and
do them in linear space instead of gamma space (which is very important when playing at low resolutions).
For SDR, the quality is also slightly increased, at least if any post process runs, as the buffer is now
R10G10B10A2 (on Vulkan, DX11 and DX12) if supported; previously it was R8G8B8A8 but the alpha bits were wasted.
Gamma correction is arguably the most important thing as Dolphin on Windows outputted in "sRGB" (implicitly)
as that's what Windows expects by default, though sRGB gamma is very different from the gamma commonly used
by video standards dating to the pre HDR era (roughly gamma 2.35).
Additionally, the addition of HDR support (which is pretty straight forward and minimal), added support for
our own custom AutoHDR shaders, which would allow us to achieve decent looking HDR in Dolphin games without
having to use SpecialK or Windows 11 AutoHDR. Both of which don't necessarily play nice with older games
with strongly different and simpler lighting. HDR should also be supported in Linux.
Development of my own AutoHDR shader is almost complete and will come next.
This has been carefully tested and there should be no regression in any of the different features that Dolphin
offers, like multisampling, stereo rendering, other post processes, etc etc.
Fixes: https://bugs.dolphin-emu.org/issues/8941
Co-authored-by: EndlesslyFlowering <EndlesslyFlowering@protonmail.com>
Co-authored-by: Dogway <lin_ares@hotmail.com>
2023-06-10 08:48:05 +00:00
|
|
|
g_vertex_manager->UploadUtilityUniforms(uniform_staging_buffer->data(),
|
|
|
|
static_cast<u32>(uniform_staging_buffer->size()));
|
|
|
|
|
|
|
|
g_gfx->SetViewportAndScissor(g_gfx->ConvertFramebufferRectangle(
|
|
|
|
m_intermediary_color_texture->GetRect(), m_intermediary_frame_buffer.get()));
|
|
|
|
g_gfx->SetPipeline(m_default_pipeline.get());
|
|
|
|
g_gfx->Draw(0, 3);
|
|
|
|
|
|
|
|
g_gfx->SetFramebuffer(previous_framebuffer);
|
|
|
|
src_rect = m_intermediary_color_texture->GetRect();
|
|
|
|
src_tex = m_intermediary_color_texture.get();
|
|
|
|
g_gfx->SetTexture(0, src_tex);
|
2023-06-27 00:23:08 +00:00
|
|
|
g_gfx->SetTexture(1, src_tex);
|
Video: implement color correction to match the NTSC and PAL color spaces (and gamma) that GC and Wii targeted.
To further increase the accuracy of the post process phase, I've added (scRGB) HDR support, which is necessary
to fully display the PAL and NTSC-J color spaces, and also to improve the quality of post process texture samplings and
do them in linear space instead of gamma space (which is very important when playing at low resolutions).
For SDR, the quality is also slightly increased, at least if any post process runs, as the buffer is now
R10G10B10A2 (on Vulkan, DX11 and DX12) if supported; previously it was R8G8B8A8 but the alpha bits were wasted.
Gamma correction is arguably the most important thing as Dolphin on Windows outputted in "sRGB" (implicitly)
as that's what Windows expects by default, though sRGB gamma is very different from the gamma commonly used
by video standards dating to the pre HDR era (roughly gamma 2.35).
Additionally, the addition of HDR support (which is pretty straight forward and minimal), added support for
our own custom AutoHDR shaders, which would allow us to achieve decent looking HDR in Dolphin games without
having to use SpecialK or Windows 11 AutoHDR. Both of which don't necessarily play nice with older games
with strongly different and simpler lighting. HDR should also be supported in Linux.
Development of my own AutoHDR shader is almost complete and will come next.
This has been carefully tested and there should be no regression in any of the different features that Dolphin
offers, like multisampling, stereo rendering, other post processes, etc etc.
Fixes: https://bugs.dolphin-emu.org/issues/8941
Co-authored-by: EndlesslyFlowering <EndlesslyFlowering@protonmail.com>
Co-authored-by: Dogway <lin_ares@hotmail.com>
2023-06-10 08:48:05 +00:00
|
|
|
// The "m_intermediary_color_texture" has already copied
|
|
|
|
// from the specified source layer onto its first one.
|
|
|
|
// If we query for a layer that the source texture doesn't have,
|
|
|
|
// it will fall back on the first one anyway.
|
|
|
|
src_layer = 0;
|
|
|
|
uniform_staging_buffer = &m_uniform_staging_buffer;
|
|
|
|
default_uniform_staging_buffer = false;
|
|
|
|
}
|
|
|
|
else
|
|
|
|
{
|
|
|
|
// If we have no custom user shader selected, and color correction
|
|
|
|
// is active, directly run the fixed pipeline shader instead of
|
|
|
|
// doing two passes, with the second one doing nothing useful.
|
2023-06-27 00:23:08 +00:00
|
|
|
if (m_default_pipeline && needs_default_pipeline)
|
Video: implement color correction to match the NTSC and PAL color spaces (and gamma) that GC and Wii targeted.
To further increase the accuracy of the post process phase, I've added (scRGB) HDR support, which is necessary
to fully display the PAL and NTSC-J color spaces, and also to improve the quality of post process texture samplings and
do them in linear space instead of gamma space (which is very important when playing at low resolutions).
For SDR, the quality is also slightly increased, at least if any post process runs, as the buffer is now
R10G10B10A2 (on Vulkan, DX11 and DX12) if supported; previously it was R8G8B8A8 but the alpha bits were wasted.
Gamma correction is arguably the most important thing as Dolphin on Windows outputted in "sRGB" (implicitly)
as that's what Windows expects by default, though sRGB gamma is very different from the gamma commonly used
by video standards dating to the pre HDR era (roughly gamma 2.35).
Additionally, the addition of HDR support (which is pretty straight forward and minimal), added support for
our own custom AutoHDR shaders, which would allow us to achieve decent looking HDR in Dolphin games without
having to use SpecialK or Windows 11 AutoHDR. Both of which don't necessarily play nice with older games
with strongly different and simpler lighting. HDR should also be supported in Linux.
Development of my own AutoHDR shader is almost complete and will come next.
This has been carefully tested and there should be no regression in any of the different features that Dolphin
offers, like multisampling, stereo rendering, other post processes, etc etc.
Fixes: https://bugs.dolphin-emu.org/issues/8941
Co-authored-by: EndlesslyFlowering <EndlesslyFlowering@protonmail.com>
Co-authored-by: Dogway <lin_ares@hotmail.com>
2023-06-10 08:48:05 +00:00
|
|
|
{
|
|
|
|
final_pipeline = m_default_pipeline.get();
|
|
|
|
}
|
|
|
|
else
|
|
|
|
{
|
|
|
|
uniform_staging_buffer = &m_uniform_staging_buffer;
|
|
|
|
default_uniform_staging_buffer = false;
|
|
|
|
}
|
|
|
|
|
|
|
|
m_intermediary_frame_buffer.release();
|
|
|
|
m_intermediary_color_texture.release();
|
|
|
|
}
|
|
|
|
|
|
|
|
// TODO: ideally we'd do the user selected post process pass in the intermediary buffer in linear
|
|
|
|
// space (instead of gamma space), so the shaders could act more accurately (and sample in linear
|
|
|
|
// space), though that would break the look of some of current post processes we have, and thus is
|
|
|
|
// better avoided for now.
|
|
|
|
|
|
|
|
// Final pass, either a user selected shader or the default (fixed) shader.
|
|
|
|
if (final_pipeline)
|
|
|
|
{
|
|
|
|
FillUniformBuffer(src_rect, src_tex, src_layer, g_gfx->GetCurrentFramebuffer()->GetRect(),
|
2023-08-06 00:11:19 +00:00
|
|
|
present_rect, uniform_staging_buffer->data(), !default_uniform_staging_buffer,
|
|
|
|
false);
|
Video: implement color correction to match the NTSC and PAL color spaces (and gamma) that GC and Wii targeted.
To further increase the accuracy of the post process phase, I've added (scRGB) HDR support, which is necessary
to fully display the PAL and NTSC-J color spaces, and also to improve the quality of post process texture samplings and
do them in linear space instead of gamma space (which is very important when playing at low resolutions).
For SDR, the quality is also slightly increased, at least if any post process runs, as the buffer is now
R10G10B10A2 (on Vulkan, DX11 and DX12) if supported; previously it was R8G8B8A8 but the alpha bits were wasted.
Gamma correction is arguably the most important thing as Dolphin on Windows outputted in "sRGB" (implicitly)
as that's what Windows expects by default, though sRGB gamma is very different from the gamma commonly used
by video standards dating to the pre HDR era (roughly gamma 2.35).
Additionally, the addition of HDR support (which is pretty straight forward and minimal), added support for
our own custom AutoHDR shaders, which would allow us to achieve decent looking HDR in Dolphin games without
having to use SpecialK or Windows 11 AutoHDR. Both of which don't necessarily play nice with older games
with strongly different and simpler lighting. HDR should also be supported in Linux.
Development of my own AutoHDR shader is almost complete and will come next.
This has been carefully tested and there should be no regression in any of the different features that Dolphin
offers, like multisampling, stereo rendering, other post processes, etc etc.
Fixes: https://bugs.dolphin-emu.org/issues/8941
Co-authored-by: EndlesslyFlowering <EndlesslyFlowering@protonmail.com>
Co-authored-by: Dogway <lin_ares@hotmail.com>
2023-06-10 08:48:05 +00:00
|
|
|
g_vertex_manager->UploadUtilityUniforms(uniform_staging_buffer->data(),
|
|
|
|
static_cast<u32>(uniform_staging_buffer->size()));
|
|
|
|
|
|
|
|
g_gfx->SetViewportAndScissor(
|
|
|
|
g_gfx->ConvertFramebufferRectangle(dst, g_gfx->GetCurrentFramebuffer()));
|
|
|
|
g_gfx->SetPipeline(final_pipeline);
|
|
|
|
g_gfx->Draw(0, 3);
|
|
|
|
}
|
2019-02-15 01:59:50 +00:00
|
|
|
}
|
|
|
|
|
Video: implement color correction to match the NTSC and PAL color spaces (and gamma) that GC and Wii targeted.
To further increase the accuracy of the post process phase, I've added (scRGB) HDR support, which is necessary
to fully display the PAL and NTSC-J color spaces, and also to improve the quality of post process texture samplings and
do them in linear space instead of gamma space (which is very important when playing at low resolutions).
For SDR, the quality is also slightly increased, at least if any post process runs, as the buffer is now
R10G10B10A2 (on Vulkan, DX11 and DX12) if supported; previously it was R8G8B8A8 but the alpha bits were wasted.
Gamma correction is arguably the most important thing as Dolphin on Windows outputted in "sRGB" (implicitly)
as that's what Windows expects by default, though sRGB gamma is very different from the gamma commonly used
by video standards dating to the pre HDR era (roughly gamma 2.35).
Additionally, the addition of HDR support (which is pretty straight forward and minimal), added support for
our own custom AutoHDR shaders, which would allow us to achieve decent looking HDR in Dolphin games without
having to use SpecialK or Windows 11 AutoHDR. Both of which don't necessarily play nice with older games
with strongly different and simpler lighting. HDR should also be supported in Linux.
Development of my own AutoHDR shader is almost complete and will come next.
This has been carefully tested and there should be no regression in any of the different features that Dolphin
offers, like multisampling, stereo rendering, other post processes, etc etc.
Fixes: https://bugs.dolphin-emu.org/issues/8941
Co-authored-by: EndlesslyFlowering <EndlesslyFlowering@protonmail.com>
Co-authored-by: Dogway <lin_ares@hotmail.com>
2023-06-10 08:48:05 +00:00
|
|
|
std::string PostProcessing::GetUniformBufferHeader(bool user_post_process) const
|
2019-02-15 01:59:50 +00:00
|
|
|
{
|
2019-09-14 20:40:34 +00:00
|
|
|
std::ostringstream ss;
|
2019-02-15 01:59:50 +00:00
|
|
|
u32 unused_counter = 1;
|
2022-05-04 05:41:34 +00:00
|
|
|
ss << "UBO_BINDING(std140, 1) uniform PSBlock {\n";
|
2019-02-15 01:59:50 +00:00
|
|
|
|
Video: implement color correction to match the NTSC and PAL color spaces (and gamma) that GC and Wii targeted.
To further increase the accuracy of the post process phase, I've added (scRGB) HDR support, which is necessary
to fully display the PAL and NTSC-J color spaces, and also to improve the quality of post process texture samplings and
do them in linear space instead of gamma space (which is very important when playing at low resolutions).
For SDR, the quality is also slightly increased, at least if any post process runs, as the buffer is now
R10G10B10A2 (on Vulkan, DX11 and DX12) if supported; previously it was R8G8B8A8 but the alpha bits were wasted.
Gamma correction is arguably the most important thing as Dolphin on Windows outputted in "sRGB" (implicitly)
as that's what Windows expects by default, though sRGB gamma is very different from the gamma commonly used
by video standards dating to the pre HDR era (roughly gamma 2.35).
Additionally, the addition of HDR support (which is pretty straight forward and minimal), added support for
our own custom AutoHDR shaders, which would allow us to achieve decent looking HDR in Dolphin games without
having to use SpecialK or Windows 11 AutoHDR. Both of which don't necessarily play nice with older games
with strongly different and simpler lighting. HDR should also be supported in Linux.
Development of my own AutoHDR shader is almost complete and will come next.
This has been carefully tested and there should be no regression in any of the different features that Dolphin
offers, like multisampling, stereo rendering, other post processes, etc etc.
Fixes: https://bugs.dolphin-emu.org/issues/8941
Co-authored-by: EndlesslyFlowering <EndlesslyFlowering@protonmail.com>
Co-authored-by: Dogway <lin_ares@hotmail.com>
2023-06-10 08:48:05 +00:00
|
|
|
// Builtin uniforms:
|
|
|
|
|
|
|
|
ss << " float4 resolution;\n"; // Source resolution
|
|
|
|
ss << " float4 target_resolution;\n";
|
2019-05-02 02:47:50 +00:00
|
|
|
ss << " float4 window_resolution;\n";
|
Video: implement color correction to match the NTSC and PAL color spaces (and gamma) that GC and Wii targeted.
To further increase the accuracy of the post process phase, I've added (scRGB) HDR support, which is necessary
to fully display the PAL and NTSC-J color spaces, and also to improve the quality of post process texture samplings and
do them in linear space instead of gamma space (which is very important when playing at low resolutions).
For SDR, the quality is also slightly increased, at least if any post process runs, as the buffer is now
R10G10B10A2 (on Vulkan, DX11 and DX12) if supported; previously it was R8G8B8A8 but the alpha bits were wasted.
Gamma correction is arguably the most important thing as Dolphin on Windows outputted in "sRGB" (implicitly)
as that's what Windows expects by default, though sRGB gamma is very different from the gamma commonly used
by video standards dating to the pre HDR era (roughly gamma 2.35).
Additionally, the addition of HDR support (which is pretty straight forward and minimal), added support for
our own custom AutoHDR shaders, which would allow us to achieve decent looking HDR in Dolphin games without
having to use SpecialK or Windows 11 AutoHDR. Both of which don't necessarily play nice with older games
with strongly different and simpler lighting. HDR should also be supported in Linux.
Development of my own AutoHDR shader is almost complete and will come next.
This has been carefully tested and there should be no regression in any of the different features that Dolphin
offers, like multisampling, stereo rendering, other post processes, etc etc.
Fixes: https://bugs.dolphin-emu.org/issues/8941
Co-authored-by: EndlesslyFlowering <EndlesslyFlowering@protonmail.com>
Co-authored-by: Dogway <lin_ares@hotmail.com>
2023-06-10 08:48:05 +00:00
|
|
|
// How many horizontal and vertical stereo views do we have? (set to 1 when we use layers instead)
|
|
|
|
ss << " int2 stereo_views;\n";
|
2019-02-15 01:59:50 +00:00
|
|
|
ss << " float4 src_rect;\n";
|
Video: implement color correction to match the NTSC and PAL color spaces (and gamma) that GC and Wii targeted.
To further increase the accuracy of the post process phase, I've added (scRGB) HDR support, which is necessary
to fully display the PAL and NTSC-J color spaces, and also to improve the quality of post process texture samplings and
do them in linear space instead of gamma space (which is very important when playing at low resolutions).
For SDR, the quality is also slightly increased, at least if any post process runs, as the buffer is now
R10G10B10A2 (on Vulkan, DX11 and DX12) if supported; previously it was R8G8B8A8 but the alpha bits were wasted.
Gamma correction is arguably the most important thing as Dolphin on Windows outputted in "sRGB" (implicitly)
as that's what Windows expects by default, though sRGB gamma is very different from the gamma commonly used
by video standards dating to the pre HDR era (roughly gamma 2.35).
Additionally, the addition of HDR support (which is pretty straight forward and minimal), added support for
our own custom AutoHDR shaders, which would allow us to achieve decent looking HDR in Dolphin games without
having to use SpecialK or Windows 11 AutoHDR. Both of which don't necessarily play nice with older games
with strongly different and simpler lighting. HDR should also be supported in Linux.
Development of my own AutoHDR shader is almost complete and will come next.
This has been carefully tested and there should be no regression in any of the different features that Dolphin
offers, like multisampling, stereo rendering, other post processes, etc etc.
Fixes: https://bugs.dolphin-emu.org/issues/8941
Co-authored-by: EndlesslyFlowering <EndlesslyFlowering@protonmail.com>
Co-authored-by: Dogway <lin_ares@hotmail.com>
2023-06-10 08:48:05 +00:00
|
|
|
// The first (but not necessarily only) source layer we target
|
2019-10-02 01:52:52 +00:00
|
|
|
ss << " int src_layer;\n";
|
2019-02-15 01:59:50 +00:00
|
|
|
ss << " uint time;\n";
|
2023-08-06 00:11:19 +00:00
|
|
|
ss << " int graphics_api;\n";
|
|
|
|
// If true, it's an intermediary buffer (including the first), if false, it's the final one
|
|
|
|
ss << " int intermediary_buffer;\n";
|
2019-02-15 01:59:50 +00:00
|
|
|
|
2023-06-27 00:23:08 +00:00
|
|
|
ss << " int resampling_method;\n";
|
Video: implement color correction to match the NTSC and PAL color spaces (and gamma) that GC and Wii targeted.
To further increase the accuracy of the post process phase, I've added (scRGB) HDR support, which is necessary
to fully display the PAL and NTSC-J color spaces, and also to improve the quality of post process texture samplings and
do them in linear space instead of gamma space (which is very important when playing at low resolutions).
For SDR, the quality is also slightly increased, at least if any post process runs, as the buffer is now
R10G10B10A2 (on Vulkan, DX11 and DX12) if supported; previously it was R8G8B8A8 but the alpha bits were wasted.
Gamma correction is arguably the most important thing as Dolphin on Windows outputted in "sRGB" (implicitly)
as that's what Windows expects by default, though sRGB gamma is very different from the gamma commonly used
by video standards dating to the pre HDR era (roughly gamma 2.35).
Additionally, the addition of HDR support (which is pretty straight forward and minimal), added support for
our own custom AutoHDR shaders, which would allow us to achieve decent looking HDR in Dolphin games without
having to use SpecialK or Windows 11 AutoHDR. Both of which don't necessarily play nice with older games
with strongly different and simpler lighting. HDR should also be supported in Linux.
Development of my own AutoHDR shader is almost complete and will come next.
This has been carefully tested and there should be no regression in any of the different features that Dolphin
offers, like multisampling, stereo rendering, other post processes, etc etc.
Fixes: https://bugs.dolphin-emu.org/issues/8941
Co-authored-by: EndlesslyFlowering <EndlesslyFlowering@protonmail.com>
Co-authored-by: Dogway <lin_ares@hotmail.com>
2023-06-10 08:48:05 +00:00
|
|
|
ss << " int correct_color_space;\n";
|
|
|
|
ss << " int game_color_space;\n";
|
|
|
|
ss << " int correct_gamma;\n";
|
|
|
|
ss << " float game_gamma;\n";
|
|
|
|
ss << " int sdr_display_gamma_sRGB;\n";
|
|
|
|
ss << " float sdr_display_custom_gamma;\n";
|
|
|
|
ss << " int linear_space_output;\n";
|
|
|
|
ss << " int hdr_output;\n";
|
|
|
|
ss << " float hdr_paper_white_nits;\n";
|
|
|
|
ss << " float hdr_sdr_white_nits;\n";
|
|
|
|
|
|
|
|
if (user_post_process)
|
2019-02-15 01:59:50 +00:00
|
|
|
{
|
Video: implement color correction to match the NTSC and PAL color spaces (and gamma) that GC and Wii targeted.
To further increase the accuracy of the post process phase, I've added (scRGB) HDR support, which is necessary
to fully display the PAL and NTSC-J color spaces, and also to improve the quality of post process texture samplings and
do them in linear space instead of gamma space (which is very important when playing at low resolutions).
For SDR, the quality is also slightly increased, at least if any post process runs, as the buffer is now
R10G10B10A2 (on Vulkan, DX11 and DX12) if supported; previously it was R8G8B8A8 but the alpha bits were wasted.
Gamma correction is arguably the most important thing as Dolphin on Windows outputted in "sRGB" (implicitly)
as that's what Windows expects by default, though sRGB gamma is very different from the gamma commonly used
by video standards dating to the pre HDR era (roughly gamma 2.35).
Additionally, the addition of HDR support (which is pretty straight forward and minimal), added support for
our own custom AutoHDR shaders, which would allow us to achieve decent looking HDR in Dolphin games without
having to use SpecialK or Windows 11 AutoHDR. Both of which don't necessarily play nice with older games
with strongly different and simpler lighting. HDR should also be supported in Linux.
Development of my own AutoHDR shader is almost complete and will come next.
This has been carefully tested and there should be no regression in any of the different features that Dolphin
offers, like multisampling, stereo rendering, other post processes, etc etc.
Fixes: https://bugs.dolphin-emu.org/issues/8941
Co-authored-by: EndlesslyFlowering <EndlesslyFlowering@protonmail.com>
Co-authored-by: Dogway <lin_ares@hotmail.com>
2023-06-10 08:48:05 +00:00
|
|
|
ss << "\n";
|
|
|
|
// Custom options/uniforms
|
|
|
|
for (const auto& it : m_config.GetOptions())
|
2019-02-15 01:59:50 +00:00
|
|
|
{
|
Video: implement color correction to match the NTSC and PAL color spaces (and gamma) that GC and Wii targeted.
To further increase the accuracy of the post process phase, I've added (scRGB) HDR support, which is necessary
to fully display the PAL and NTSC-J color spaces, and also to improve the quality of post process texture samplings and
do them in linear space instead of gamma space (which is very important when playing at low resolutions).
For SDR, the quality is also slightly increased, at least if any post process runs, as the buffer is now
R10G10B10A2 (on Vulkan, DX11 and DX12) if supported; previously it was R8G8B8A8 but the alpha bits were wasted.
Gamma correction is arguably the most important thing as Dolphin on Windows outputted in "sRGB" (implicitly)
as that's what Windows expects by default, though sRGB gamma is very different from the gamma commonly used
by video standards dating to the pre HDR era (roughly gamma 2.35).
Additionally, the addition of HDR support (which is pretty straight forward and minimal), added support for
our own custom AutoHDR shaders, which would allow us to achieve decent looking HDR in Dolphin games without
having to use SpecialK or Windows 11 AutoHDR. Both of which don't necessarily play nice with older games
with strongly different and simpler lighting. HDR should also be supported in Linux.
Development of my own AutoHDR shader is almost complete and will come next.
This has been carefully tested and there should be no regression in any of the different features that Dolphin
offers, like multisampling, stereo rendering, other post processes, etc etc.
Fixes: https://bugs.dolphin-emu.org/issues/8941
Co-authored-by: EndlesslyFlowering <EndlesslyFlowering@protonmail.com>
Co-authored-by: Dogway <lin_ares@hotmail.com>
2023-06-10 08:48:05 +00:00
|
|
|
if (it.second.m_type == PostProcessingConfiguration::ConfigurationOption::OptionType::Bool)
|
|
|
|
{
|
2019-11-22 22:10:41 +00:00
|
|
|
ss << fmt::format(" int {};\n", it.first);
|
Video: implement color correction to match the NTSC and PAL color spaces (and gamma) that GC and Wii targeted.
To further increase the accuracy of the post process phase, I've added (scRGB) HDR support, which is necessary
to fully display the PAL and NTSC-J color spaces, and also to improve the quality of post process texture samplings and
do them in linear space instead of gamma space (which is very important when playing at low resolutions).
For SDR, the quality is also slightly increased, at least if any post process runs, as the buffer is now
R10G10B10A2 (on Vulkan, DX11 and DX12) if supported; previously it was R8G8B8A8 but the alpha bits were wasted.
Gamma correction is arguably the most important thing as Dolphin on Windows outputted in "sRGB" (implicitly)
as that's what Windows expects by default, though sRGB gamma is very different from the gamma commonly used
by video standards dating to the pre HDR era (roughly gamma 2.35).
Additionally, the addition of HDR support (which is pretty straight forward and minimal), added support for
our own custom AutoHDR shaders, which would allow us to achieve decent looking HDR in Dolphin games without
having to use SpecialK or Windows 11 AutoHDR. Both of which don't necessarily play nice with older games
with strongly different and simpler lighting. HDR should also be supported in Linux.
Development of my own AutoHDR shader is almost complete and will come next.
This has been carefully tested and there should be no regression in any of the different features that Dolphin
offers, like multisampling, stereo rendering, other post processes, etc etc.
Fixes: https://bugs.dolphin-emu.org/issues/8941
Co-authored-by: EndlesslyFlowering <EndlesslyFlowering@protonmail.com>
Co-authored-by: Dogway <lin_ares@hotmail.com>
2023-06-10 08:48:05 +00:00
|
|
|
for (u32 i = 0; i < 3; i++)
|
|
|
|
ss << " int ubo_align_" << unused_counter++ << "_;\n";
|
|
|
|
}
|
|
|
|
else if (it.second.m_type ==
|
|
|
|
PostProcessingConfiguration::ConfigurationOption::OptionType::Integer)
|
|
|
|
{
|
|
|
|
u32 count = static_cast<u32>(it.second.m_integer_values.size());
|
|
|
|
if (count == 1)
|
|
|
|
ss << fmt::format(" int {};\n", it.first);
|
|
|
|
else
|
|
|
|
ss << fmt::format(" int{} {};\n", count, it.first);
|
2019-02-15 01:59:50 +00:00
|
|
|
|
Video: implement color correction to match the NTSC and PAL color spaces (and gamma) that GC and Wii targeted.
To further increase the accuracy of the post process phase, I've added (scRGB) HDR support, which is necessary
to fully display the PAL and NTSC-J color spaces, and also to improve the quality of post process texture samplings and
do them in linear space instead of gamma space (which is very important when playing at low resolutions).
For SDR, the quality is also slightly increased, at least if any post process runs, as the buffer is now
R10G10B10A2 (on Vulkan, DX11 and DX12) if supported; previously it was R8G8B8A8 but the alpha bits were wasted.
Gamma correction is arguably the most important thing as Dolphin on Windows outputted in "sRGB" (implicitly)
as that's what Windows expects by default, though sRGB gamma is very different from the gamma commonly used
by video standards dating to the pre HDR era (roughly gamma 2.35).
Additionally, the addition of HDR support (which is pretty straight forward and minimal), added support for
our own custom AutoHDR shaders, which would allow us to achieve decent looking HDR in Dolphin games without
having to use SpecialK or Windows 11 AutoHDR. Both of which don't necessarily play nice with older games
with strongly different and simpler lighting. HDR should also be supported in Linux.
Development of my own AutoHDR shader is almost complete and will come next.
This has been carefully tested and there should be no regression in any of the different features that Dolphin
offers, like multisampling, stereo rendering, other post processes, etc etc.
Fixes: https://bugs.dolphin-emu.org/issues/8941
Co-authored-by: EndlesslyFlowering <EndlesslyFlowering@protonmail.com>
Co-authored-by: Dogway <lin_ares@hotmail.com>
2023-06-10 08:48:05 +00:00
|
|
|
for (u32 i = count; i < 4; i++)
|
|
|
|
ss << " int ubo_align_" << unused_counter++ << "_;\n";
|
|
|
|
}
|
|
|
|
else if (it.second.m_type ==
|
|
|
|
PostProcessingConfiguration::ConfigurationOption::OptionType::Float)
|
|
|
|
{
|
|
|
|
u32 count = static_cast<u32>(it.second.m_float_values.size());
|
|
|
|
if (count == 1)
|
|
|
|
ss << fmt::format(" float {};\n", it.first);
|
|
|
|
else
|
|
|
|
ss << fmt::format(" float{} {};\n", count, it.first);
|
|
|
|
|
|
|
|
for (u32 i = count; i < 4; i++)
|
|
|
|
ss << " float ubo_align_" << unused_counter++ << "_;\n";
|
|
|
|
}
|
2019-02-15 01:59:50 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
ss << "};\n\n";
|
|
|
|
return ss.str();
|
|
|
|
}
|
|
|
|
|
Video: implement color correction to match the NTSC and PAL color spaces (and gamma) that GC and Wii targeted.
To further increase the accuracy of the post process phase, I've added (scRGB) HDR support, which is necessary
to fully display the PAL and NTSC-J color spaces, and also to improve the quality of post process texture samplings and
do them in linear space instead of gamma space (which is very important when playing at low resolutions).
For SDR, the quality is also slightly increased, at least if any post process runs, as the buffer is now
R10G10B10A2 (on Vulkan, DX11 and DX12) if supported; previously it was R8G8B8A8 but the alpha bits were wasted.
Gamma correction is arguably the most important thing as Dolphin on Windows outputted in "sRGB" (implicitly)
as that's what Windows expects by default, though sRGB gamma is very different from the gamma commonly used
by video standards dating to the pre HDR era (roughly gamma 2.35).
Additionally, the addition of HDR support (which is pretty straight forward and minimal), added support for
our own custom AutoHDR shaders, which would allow us to achieve decent looking HDR in Dolphin games without
having to use SpecialK or Windows 11 AutoHDR. Both of which don't necessarily play nice with older games
with strongly different and simpler lighting. HDR should also be supported in Linux.
Development of my own AutoHDR shader is almost complete and will come next.
This has been carefully tested and there should be no regression in any of the different features that Dolphin
offers, like multisampling, stereo rendering, other post processes, etc etc.
Fixes: https://bugs.dolphin-emu.org/issues/8941
Co-authored-by: EndlesslyFlowering <EndlesslyFlowering@protonmail.com>
Co-authored-by: Dogway <lin_ares@hotmail.com>
2023-06-10 08:48:05 +00:00
|
|
|
std::string PostProcessing::GetHeader(bool user_post_process) const
|
2019-02-15 01:59:50 +00:00
|
|
|
{
|
2019-09-14 20:40:34 +00:00
|
|
|
std::ostringstream ss;
|
Video: implement color correction to match the NTSC and PAL color spaces (and gamma) that GC and Wii targeted.
To further increase the accuracy of the post process phase, I've added (scRGB) HDR support, which is necessary
to fully display the PAL and NTSC-J color spaces, and also to improve the quality of post process texture samplings and
do them in linear space instead of gamma space (which is very important when playing at low resolutions).
For SDR, the quality is also slightly increased, at least if any post process runs, as the buffer is now
R10G10B10A2 (on Vulkan, DX11 and DX12) if supported; previously it was R8G8B8A8 but the alpha bits were wasted.
Gamma correction is arguably the most important thing as Dolphin on Windows outputted in "sRGB" (implicitly)
as that's what Windows expects by default, though sRGB gamma is very different from the gamma commonly used
by video standards dating to the pre HDR era (roughly gamma 2.35).
Additionally, the addition of HDR support (which is pretty straight forward and minimal), added support for
our own custom AutoHDR shaders, which would allow us to achieve decent looking HDR in Dolphin games without
having to use SpecialK or Windows 11 AutoHDR. Both of which don't necessarily play nice with older games
with strongly different and simpler lighting. HDR should also be supported in Linux.
Development of my own AutoHDR shader is almost complete and will come next.
This has been carefully tested and there should be no regression in any of the different features that Dolphin
offers, like multisampling, stereo rendering, other post processes, etc etc.
Fixes: https://bugs.dolphin-emu.org/issues/8941
Co-authored-by: EndlesslyFlowering <EndlesslyFlowering@protonmail.com>
Co-authored-by: Dogway <lin_ares@hotmail.com>
2023-06-10 08:48:05 +00:00
|
|
|
ss << GetUniformBufferHeader(user_post_process);
|
2022-05-04 05:41:34 +00:00
|
|
|
ss << "SAMPLER_BINDING(0) uniform sampler2DArray samp0;\n";
|
Video: implement color correction to match the NTSC and PAL color spaces (and gamma) that GC and Wii targeted.
To further increase the accuracy of the post process phase, I've added (scRGB) HDR support, which is necessary
to fully display the PAL and NTSC-J color spaces, and also to improve the quality of post process texture samplings and
do them in linear space instead of gamma space (which is very important when playing at low resolutions).
For SDR, the quality is also slightly increased, at least if any post process runs, as the buffer is now
R10G10B10A2 (on Vulkan, DX11 and DX12) if supported; previously it was R8G8B8A8 but the alpha bits were wasted.
Gamma correction is arguably the most important thing as Dolphin on Windows outputted in "sRGB" (implicitly)
as that's what Windows expects by default, though sRGB gamma is very different from the gamma commonly used
by video standards dating to the pre HDR era (roughly gamma 2.35).
Additionally, the addition of HDR support (which is pretty straight forward and minimal), added support for
our own custom AutoHDR shaders, which would allow us to achieve decent looking HDR in Dolphin games without
having to use SpecialK or Windows 11 AutoHDR. Both of which don't necessarily play nice with older games
with strongly different and simpler lighting. HDR should also be supported in Linux.
Development of my own AutoHDR shader is almost complete and will come next.
This has been carefully tested and there should be no regression in any of the different features that Dolphin
offers, like multisampling, stereo rendering, other post processes, etc etc.
Fixes: https://bugs.dolphin-emu.org/issues/8941
Co-authored-by: EndlesslyFlowering <EndlesslyFlowering@protonmail.com>
Co-authored-by: Dogway <lin_ares@hotmail.com>
2023-06-10 08:48:05 +00:00
|
|
|
ss << "SAMPLER_BINDING(1) uniform sampler2DArray samp1;\n";
|
2022-05-04 05:41:34 +00:00
|
|
|
|
|
|
|
if (g_ActiveConfig.backend_info.bSupportsGeometryShaders)
|
2019-02-15 01:59:50 +00:00
|
|
|
{
|
2022-05-04 05:41:34 +00:00
|
|
|
ss << "VARYING_LOCATION(0) in VertexData {\n";
|
|
|
|
ss << " float3 v_tex0;\n";
|
|
|
|
ss << "};\n";
|
2019-02-15 01:59:50 +00:00
|
|
|
}
|
|
|
|
else
|
|
|
|
{
|
2022-05-04 05:41:34 +00:00
|
|
|
ss << "VARYING_LOCATION(0) in float3 v_tex0;\n";
|
2019-02-15 01:59:50 +00:00
|
|
|
}
|
|
|
|
|
2022-05-04 05:41:34 +00:00
|
|
|
ss << "FRAGMENT_OUTPUT_LOCATION(0) out float4 ocol0;\n";
|
2019-02-15 01:59:50 +00:00
|
|
|
|
|
|
|
ss << R"(
|
2019-10-02 01:52:52 +00:00
|
|
|
float4 Sample() { return texture(samp0, v_tex0); }
|
|
|
|
float4 SampleLocation(float2 location) { return texture(samp0, float3(location, float(v_tex0.z))); }
|
2019-02-15 01:59:50 +00:00
|
|
|
float4 SampleLayer(int layer) { return texture(samp0, float3(v_tex0.xy, float(layer))); }
|
2019-10-02 01:52:52 +00:00
|
|
|
#define SampleOffset(offset) textureOffset(samp0, v_tex0, offset)
|
2019-02-15 01:59:50 +00:00
|
|
|
|
Video: implement color correction to match the NTSC and PAL color spaces (and gamma) that GC and Wii targeted.
To further increase the accuracy of the post process phase, I've added (scRGB) HDR support, which is necessary
to fully display the PAL and NTSC-J color spaces, and also to improve the quality of post process texture samplings and
do them in linear space instead of gamma space (which is very important when playing at low resolutions).
For SDR, the quality is also slightly increased, at least if any post process runs, as the buffer is now
R10G10B10A2 (on Vulkan, DX11 and DX12) if supported; previously it was R8G8B8A8 but the alpha bits were wasted.
Gamma correction is arguably the most important thing as Dolphin on Windows outputted in "sRGB" (implicitly)
as that's what Windows expects by default, though sRGB gamma is very different from the gamma commonly used
by video standards dating to the pre HDR era (roughly gamma 2.35).
Additionally, the addition of HDR support (which is pretty straight forward and minimal), added support for
our own custom AutoHDR shaders, which would allow us to achieve decent looking HDR in Dolphin games without
having to use SpecialK or Windows 11 AutoHDR. Both of which don't necessarily play nice with older games
with strongly different and simpler lighting. HDR should also be supported in Linux.
Development of my own AutoHDR shader is almost complete and will come next.
This has been carefully tested and there should be no regression in any of the different features that Dolphin
offers, like multisampling, stereo rendering, other post processes, etc etc.
Fixes: https://bugs.dolphin-emu.org/issues/8941
Co-authored-by: EndlesslyFlowering <EndlesslyFlowering@protonmail.com>
Co-authored-by: Dogway <lin_ares@hotmail.com>
2023-06-10 08:48:05 +00:00
|
|
|
float2 GetTargetResolution()
|
|
|
|
{
|
|
|
|
return target_resolution.xy;
|
|
|
|
}
|
|
|
|
|
|
|
|
float2 GetInvTargetResolution()
|
|
|
|
{
|
|
|
|
return target_resolution.zw;
|
|
|
|
}
|
|
|
|
|
2019-05-02 02:47:50 +00:00
|
|
|
float2 GetWindowResolution()
|
|
|
|
{
|
|
|
|
return window_resolution.xy;
|
|
|
|
}
|
|
|
|
|
2021-04-13 17:14:17 +00:00
|
|
|
float2 GetInvWindowResolution()
|
|
|
|
{
|
|
|
|
return window_resolution.zw;
|
|
|
|
}
|
|
|
|
|
2019-02-15 01:59:50 +00:00
|
|
|
float2 GetResolution()
|
|
|
|
{
|
|
|
|
return resolution.xy;
|
|
|
|
}
|
|
|
|
|
|
|
|
float2 GetInvResolution()
|
|
|
|
{
|
|
|
|
return resolution.zw;
|
|
|
|
}
|
|
|
|
|
|
|
|
float2 GetCoordinates()
|
|
|
|
{
|
|
|
|
return v_tex0.xy;
|
|
|
|
}
|
|
|
|
|
2019-10-02 01:52:52 +00:00
|
|
|
float GetLayer()
|
|
|
|
{
|
|
|
|
return v_tex0.z;
|
|
|
|
}
|
|
|
|
|
2019-02-15 01:59:50 +00:00
|
|
|
uint GetTime()
|
|
|
|
{
|
|
|
|
return time;
|
|
|
|
}
|
|
|
|
|
|
|
|
void SetOutput(float4 color)
|
|
|
|
{
|
|
|
|
ocol0 = color;
|
|
|
|
}
|
|
|
|
|
|
|
|
#define GetOption(x) (x)
|
|
|
|
#define OptionEnabled(x) ((x) != 0)
|
2023-08-06 00:11:19 +00:00
|
|
|
#define OptionDisabled(x) ((x) == 0)
|
2019-02-15 01:59:50 +00:00
|
|
|
|
|
|
|
)";
|
|
|
|
return ss.str();
|
|
|
|
}
|
|
|
|
|
|
|
|
std::string PostProcessing::GetFooter() const
|
|
|
|
{
|
2022-05-04 05:41:34 +00:00
|
|
|
return {};
|
2019-02-15 01:59:50 +00:00
|
|
|
}
|
|
|
|
|
2023-12-11 22:07:56 +00:00
|
|
|
static std::string GetVertexShaderBody()
|
2019-02-15 01:59:50 +00:00
|
|
|
{
|
2019-09-14 20:40:34 +00:00
|
|
|
std::ostringstream ss;
|
2022-05-04 05:41:34 +00:00
|
|
|
if (g_ActiveConfig.backend_info.bSupportsGeometryShaders)
|
2019-02-15 01:59:50 +00:00
|
|
|
{
|
2022-05-04 05:41:34 +00:00
|
|
|
ss << "VARYING_LOCATION(0) out VertexData {\n";
|
|
|
|
ss << " float3 v_tex0;\n";
|
|
|
|
ss << "};\n";
|
2019-02-15 01:59:50 +00:00
|
|
|
}
|
|
|
|
else
|
|
|
|
{
|
2022-05-04 05:41:34 +00:00
|
|
|
ss << "VARYING_LOCATION(0) out float3 v_tex0;\n";
|
2019-02-15 01:59:50 +00:00
|
|
|
}
|
2022-05-04 05:41:34 +00:00
|
|
|
|
|
|
|
ss << "#define id gl_VertexID\n";
|
|
|
|
ss << "#define opos gl_Position\n";
|
|
|
|
ss << "void main() {\n";
|
2019-02-15 01:59:50 +00:00
|
|
|
ss << " v_tex0 = float3(float((id << 1) & 2), float(id & 2), 0.0f);\n";
|
|
|
|
ss << " opos = float4(v_tex0.xy * float2(2.0f, -2.0f) + float2(-1.0f, 1.0f), 0.0f, 1.0f);\n";
|
2019-10-02 01:52:52 +00:00
|
|
|
ss << " v_tex0 = float3(src_rect.xy + (src_rect.zw * v_tex0.xy), float(src_layer));\n";
|
2019-02-15 01:59:50 +00:00
|
|
|
|
Video: implement color correction to match the NTSC and PAL color spaces (and gamma) that GC and Wii targeted.
To further increase the accuracy of the post process phase, I've added (scRGB) HDR support, which is necessary
to fully display the PAL and NTSC-J color spaces, and also to improve the quality of post process texture samplings and
do them in linear space instead of gamma space (which is very important when playing at low resolutions).
For SDR, the quality is also slightly increased, at least if any post process runs, as the buffer is now
R10G10B10A2 (on Vulkan, DX11 and DX12) if supported; previously it was R8G8B8A8 but the alpha bits were wasted.
Gamma correction is arguably the most important thing as Dolphin on Windows outputted in "sRGB" (implicitly)
as that's what Windows expects by default, though sRGB gamma is very different from the gamma commonly used
by video standards dating to the pre HDR era (roughly gamma 2.35).
Additionally, the addition of HDR support (which is pretty straight forward and minimal), added support for
our own custom AutoHDR shaders, which would allow us to achieve decent looking HDR in Dolphin games without
having to use SpecialK or Windows 11 AutoHDR. Both of which don't necessarily play nice with older games
with strongly different and simpler lighting. HDR should also be supported in Linux.
Development of my own AutoHDR shader is almost complete and will come next.
This has been carefully tested and there should be no regression in any of the different features that Dolphin
offers, like multisampling, stereo rendering, other post processes, etc etc.
Fixes: https://bugs.dolphin-emu.org/issues/8941
Co-authored-by: EndlesslyFlowering <EndlesslyFlowering@protonmail.com>
Co-authored-by: Dogway <lin_ares@hotmail.com>
2023-06-10 08:48:05 +00:00
|
|
|
// Vulkan Y needs to be inverted on every pass
|
2019-02-15 01:59:50 +00:00
|
|
|
if (g_ActiveConfig.backend_info.api_type == APIType::Vulkan)
|
2023-08-06 00:11:19 +00:00
|
|
|
{
|
2019-02-15 01:59:50 +00:00
|
|
|
ss << " opos.y = -opos.y;\n";
|
2023-08-06 00:11:19 +00:00
|
|
|
}
|
|
|
|
// OpenGL Y needs to be inverted in all passes except the last one
|
|
|
|
else if (g_ActiveConfig.backend_info.api_type == APIType::OpenGL)
|
|
|
|
{
|
|
|
|
ss << " if (intermediary_buffer != 0)\n";
|
|
|
|
ss << " opos.y = -opos.y;\n";
|
|
|
|
}
|
Video: implement color correction to match the NTSC and PAL color spaces (and gamma) that GC and Wii targeted.
To further increase the accuracy of the post process phase, I've added (scRGB) HDR support, which is necessary
to fully display the PAL and NTSC-J color spaces, and also to improve the quality of post process texture samplings and
do them in linear space instead of gamma space (which is very important when playing at low resolutions).
For SDR, the quality is also slightly increased, at least if any post process runs, as the buffer is now
R10G10B10A2 (on Vulkan, DX11 and DX12) if supported; previously it was R8G8B8A8 but the alpha bits were wasted.
Gamma correction is arguably the most important thing as Dolphin on Windows outputted in "sRGB" (implicitly)
as that's what Windows expects by default, though sRGB gamma is very different from the gamma commonly used
by video standards dating to the pre HDR era (roughly gamma 2.35).
Additionally, the addition of HDR support (which is pretty straight forward and minimal), added support for
our own custom AutoHDR shaders, which would allow us to achieve decent looking HDR in Dolphin games without
having to use SpecialK or Windows 11 AutoHDR. Both of which don't necessarily play nice with older games
with strongly different and simpler lighting. HDR should also be supported in Linux.
Development of my own AutoHDR shader is almost complete and will come next.
This has been carefully tested and there should be no regression in any of the different features that Dolphin
offers, like multisampling, stereo rendering, other post processes, etc etc.
Fixes: https://bugs.dolphin-emu.org/issues/8941
Co-authored-by: EndlesslyFlowering <EndlesslyFlowering@protonmail.com>
Co-authored-by: Dogway <lin_ares@hotmail.com>
2023-06-10 08:48:05 +00:00
|
|
|
|
2019-02-15 01:59:50 +00:00
|
|
|
ss << "}\n";
|
2023-08-06 00:11:19 +00:00
|
|
|
return ss.str();
|
|
|
|
}
|
|
|
|
|
|
|
|
bool PostProcessing::CompileVertexShader()
|
|
|
|
{
|
|
|
|
std::ostringstream ss_default;
|
|
|
|
ss_default << GetUniformBufferHeader(false);
|
|
|
|
ss_default << GetVertexShaderBody();
|
|
|
|
m_default_vertex_shader = g_gfx->CreateShaderFromSource(ShaderStage::Vertex, ss_default.str(),
|
|
|
|
"Default post-processing vertex shader");
|
2019-02-15 01:59:50 +00:00
|
|
|
|
2023-08-06 00:11:19 +00:00
|
|
|
std::ostringstream ss;
|
|
|
|
ss << GetUniformBufferHeader(true);
|
|
|
|
ss << GetVertexShaderBody();
|
2023-01-26 22:34:59 +00:00
|
|
|
m_vertex_shader =
|
|
|
|
g_gfx->CreateShaderFromSource(ShaderStage::Vertex, ss.str(), "Post-processing vertex shader");
|
2023-08-06 00:11:19 +00:00
|
|
|
|
Video: implement color correction to match the NTSC and PAL color spaces (and gamma) that GC and Wii targeted.
To further increase the accuracy of the post process phase, I've added (scRGB) HDR support, which is necessary
to fully display the PAL and NTSC-J color spaces, and also to improve the quality of post process texture samplings and
do them in linear space instead of gamma space (which is very important when playing at low resolutions).
For SDR, the quality is also slightly increased, at least if any post process runs, as the buffer is now
R10G10B10A2 (on Vulkan, DX11 and DX12) if supported; previously it was R8G8B8A8 but the alpha bits were wasted.
Gamma correction is arguably the most important thing as Dolphin on Windows outputted in "sRGB" (implicitly)
as that's what Windows expects by default, though sRGB gamma is very different from the gamma commonly used
by video standards dating to the pre HDR era (roughly gamma 2.35).
Additionally, the addition of HDR support (which is pretty straight forward and minimal), added support for
our own custom AutoHDR shaders, which would allow us to achieve decent looking HDR in Dolphin games without
having to use SpecialK or Windows 11 AutoHDR. Both of which don't necessarily play nice with older games
with strongly different and simpler lighting. HDR should also be supported in Linux.
Development of my own AutoHDR shader is almost complete and will come next.
This has been carefully tested and there should be no regression in any of the different features that Dolphin
offers, like multisampling, stereo rendering, other post processes, etc etc.
Fixes: https://bugs.dolphin-emu.org/issues/8941
Co-authored-by: EndlesslyFlowering <EndlesslyFlowering@protonmail.com>
Co-authored-by: Dogway <lin_ares@hotmail.com>
2023-06-10 08:48:05 +00:00
|
|
|
if (!m_default_vertex_shader || !m_vertex_shader)
|
2019-02-15 01:59:50 +00:00
|
|
|
{
|
2020-11-14 03:33:26 +00:00
|
|
|
PanicAlertFmt("Failed to compile post-processing vertex shader");
|
Video: implement color correction to match the NTSC and PAL color spaces (and gamma) that GC and Wii targeted.
To further increase the accuracy of the post process phase, I've added (scRGB) HDR support, which is necessary
to fully display the PAL and NTSC-J color spaces, and also to improve the quality of post process texture samplings and
do them in linear space instead of gamma space (which is very important when playing at low resolutions).
For SDR, the quality is also slightly increased, at least if any post process runs, as the buffer is now
R10G10B10A2 (on Vulkan, DX11 and DX12) if supported; previously it was R8G8B8A8 but the alpha bits were wasted.
Gamma correction is arguably the most important thing as Dolphin on Windows outputted in "sRGB" (implicitly)
as that's what Windows expects by default, though sRGB gamma is very different from the gamma commonly used
by video standards dating to the pre HDR era (roughly gamma 2.35).
Additionally, the addition of HDR support (which is pretty straight forward and minimal), added support for
our own custom AutoHDR shaders, which would allow us to achieve decent looking HDR in Dolphin games without
having to use SpecialK or Windows 11 AutoHDR. Both of which don't necessarily play nice with older games
with strongly different and simpler lighting. HDR should also be supported in Linux.
Development of my own AutoHDR shader is almost complete and will come next.
This has been carefully tested and there should be no regression in any of the different features that Dolphin
offers, like multisampling, stereo rendering, other post processes, etc etc.
Fixes: https://bugs.dolphin-emu.org/issues/8941
Co-authored-by: EndlesslyFlowering <EndlesslyFlowering@protonmail.com>
Co-authored-by: Dogway <lin_ares@hotmail.com>
2023-06-10 08:48:05 +00:00
|
|
|
m_default_vertex_shader.reset();
|
|
|
|
m_vertex_shader.reset();
|
2019-02-15 01:59:50 +00:00
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
|
|
|
struct BuiltinUniforms
|
|
|
|
{
|
Video: implement color correction to match the NTSC and PAL color spaces (and gamma) that GC and Wii targeted.
To further increase the accuracy of the post process phase, I've added (scRGB) HDR support, which is necessary
to fully display the PAL and NTSC-J color spaces, and also to improve the quality of post process texture samplings and
do them in linear space instead of gamma space (which is very important when playing at low resolutions).
For SDR, the quality is also slightly increased, at least if any post process runs, as the buffer is now
R10G10B10A2 (on Vulkan, DX11 and DX12) if supported; previously it was R8G8B8A8 but the alpha bits were wasted.
Gamma correction is arguably the most important thing as Dolphin on Windows outputted in "sRGB" (implicitly)
as that's what Windows expects by default, though sRGB gamma is very different from the gamma commonly used
by video standards dating to the pre HDR era (roughly gamma 2.35).
Additionally, the addition of HDR support (which is pretty straight forward and minimal), added support for
our own custom AutoHDR shaders, which would allow us to achieve decent looking HDR in Dolphin games without
having to use SpecialK or Windows 11 AutoHDR. Both of which don't necessarily play nice with older games
with strongly different and simpler lighting. HDR should also be supported in Linux.
Development of my own AutoHDR shader is almost complete and will come next.
This has been carefully tested and there should be no regression in any of the different features that Dolphin
offers, like multisampling, stereo rendering, other post processes, etc etc.
Fixes: https://bugs.dolphin-emu.org/issues/8941
Co-authored-by: EndlesslyFlowering <EndlesslyFlowering@protonmail.com>
Co-authored-by: Dogway <lin_ares@hotmail.com>
2023-06-10 08:48:05 +00:00
|
|
|
// bools need to be represented as "s32"
|
|
|
|
|
|
|
|
std::array<float, 4> source_resolution;
|
|
|
|
std::array<float, 4> target_resolution;
|
|
|
|
std::array<float, 4> window_resolution;
|
|
|
|
std::array<float, 4> stereo_views;
|
|
|
|
std::array<float, 4> src_rect;
|
2019-10-02 01:52:52 +00:00
|
|
|
s32 src_layer;
|
|
|
|
u32 time;
|
2023-08-06 00:11:19 +00:00
|
|
|
s32 graphics_api;
|
|
|
|
s32 intermediary_buffer;
|
2023-06-27 00:23:08 +00:00
|
|
|
s32 resampling_method;
|
Video: implement color correction to match the NTSC and PAL color spaces (and gamma) that GC and Wii targeted.
To further increase the accuracy of the post process phase, I've added (scRGB) HDR support, which is necessary
to fully display the PAL and NTSC-J color spaces, and also to improve the quality of post process texture samplings and
do them in linear space instead of gamma space (which is very important when playing at low resolutions).
For SDR, the quality is also slightly increased, at least if any post process runs, as the buffer is now
R10G10B10A2 (on Vulkan, DX11 and DX12) if supported; previously it was R8G8B8A8 but the alpha bits were wasted.
Gamma correction is arguably the most important thing as Dolphin on Windows outputted in "sRGB" (implicitly)
as that's what Windows expects by default, though sRGB gamma is very different from the gamma commonly used
by video standards dating to the pre HDR era (roughly gamma 2.35).
Additionally, the addition of HDR support (which is pretty straight forward and minimal), added support for
our own custom AutoHDR shaders, which would allow us to achieve decent looking HDR in Dolphin games without
having to use SpecialK or Windows 11 AutoHDR. Both of which don't necessarily play nice with older games
with strongly different and simpler lighting. HDR should also be supported in Linux.
Development of my own AutoHDR shader is almost complete and will come next.
This has been carefully tested and there should be no regression in any of the different features that Dolphin
offers, like multisampling, stereo rendering, other post processes, etc etc.
Fixes: https://bugs.dolphin-emu.org/issues/8941
Co-authored-by: EndlesslyFlowering <EndlesslyFlowering@protonmail.com>
Co-authored-by: Dogway <lin_ares@hotmail.com>
2023-06-10 08:48:05 +00:00
|
|
|
s32 correct_color_space;
|
|
|
|
s32 game_color_space;
|
|
|
|
s32 correct_gamma;
|
|
|
|
float game_gamma;
|
|
|
|
s32 sdr_display_gamma_sRGB;
|
|
|
|
float sdr_display_custom_gamma;
|
|
|
|
s32 linear_space_output;
|
|
|
|
s32 hdr_output;
|
|
|
|
float hdr_paper_white_nits;
|
|
|
|
float hdr_sdr_white_nits;
|
2019-02-15 01:59:50 +00:00
|
|
|
};
|
|
|
|
|
Video: implement color correction to match the NTSC and PAL color spaces (and gamma) that GC and Wii targeted.
To further increase the accuracy of the post process phase, I've added (scRGB) HDR support, which is necessary
to fully display the PAL and NTSC-J color spaces, and also to improve the quality of post process texture samplings and
do them in linear space instead of gamma space (which is very important when playing at low resolutions).
For SDR, the quality is also slightly increased, at least if any post process runs, as the buffer is now
R10G10B10A2 (on Vulkan, DX11 and DX12) if supported; previously it was R8G8B8A8 but the alpha bits were wasted.
Gamma correction is arguably the most important thing as Dolphin on Windows outputted in "sRGB" (implicitly)
as that's what Windows expects by default, though sRGB gamma is very different from the gamma commonly used
by video standards dating to the pre HDR era (roughly gamma 2.35).
Additionally, the addition of HDR support (which is pretty straight forward and minimal), added support for
our own custom AutoHDR shaders, which would allow us to achieve decent looking HDR in Dolphin games without
having to use SpecialK or Windows 11 AutoHDR. Both of which don't necessarily play nice with older games
with strongly different and simpler lighting. HDR should also be supported in Linux.
Development of my own AutoHDR shader is almost complete and will come next.
This has been carefully tested and there should be no regression in any of the different features that Dolphin
offers, like multisampling, stereo rendering, other post processes, etc etc.
Fixes: https://bugs.dolphin-emu.org/issues/8941
Co-authored-by: EndlesslyFlowering <EndlesslyFlowering@protonmail.com>
Co-authored-by: Dogway <lin_ares@hotmail.com>
2023-06-10 08:48:05 +00:00
|
|
|
size_t PostProcessing::CalculateUniformsSize(bool user_post_process) const
|
2019-02-15 01:59:50 +00:00
|
|
|
{
|
|
|
|
// Allocate a vec4 for each uniform to simplify allocation.
|
Video: implement color correction to match the NTSC and PAL color spaces (and gamma) that GC and Wii targeted.
To further increase the accuracy of the post process phase, I've added (scRGB) HDR support, which is necessary
to fully display the PAL and NTSC-J color spaces, and also to improve the quality of post process texture samplings and
do them in linear space instead of gamma space (which is very important when playing at low resolutions).
For SDR, the quality is also slightly increased, at least if any post process runs, as the buffer is now
R10G10B10A2 (on Vulkan, DX11 and DX12) if supported; previously it was R8G8B8A8 but the alpha bits were wasted.
Gamma correction is arguably the most important thing as Dolphin on Windows outputted in "sRGB" (implicitly)
as that's what Windows expects by default, though sRGB gamma is very different from the gamma commonly used
by video standards dating to the pre HDR era (roughly gamma 2.35).
Additionally, the addition of HDR support (which is pretty straight forward and minimal), added support for
our own custom AutoHDR shaders, which would allow us to achieve decent looking HDR in Dolphin games without
having to use SpecialK or Windows 11 AutoHDR. Both of which don't necessarily play nice with older games
with strongly different and simpler lighting. HDR should also be supported in Linux.
Development of my own AutoHDR shader is almost complete and will come next.
This has been carefully tested and there should be no regression in any of the different features that Dolphin
offers, like multisampling, stereo rendering, other post processes, etc etc.
Fixes: https://bugs.dolphin-emu.org/issues/8941
Co-authored-by: EndlesslyFlowering <EndlesslyFlowering@protonmail.com>
Co-authored-by: Dogway <lin_ares@hotmail.com>
2023-06-10 08:48:05 +00:00
|
|
|
return sizeof(BuiltinUniforms) +
|
|
|
|
(user_post_process ? m_config.GetOptions().size() : 0) * sizeof(float) * 4;
|
2019-02-15 01:59:50 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
void PostProcessing::FillUniformBuffer(const MathUtil::Rectangle<int>& src,
|
Video: implement color correction to match the NTSC and PAL color spaces (and gamma) that GC and Wii targeted.
To further increase the accuracy of the post process phase, I've added (scRGB) HDR support, which is necessary
to fully display the PAL and NTSC-J color spaces, and also to improve the quality of post process texture samplings and
do them in linear space instead of gamma space (which is very important when playing at low resolutions).
For SDR, the quality is also slightly increased, at least if any post process runs, as the buffer is now
R10G10B10A2 (on Vulkan, DX11 and DX12) if supported; previously it was R8G8B8A8 but the alpha bits were wasted.
Gamma correction is arguably the most important thing as Dolphin on Windows outputted in "sRGB" (implicitly)
as that's what Windows expects by default, though sRGB gamma is very different from the gamma commonly used
by video standards dating to the pre HDR era (roughly gamma 2.35).
Additionally, the addition of HDR support (which is pretty straight forward and minimal), added support for
our own custom AutoHDR shaders, which would allow us to achieve decent looking HDR in Dolphin games without
having to use SpecialK or Windows 11 AutoHDR. Both of which don't necessarily play nice with older games
with strongly different and simpler lighting. HDR should also be supported in Linux.
Development of my own AutoHDR shader is almost complete and will come next.
This has been carefully tested and there should be no regression in any of the different features that Dolphin
offers, like multisampling, stereo rendering, other post processes, etc etc.
Fixes: https://bugs.dolphin-emu.org/issues/8941
Co-authored-by: EndlesslyFlowering <EndlesslyFlowering@protonmail.com>
Co-authored-by: Dogway <lin_ares@hotmail.com>
2023-06-10 08:48:05 +00:00
|
|
|
const AbstractTexture* src_tex, int src_layer,
|
|
|
|
const MathUtil::Rectangle<int>& dst,
|
|
|
|
const MathUtil::Rectangle<int>& wnd, u8* buffer,
|
2023-08-06 00:11:19 +00:00
|
|
|
bool user_post_process, bool intermediary_buffer)
|
2019-02-15 01:59:50 +00:00
|
|
|
{
|
|
|
|
const float rcp_src_width = 1.0f / src_tex->GetWidth();
|
|
|
|
const float rcp_src_height = 1.0f / src_tex->GetHeight();
|
|
|
|
|
Video: implement color correction to match the NTSC and PAL color spaces (and gamma) that GC and Wii targeted.
To further increase the accuracy of the post process phase, I've added (scRGB) HDR support, which is necessary
to fully display the PAL and NTSC-J color spaces, and also to improve the quality of post process texture samplings and
do them in linear space instead of gamma space (which is very important when playing at low resolutions).
For SDR, the quality is also slightly increased, at least if any post process runs, as the buffer is now
R10G10B10A2 (on Vulkan, DX11 and DX12) if supported; previously it was R8G8B8A8 but the alpha bits were wasted.
Gamma correction is arguably the most important thing as Dolphin on Windows outputted in "sRGB" (implicitly)
as that's what Windows expects by default, though sRGB gamma is very different from the gamma commonly used
by video standards dating to the pre HDR era (roughly gamma 2.35).
Additionally, the addition of HDR support (which is pretty straight forward and minimal), added support for
our own custom AutoHDR shaders, which would allow us to achieve decent looking HDR in Dolphin games without
having to use SpecialK or Windows 11 AutoHDR. Both of which don't necessarily play nice with older games
with strongly different and simpler lighting. HDR should also be supported in Linux.
Development of my own AutoHDR shader is almost complete and will come next.
This has been carefully tested and there should be no regression in any of the different features that Dolphin
offers, like multisampling, stereo rendering, other post processes, etc etc.
Fixes: https://bugs.dolphin-emu.org/issues/8941
Co-authored-by: EndlesslyFlowering <EndlesslyFlowering@protonmail.com>
Co-authored-by: Dogway <lin_ares@hotmail.com>
2023-06-10 08:48:05 +00:00
|
|
|
BuiltinUniforms builtin_uniforms;
|
|
|
|
builtin_uniforms.source_resolution = {static_cast<float>(src_tex->GetWidth()),
|
|
|
|
static_cast<float>(src_tex->GetHeight()), rcp_src_width,
|
|
|
|
rcp_src_height};
|
|
|
|
builtin_uniforms.target_resolution = {
|
|
|
|
static_cast<float>(dst.GetWidth()), static_cast<float>(dst.GetHeight()),
|
|
|
|
1.0f / static_cast<float>(dst.GetWidth()), 1.0f / static_cast<float>(dst.GetHeight())};
|
|
|
|
builtin_uniforms.window_resolution = {
|
|
|
|
static_cast<float>(wnd.GetWidth()), static_cast<float>(wnd.GetHeight()),
|
|
|
|
1.0f / static_cast<float>(wnd.GetWidth()), 1.0f / static_cast<float>(wnd.GetHeight())};
|
|
|
|
builtin_uniforms.src_rect = {static_cast<float>(src.left) * rcp_src_width,
|
|
|
|
static_cast<float>(src.top) * rcp_src_height,
|
|
|
|
static_cast<float>(src.GetWidth()) * rcp_src_width,
|
|
|
|
static_cast<float>(src.GetHeight()) * rcp_src_height};
|
|
|
|
builtin_uniforms.src_layer = static_cast<s32>(src_layer);
|
|
|
|
builtin_uniforms.time = static_cast<u32>(m_timer.ElapsedMs());
|
2023-08-06 00:11:19 +00:00
|
|
|
builtin_uniforms.graphics_api = static_cast<s32>(g_ActiveConfig.backend_info.api_type);
|
|
|
|
builtin_uniforms.intermediary_buffer = static_cast<s32>(intermediary_buffer);
|
Video: implement color correction to match the NTSC and PAL color spaces (and gamma) that GC and Wii targeted.
To further increase the accuracy of the post process phase, I've added (scRGB) HDR support, which is necessary
to fully display the PAL and NTSC-J color spaces, and also to improve the quality of post process texture samplings and
do them in linear space instead of gamma space (which is very important when playing at low resolutions).
For SDR, the quality is also slightly increased, at least if any post process runs, as the buffer is now
R10G10B10A2 (on Vulkan, DX11 and DX12) if supported; previously it was R8G8B8A8 but the alpha bits were wasted.
Gamma correction is arguably the most important thing as Dolphin on Windows outputted in "sRGB" (implicitly)
as that's what Windows expects by default, though sRGB gamma is very different from the gamma commonly used
by video standards dating to the pre HDR era (roughly gamma 2.35).
Additionally, the addition of HDR support (which is pretty straight forward and minimal), added support for
our own custom AutoHDR shaders, which would allow us to achieve decent looking HDR in Dolphin games without
having to use SpecialK or Windows 11 AutoHDR. Both of which don't necessarily play nice with older games
with strongly different and simpler lighting. HDR should also be supported in Linux.
Development of my own AutoHDR shader is almost complete and will come next.
This has been carefully tested and there should be no regression in any of the different features that Dolphin
offers, like multisampling, stereo rendering, other post processes, etc etc.
Fixes: https://bugs.dolphin-emu.org/issues/8941
Co-authored-by: EndlesslyFlowering <EndlesslyFlowering@protonmail.com>
Co-authored-by: Dogway <lin_ares@hotmail.com>
2023-06-10 08:48:05 +00:00
|
|
|
|
2023-06-27 00:23:08 +00:00
|
|
|
builtin_uniforms.resampling_method = static_cast<s32>(g_ActiveConfig.output_resampling_mode);
|
Video: implement color correction to match the NTSC and PAL color spaces (and gamma) that GC and Wii targeted.
To further increase the accuracy of the post process phase, I've added (scRGB) HDR support, which is necessary
to fully display the PAL and NTSC-J color spaces, and also to improve the quality of post process texture samplings and
do them in linear space instead of gamma space (which is very important when playing at low resolutions).
For SDR, the quality is also slightly increased, at least if any post process runs, as the buffer is now
R10G10B10A2 (on Vulkan, DX11 and DX12) if supported; previously it was R8G8B8A8 but the alpha bits were wasted.
Gamma correction is arguably the most important thing as Dolphin on Windows outputted in "sRGB" (implicitly)
as that's what Windows expects by default, though sRGB gamma is very different from the gamma commonly used
by video standards dating to the pre HDR era (roughly gamma 2.35).
Additionally, the addition of HDR support (which is pretty straight forward and minimal), added support for
our own custom AutoHDR shaders, which would allow us to achieve decent looking HDR in Dolphin games without
having to use SpecialK or Windows 11 AutoHDR. Both of which don't necessarily play nice with older games
with strongly different and simpler lighting. HDR should also be supported in Linux.
Development of my own AutoHDR shader is almost complete and will come next.
This has been carefully tested and there should be no regression in any of the different features that Dolphin
offers, like multisampling, stereo rendering, other post processes, etc etc.
Fixes: https://bugs.dolphin-emu.org/issues/8941
Co-authored-by: EndlesslyFlowering <EndlesslyFlowering@protonmail.com>
Co-authored-by: Dogway <lin_ares@hotmail.com>
2023-06-10 08:48:05 +00:00
|
|
|
// Color correction related uniforms.
|
|
|
|
// These are mainly used by the "m_default_pixel_shader",
|
|
|
|
// but should also be accessible to all other shaders.
|
|
|
|
builtin_uniforms.correct_color_space = g_ActiveConfig.color_correction.bCorrectColorSpace;
|
|
|
|
builtin_uniforms.game_color_space =
|
|
|
|
static_cast<int>(g_ActiveConfig.color_correction.game_color_space);
|
|
|
|
builtin_uniforms.correct_gamma = g_ActiveConfig.color_correction.bCorrectGamma;
|
|
|
|
builtin_uniforms.game_gamma = g_ActiveConfig.color_correction.fGameGamma;
|
|
|
|
builtin_uniforms.sdr_display_gamma_sRGB = g_ActiveConfig.color_correction.bSDRDisplayGammaSRGB;
|
|
|
|
builtin_uniforms.sdr_display_custom_gamma =
|
|
|
|
g_ActiveConfig.color_correction.fSDRDisplayCustomGamma;
|
|
|
|
// scRGB (RGBA16F) expects linear values as opposed to sRGB gamma
|
|
|
|
builtin_uniforms.linear_space_output = m_framebuffer_format == AbstractTextureFormat::RGBA16F;
|
|
|
|
// Implies ouput values can be beyond the 0-1 range
|
|
|
|
builtin_uniforms.hdr_output = m_framebuffer_format == AbstractTextureFormat::RGBA16F;
|
|
|
|
builtin_uniforms.hdr_paper_white_nits = g_ActiveConfig.color_correction.fHDRPaperWhiteNits;
|
|
|
|
// A value of 1 1 1 usually matches 80 nits in HDR
|
|
|
|
builtin_uniforms.hdr_sdr_white_nits = 80.f;
|
|
|
|
|
|
|
|
std::memcpy(buffer, &builtin_uniforms, sizeof(builtin_uniforms));
|
|
|
|
buffer += sizeof(builtin_uniforms);
|
|
|
|
|
2023-08-06 00:11:19 +00:00
|
|
|
// Don't include the custom pp shader options if they are not necessary,
|
|
|
|
// having mismatching uniforms between different shaders can cause issues on some backends
|
Video: implement color correction to match the NTSC and PAL color spaces (and gamma) that GC and Wii targeted.
To further increase the accuracy of the post process phase, I've added (scRGB) HDR support, which is necessary
to fully display the PAL and NTSC-J color spaces, and also to improve the quality of post process texture samplings and
do them in linear space instead of gamma space (which is very important when playing at low resolutions).
For SDR, the quality is also slightly increased, at least if any post process runs, as the buffer is now
R10G10B10A2 (on Vulkan, DX11 and DX12) if supported; previously it was R8G8B8A8 but the alpha bits were wasted.
Gamma correction is arguably the most important thing as Dolphin on Windows outputted in "sRGB" (implicitly)
as that's what Windows expects by default, though sRGB gamma is very different from the gamma commonly used
by video standards dating to the pre HDR era (roughly gamma 2.35).
Additionally, the addition of HDR support (which is pretty straight forward and minimal), added support for
our own custom AutoHDR shaders, which would allow us to achieve decent looking HDR in Dolphin games without
having to use SpecialK or Windows 11 AutoHDR. Both of which don't necessarily play nice with older games
with strongly different and simpler lighting. HDR should also be supported in Linux.
Development of my own AutoHDR shader is almost complete and will come next.
This has been carefully tested and there should be no regression in any of the different features that Dolphin
offers, like multisampling, stereo rendering, other post processes, etc etc.
Fixes: https://bugs.dolphin-emu.org/issues/8941
Co-authored-by: EndlesslyFlowering <EndlesslyFlowering@protonmail.com>
Co-authored-by: Dogway <lin_ares@hotmail.com>
2023-06-10 08:48:05 +00:00
|
|
|
if (!user_post_process)
|
|
|
|
return;
|
2019-02-15 01:59:50 +00:00
|
|
|
|
Video: implement color correction to match the NTSC and PAL color spaces (and gamma) that GC and Wii targeted.
To further increase the accuracy of the post process phase, I've added (scRGB) HDR support, which is necessary
to fully display the PAL and NTSC-J color spaces, and also to improve the quality of post process texture samplings and
do them in linear space instead of gamma space (which is very important when playing at low resolutions).
For SDR, the quality is also slightly increased, at least if any post process runs, as the buffer is now
R10G10B10A2 (on Vulkan, DX11 and DX12) if supported; previously it was R8G8B8A8 but the alpha bits were wasted.
Gamma correction is arguably the most important thing as Dolphin on Windows outputted in "sRGB" (implicitly)
as that's what Windows expects by default, though sRGB gamma is very different from the gamma commonly used
by video standards dating to the pre HDR era (roughly gamma 2.35).
Additionally, the addition of HDR support (which is pretty straight forward and minimal), added support for
our own custom AutoHDR shaders, which would allow us to achieve decent looking HDR in Dolphin games without
having to use SpecialK or Windows 11 AutoHDR. Both of which don't necessarily play nice with older games
with strongly different and simpler lighting. HDR should also be supported in Linux.
Development of my own AutoHDR shader is almost complete and will come next.
This has been carefully tested and there should be no regression in any of the different features that Dolphin
offers, like multisampling, stereo rendering, other post processes, etc etc.
Fixes: https://bugs.dolphin-emu.org/issues/8941
Co-authored-by: EndlesslyFlowering <EndlesslyFlowering@protonmail.com>
Co-authored-by: Dogway <lin_ares@hotmail.com>
2023-06-10 08:48:05 +00:00
|
|
|
for (auto& it : m_config.GetOptions())
|
2019-02-15 01:59:50 +00:00
|
|
|
{
|
|
|
|
union
|
|
|
|
{
|
|
|
|
u32 as_bool[4];
|
|
|
|
s32 as_int[4];
|
|
|
|
float as_float[4];
|
|
|
|
} value = {};
|
|
|
|
|
|
|
|
switch (it.second.m_type)
|
|
|
|
{
|
2022-02-17 17:54:07 +00:00
|
|
|
case PostProcessingConfiguration::ConfigurationOption::OptionType::Bool:
|
2019-02-15 01:59:50 +00:00
|
|
|
value.as_bool[0] = it.second.m_bool_value ? 1 : 0;
|
|
|
|
break;
|
|
|
|
|
2022-02-17 17:54:07 +00:00
|
|
|
case PostProcessingConfiguration::ConfigurationOption::OptionType::Integer:
|
2023-06-07 23:54:46 +00:00
|
|
|
ASSERT(it.second.m_integer_values.size() <= 4);
|
2019-02-15 01:59:50 +00:00
|
|
|
std::copy_n(it.second.m_integer_values.begin(), it.second.m_integer_values.size(),
|
|
|
|
value.as_int);
|
|
|
|
break;
|
|
|
|
|
2022-02-17 17:54:07 +00:00
|
|
|
case PostProcessingConfiguration::ConfigurationOption::OptionType::Float:
|
2023-06-07 23:54:46 +00:00
|
|
|
ASSERT(it.second.m_float_values.size() <= 4);
|
2019-02-15 01:59:50 +00:00
|
|
|
std::copy_n(it.second.m_float_values.begin(), it.second.m_float_values.size(),
|
|
|
|
value.as_float);
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
|
Video: implement color correction to match the NTSC and PAL color spaces (and gamma) that GC and Wii targeted.
To further increase the accuracy of the post process phase, I've added (scRGB) HDR support, which is necessary
to fully display the PAL and NTSC-J color spaces, and also to improve the quality of post process texture samplings and
do them in linear space instead of gamma space (which is very important when playing at low resolutions).
For SDR, the quality is also slightly increased, at least if any post process runs, as the buffer is now
R10G10B10A2 (on Vulkan, DX11 and DX12) if supported; previously it was R8G8B8A8 but the alpha bits were wasted.
Gamma correction is arguably the most important thing as Dolphin on Windows outputted in "sRGB" (implicitly)
as that's what Windows expects by default, though sRGB gamma is very different from the gamma commonly used
by video standards dating to the pre HDR era (roughly gamma 2.35).
Additionally, the addition of HDR support (which is pretty straight forward and minimal), added support for
our own custom AutoHDR shaders, which would allow us to achieve decent looking HDR in Dolphin games without
having to use SpecialK or Windows 11 AutoHDR. Both of which don't necessarily play nice with older games
with strongly different and simpler lighting. HDR should also be supported in Linux.
Development of my own AutoHDR shader is almost complete and will come next.
This has been carefully tested and there should be no regression in any of the different features that Dolphin
offers, like multisampling, stereo rendering, other post processes, etc etc.
Fixes: https://bugs.dolphin-emu.org/issues/8941
Co-authored-by: EndlesslyFlowering <EndlesslyFlowering@protonmail.com>
Co-authored-by: Dogway <lin_ares@hotmail.com>
2023-06-10 08:48:05 +00:00
|
|
|
it.second.m_dirty = false;
|
|
|
|
|
|
|
|
std::memcpy(buffer, &value, sizeof(value));
|
|
|
|
buffer += sizeof(value);
|
2019-02-15 01:59:50 +00:00
|
|
|
}
|
Video: implement color correction to match the NTSC and PAL color spaces (and gamma) that GC and Wii targeted.
To further increase the accuracy of the post process phase, I've added (scRGB) HDR support, which is necessary
to fully display the PAL and NTSC-J color spaces, and also to improve the quality of post process texture samplings and
do them in linear space instead of gamma space (which is very important when playing at low resolutions).
For SDR, the quality is also slightly increased, at least if any post process runs, as the buffer is now
R10G10B10A2 (on Vulkan, DX11 and DX12) if supported; previously it was R8G8B8A8 but the alpha bits were wasted.
Gamma correction is arguably the most important thing as Dolphin on Windows outputted in "sRGB" (implicitly)
as that's what Windows expects by default, though sRGB gamma is very different from the gamma commonly used
by video standards dating to the pre HDR era (roughly gamma 2.35).
Additionally, the addition of HDR support (which is pretty straight forward and minimal), added support for
our own custom AutoHDR shaders, which would allow us to achieve decent looking HDR in Dolphin games without
having to use SpecialK or Windows 11 AutoHDR. Both of which don't necessarily play nice with older games
with strongly different and simpler lighting. HDR should also be supported in Linux.
Development of my own AutoHDR shader is almost complete and will come next.
This has been carefully tested and there should be no regression in any of the different features that Dolphin
offers, like multisampling, stereo rendering, other post processes, etc etc.
Fixes: https://bugs.dolphin-emu.org/issues/8941
Co-authored-by: EndlesslyFlowering <EndlesslyFlowering@protonmail.com>
Co-authored-by: Dogway <lin_ares@hotmail.com>
2023-06-10 08:48:05 +00:00
|
|
|
|
|
|
|
m_config.SetDirty(false);
|
2019-02-15 01:59:50 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
bool PostProcessing::CompilePixelShader()
|
|
|
|
{
|
Video: implement color correction to match the NTSC and PAL color spaces (and gamma) that GC and Wii targeted.
To further increase the accuracy of the post process phase, I've added (scRGB) HDR support, which is necessary
to fully display the PAL and NTSC-J color spaces, and also to improve the quality of post process texture samplings and
do them in linear space instead of gamma space (which is very important when playing at low resolutions).
For SDR, the quality is also slightly increased, at least if any post process runs, as the buffer is now
R10G10B10A2 (on Vulkan, DX11 and DX12) if supported; previously it was R8G8B8A8 but the alpha bits were wasted.
Gamma correction is arguably the most important thing as Dolphin on Windows outputted in "sRGB" (implicitly)
as that's what Windows expects by default, though sRGB gamma is very different from the gamma commonly used
by video standards dating to the pre HDR era (roughly gamma 2.35).
Additionally, the addition of HDR support (which is pretty straight forward and minimal), added support for
our own custom AutoHDR shaders, which would allow us to achieve decent looking HDR in Dolphin games without
having to use SpecialK or Windows 11 AutoHDR. Both of which don't necessarily play nice with older games
with strongly different and simpler lighting. HDR should also be supported in Linux.
Development of my own AutoHDR shader is almost complete and will come next.
This has been carefully tested and there should be no regression in any of the different features that Dolphin
offers, like multisampling, stereo rendering, other post processes, etc etc.
Fixes: https://bugs.dolphin-emu.org/issues/8941
Co-authored-by: EndlesslyFlowering <EndlesslyFlowering@protonmail.com>
Co-authored-by: Dogway <lin_ares@hotmail.com>
2023-06-10 08:48:05 +00:00
|
|
|
m_default_pixel_shader.reset();
|
2019-02-15 01:59:50 +00:00
|
|
|
m_pixel_shader.reset();
|
|
|
|
|
Video: implement color correction to match the NTSC and PAL color spaces (and gamma) that GC and Wii targeted.
To further increase the accuracy of the post process phase, I've added (scRGB) HDR support, which is necessary
to fully display the PAL and NTSC-J color spaces, and also to improve the quality of post process texture samplings and
do them in linear space instead of gamma space (which is very important when playing at low resolutions).
For SDR, the quality is also slightly increased, at least if any post process runs, as the buffer is now
R10G10B10A2 (on Vulkan, DX11 and DX12) if supported; previously it was R8G8B8A8 but the alpha bits were wasted.
Gamma correction is arguably the most important thing as Dolphin on Windows outputted in "sRGB" (implicitly)
as that's what Windows expects by default, though sRGB gamma is very different from the gamma commonly used
by video standards dating to the pre HDR era (roughly gamma 2.35).
Additionally, the addition of HDR support (which is pretty straight forward and minimal), added support for
our own custom AutoHDR shaders, which would allow us to achieve decent looking HDR in Dolphin games without
having to use SpecialK or Windows 11 AutoHDR. Both of which don't necessarily play nice with older games
with strongly different and simpler lighting. HDR should also be supported in Linux.
Development of my own AutoHDR shader is almost complete and will come next.
This has been carefully tested and there should be no regression in any of the different features that Dolphin
offers, like multisampling, stereo rendering, other post processes, etc etc.
Fixes: https://bugs.dolphin-emu.org/issues/8941
Co-authored-by: EndlesslyFlowering <EndlesslyFlowering@protonmail.com>
Co-authored-by: Dogway <lin_ares@hotmail.com>
2023-06-10 08:48:05 +00:00
|
|
|
// Generate GLSL and compile the new shaders:
|
|
|
|
|
|
|
|
std::string default_pixel_shader_code;
|
|
|
|
if (LoadShaderFromFile(s_default_pixel_shader_name, "", default_pixel_shader_code))
|
|
|
|
{
|
|
|
|
m_default_pixel_shader = g_gfx->CreateShaderFromSource(
|
|
|
|
ShaderStage::Pixel, GetHeader(false) + default_pixel_shader_code + GetFooter(),
|
|
|
|
"Default post-processing pixel shader");
|
|
|
|
// We continue even if all of this failed, it doesn't matter
|
|
|
|
m_default_uniform_staging_buffer.resize(CalculateUniformsSize(false));
|
|
|
|
}
|
|
|
|
else
|
|
|
|
{
|
|
|
|
m_default_uniform_staging_buffer.resize(0);
|
|
|
|
}
|
|
|
|
|
2019-02-15 01:59:50 +00:00
|
|
|
m_config.LoadShader(g_ActiveConfig.sPostProcessingShader);
|
2023-01-26 22:34:59 +00:00
|
|
|
m_pixel_shader = g_gfx->CreateShaderFromSource(
|
Video: implement color correction to match the NTSC and PAL color spaces (and gamma) that GC and Wii targeted.
To further increase the accuracy of the post process phase, I've added (scRGB) HDR support, which is necessary
to fully display the PAL and NTSC-J color spaces, and also to improve the quality of post process texture samplings and
do them in linear space instead of gamma space (which is very important when playing at low resolutions).
For SDR, the quality is also slightly increased, at least if any post process runs, as the buffer is now
R10G10B10A2 (on Vulkan, DX11 and DX12) if supported; previously it was R8G8B8A8 but the alpha bits were wasted.
Gamma correction is arguably the most important thing as Dolphin on Windows outputted in "sRGB" (implicitly)
as that's what Windows expects by default, though sRGB gamma is very different from the gamma commonly used
by video standards dating to the pre HDR era (roughly gamma 2.35).
Additionally, the addition of HDR support (which is pretty straight forward and minimal), added support for
our own custom AutoHDR shaders, which would allow us to achieve decent looking HDR in Dolphin games without
having to use SpecialK or Windows 11 AutoHDR. Both of which don't necessarily play nice with older games
with strongly different and simpler lighting. HDR should also be supported in Linux.
Development of my own AutoHDR shader is almost complete and will come next.
This has been carefully tested and there should be no regression in any of the different features that Dolphin
offers, like multisampling, stereo rendering, other post processes, etc etc.
Fixes: https://bugs.dolphin-emu.org/issues/8941
Co-authored-by: EndlesslyFlowering <EndlesslyFlowering@protonmail.com>
Co-authored-by: Dogway <lin_ares@hotmail.com>
2023-06-10 08:48:05 +00:00
|
|
|
ShaderStage::Pixel, GetHeader(true) + m_config.GetShaderCode() + GetFooter(),
|
|
|
|
fmt::format("User post-processing pixel shader: {}", m_config.GetShader()));
|
2019-02-15 01:59:50 +00:00
|
|
|
if (!m_pixel_shader)
|
|
|
|
{
|
Video: implement color correction to match the NTSC and PAL color spaces (and gamma) that GC and Wii targeted.
To further increase the accuracy of the post process phase, I've added (scRGB) HDR support, which is necessary
to fully display the PAL and NTSC-J color spaces, and also to improve the quality of post process texture samplings and
do them in linear space instead of gamma space (which is very important when playing at low resolutions).
For SDR, the quality is also slightly increased, at least if any post process runs, as the buffer is now
R10G10B10A2 (on Vulkan, DX11 and DX12) if supported; previously it was R8G8B8A8 but the alpha bits were wasted.
Gamma correction is arguably the most important thing as Dolphin on Windows outputted in "sRGB" (implicitly)
as that's what Windows expects by default, though sRGB gamma is very different from the gamma commonly used
by video standards dating to the pre HDR era (roughly gamma 2.35).
Additionally, the addition of HDR support (which is pretty straight forward and minimal), added support for
our own custom AutoHDR shaders, which would allow us to achieve decent looking HDR in Dolphin games without
having to use SpecialK or Windows 11 AutoHDR. Both of which don't necessarily play nice with older games
with strongly different and simpler lighting. HDR should also be supported in Linux.
Development of my own AutoHDR shader is almost complete and will come next.
This has been carefully tested and there should be no regression in any of the different features that Dolphin
offers, like multisampling, stereo rendering, other post processes, etc etc.
Fixes: https://bugs.dolphin-emu.org/issues/8941
Co-authored-by: EndlesslyFlowering <EndlesslyFlowering@protonmail.com>
Co-authored-by: Dogway <lin_ares@hotmail.com>
2023-06-10 08:48:05 +00:00
|
|
|
PanicAlertFmt("Failed to compile user post-processing shader {}", m_config.GetShader());
|
2019-02-15 01:59:50 +00:00
|
|
|
|
|
|
|
// Use default shader.
|
|
|
|
m_config.LoadDefaultShader();
|
2023-01-26 22:34:59 +00:00
|
|
|
m_pixel_shader = g_gfx->CreateShaderFromSource(
|
Video: implement color correction to match the NTSC and PAL color spaces (and gamma) that GC and Wii targeted.
To further increase the accuracy of the post process phase, I've added (scRGB) HDR support, which is necessary
to fully display the PAL and NTSC-J color spaces, and also to improve the quality of post process texture samplings and
do them in linear space instead of gamma space (which is very important when playing at low resolutions).
For SDR, the quality is also slightly increased, at least if any post process runs, as the buffer is now
R10G10B10A2 (on Vulkan, DX11 and DX12) if supported; previously it was R8G8B8A8 but the alpha bits were wasted.
Gamma correction is arguably the most important thing as Dolphin on Windows outputted in "sRGB" (implicitly)
as that's what Windows expects by default, though sRGB gamma is very different from the gamma commonly used
by video standards dating to the pre HDR era (roughly gamma 2.35).
Additionally, the addition of HDR support (which is pretty straight forward and minimal), added support for
our own custom AutoHDR shaders, which would allow us to achieve decent looking HDR in Dolphin games without
having to use SpecialK or Windows 11 AutoHDR. Both of which don't necessarily play nice with older games
with strongly different and simpler lighting. HDR should also be supported in Linux.
Development of my own AutoHDR shader is almost complete and will come next.
This has been carefully tested and there should be no regression in any of the different features that Dolphin
offers, like multisampling, stereo rendering, other post processes, etc etc.
Fixes: https://bugs.dolphin-emu.org/issues/8941
Co-authored-by: EndlesslyFlowering <EndlesslyFlowering@protonmail.com>
Co-authored-by: Dogway <lin_ares@hotmail.com>
2023-06-10 08:48:05 +00:00
|
|
|
ShaderStage::Pixel, GetHeader(true) + m_config.GetShaderCode() + GetFooter(),
|
|
|
|
"Default user post-processing pixel shader");
|
2019-02-15 01:59:50 +00:00
|
|
|
if (!m_pixel_shader)
|
Video: implement color correction to match the NTSC and PAL color spaces (and gamma) that GC and Wii targeted.
To further increase the accuracy of the post process phase, I've added (scRGB) HDR support, which is necessary
to fully display the PAL and NTSC-J color spaces, and also to improve the quality of post process texture samplings and
do them in linear space instead of gamma space (which is very important when playing at low resolutions).
For SDR, the quality is also slightly increased, at least if any post process runs, as the buffer is now
R10G10B10A2 (on Vulkan, DX11 and DX12) if supported; previously it was R8G8B8A8 but the alpha bits were wasted.
Gamma correction is arguably the most important thing as Dolphin on Windows outputted in "sRGB" (implicitly)
as that's what Windows expects by default, though sRGB gamma is very different from the gamma commonly used
by video standards dating to the pre HDR era (roughly gamma 2.35).
Additionally, the addition of HDR support (which is pretty straight forward and minimal), added support for
our own custom AutoHDR shaders, which would allow us to achieve decent looking HDR in Dolphin games without
having to use SpecialK or Windows 11 AutoHDR. Both of which don't necessarily play nice with older games
with strongly different and simpler lighting. HDR should also be supported in Linux.
Development of my own AutoHDR shader is almost complete and will come next.
This has been carefully tested and there should be no regression in any of the different features that Dolphin
offers, like multisampling, stereo rendering, other post processes, etc etc.
Fixes: https://bugs.dolphin-emu.org/issues/8941
Co-authored-by: EndlesslyFlowering <EndlesslyFlowering@protonmail.com>
Co-authored-by: Dogway <lin_ares@hotmail.com>
2023-06-10 08:48:05 +00:00
|
|
|
{
|
|
|
|
m_uniform_staging_buffer.resize(0);
|
2019-02-15 01:59:50 +00:00
|
|
|
return false;
|
Video: implement color correction to match the NTSC and PAL color spaces (and gamma) that GC and Wii targeted.
To further increase the accuracy of the post process phase, I've added (scRGB) HDR support, which is necessary
to fully display the PAL and NTSC-J color spaces, and also to improve the quality of post process texture samplings and
do them in linear space instead of gamma space (which is very important when playing at low resolutions).
For SDR, the quality is also slightly increased, at least if any post process runs, as the buffer is now
R10G10B10A2 (on Vulkan, DX11 and DX12) if supported; previously it was R8G8B8A8 but the alpha bits were wasted.
Gamma correction is arguably the most important thing as Dolphin on Windows outputted in "sRGB" (implicitly)
as that's what Windows expects by default, though sRGB gamma is very different from the gamma commonly used
by video standards dating to the pre HDR era (roughly gamma 2.35).
Additionally, the addition of HDR support (which is pretty straight forward and minimal), added support for
our own custom AutoHDR shaders, which would allow us to achieve decent looking HDR in Dolphin games without
having to use SpecialK or Windows 11 AutoHDR. Both of which don't necessarily play nice with older games
with strongly different and simpler lighting. HDR should also be supported in Linux.
Development of my own AutoHDR shader is almost complete and will come next.
This has been carefully tested and there should be no regression in any of the different features that Dolphin
offers, like multisampling, stereo rendering, other post processes, etc etc.
Fixes: https://bugs.dolphin-emu.org/issues/8941
Co-authored-by: EndlesslyFlowering <EndlesslyFlowering@protonmail.com>
Co-authored-by: Dogway <lin_ares@hotmail.com>
2023-06-10 08:48:05 +00:00
|
|
|
}
|
2019-02-15 01:59:50 +00:00
|
|
|
}
|
|
|
|
|
Video: implement color correction to match the NTSC and PAL color spaces (and gamma) that GC and Wii targeted.
To further increase the accuracy of the post process phase, I've added (scRGB) HDR support, which is necessary
to fully display the PAL and NTSC-J color spaces, and also to improve the quality of post process texture samplings and
do them in linear space instead of gamma space (which is very important when playing at low resolutions).
For SDR, the quality is also slightly increased, at least if any post process runs, as the buffer is now
R10G10B10A2 (on Vulkan, DX11 and DX12) if supported; previously it was R8G8B8A8 but the alpha bits were wasted.
Gamma correction is arguably the most important thing as Dolphin on Windows outputted in "sRGB" (implicitly)
as that's what Windows expects by default, though sRGB gamma is very different from the gamma commonly used
by video standards dating to the pre HDR era (roughly gamma 2.35).
Additionally, the addition of HDR support (which is pretty straight forward and minimal), added support for
our own custom AutoHDR shaders, which would allow us to achieve decent looking HDR in Dolphin games without
having to use SpecialK or Windows 11 AutoHDR. Both of which don't necessarily play nice with older games
with strongly different and simpler lighting. HDR should also be supported in Linux.
Development of my own AutoHDR shader is almost complete and will come next.
This has been carefully tested and there should be no regression in any of the different features that Dolphin
offers, like multisampling, stereo rendering, other post processes, etc etc.
Fixes: https://bugs.dolphin-emu.org/issues/8941
Co-authored-by: EndlesslyFlowering <EndlesslyFlowering@protonmail.com>
Co-authored-by: Dogway <lin_ares@hotmail.com>
2023-06-10 08:48:05 +00:00
|
|
|
m_uniform_staging_buffer.resize(CalculateUniformsSize(true));
|
2019-02-15 01:59:50 +00:00
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
2023-12-11 22:07:56 +00:00
|
|
|
static bool UseGeometryShaderForPostProcess(bool is_intermediary_buffer)
|
Video: implement color correction to match the NTSC and PAL color spaces (and gamma) that GC and Wii targeted.
To further increase the accuracy of the post process phase, I've added (scRGB) HDR support, which is necessary
to fully display the PAL and NTSC-J color spaces, and also to improve the quality of post process texture samplings and
do them in linear space instead of gamma space (which is very important when playing at low resolutions).
For SDR, the quality is also slightly increased, at least if any post process runs, as the buffer is now
R10G10B10A2 (on Vulkan, DX11 and DX12) if supported; previously it was R8G8B8A8 but the alpha bits were wasted.
Gamma correction is arguably the most important thing as Dolphin on Windows outputted in "sRGB" (implicitly)
as that's what Windows expects by default, though sRGB gamma is very different from the gamma commonly used
by video standards dating to the pre HDR era (roughly gamma 2.35).
Additionally, the addition of HDR support (which is pretty straight forward and minimal), added support for
our own custom AutoHDR shaders, which would allow us to achieve decent looking HDR in Dolphin games without
having to use SpecialK or Windows 11 AutoHDR. Both of which don't necessarily play nice with older games
with strongly different and simpler lighting. HDR should also be supported in Linux.
Development of my own AutoHDR shader is almost complete and will come next.
This has been carefully tested and there should be no regression in any of the different features that Dolphin
offers, like multisampling, stereo rendering, other post processes, etc etc.
Fixes: https://bugs.dolphin-emu.org/issues/8941
Co-authored-by: EndlesslyFlowering <EndlesslyFlowering@protonmail.com>
Co-authored-by: Dogway <lin_ares@hotmail.com>
2023-06-10 08:48:05 +00:00
|
|
|
{
|
|
|
|
// We only return true on stereo modes that need to copy
|
|
|
|
// both source texture layers into the target texture layers.
|
|
|
|
// Any other case is handled manually with multiple copies, thus
|
|
|
|
// it doesn't need a geom shader.
|
|
|
|
switch (g_ActiveConfig.stereo_mode)
|
|
|
|
{
|
|
|
|
case StereoMode::QuadBuffer:
|
|
|
|
return !g_ActiveConfig.backend_info.bUsesExplictQuadBuffering;
|
|
|
|
case StereoMode::Anaglyph:
|
|
|
|
case StereoMode::Passive:
|
|
|
|
return is_intermediary_buffer;
|
|
|
|
case StereoMode::SBS:
|
|
|
|
case StereoMode::TAB:
|
|
|
|
case StereoMode::Off:
|
|
|
|
default:
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2019-02-15 01:59:50 +00:00
|
|
|
bool PostProcessing::CompilePipeline()
|
|
|
|
{
|
Video: implement color correction to match the NTSC and PAL color spaces (and gamma) that GC and Wii targeted.
To further increase the accuracy of the post process phase, I've added (scRGB) HDR support, which is necessary
to fully display the PAL and NTSC-J color spaces, and also to improve the quality of post process texture samplings and
do them in linear space instead of gamma space (which is very important when playing at low resolutions).
For SDR, the quality is also slightly increased, at least if any post process runs, as the buffer is now
R10G10B10A2 (on Vulkan, DX11 and DX12) if supported; previously it was R8G8B8A8 but the alpha bits were wasted.
Gamma correction is arguably the most important thing as Dolphin on Windows outputted in "sRGB" (implicitly)
as that's what Windows expects by default, though sRGB gamma is very different from the gamma commonly used
by video standards dating to the pre HDR era (roughly gamma 2.35).
Additionally, the addition of HDR support (which is pretty straight forward and minimal), added support for
our own custom AutoHDR shaders, which would allow us to achieve decent looking HDR in Dolphin games without
having to use SpecialK or Windows 11 AutoHDR. Both of which don't necessarily play nice with older games
with strongly different and simpler lighting. HDR should also be supported in Linux.
Development of my own AutoHDR shader is almost complete and will come next.
This has been carefully tested and there should be no regression in any of the different features that Dolphin
offers, like multisampling, stereo rendering, other post processes, etc etc.
Fixes: https://bugs.dolphin-emu.org/issues/8941
Co-authored-by: EndlesslyFlowering <EndlesslyFlowering@protonmail.com>
Co-authored-by: Dogway <lin_ares@hotmail.com>
2023-06-10 08:48:05 +00:00
|
|
|
// Not needed. Some backends don't like making pipelines with no targets,
|
|
|
|
// and in any case, we don't need to render anything if that happened.
|
2023-01-29 20:35:23 +00:00
|
|
|
if (m_framebuffer_format == AbstractTextureFormat::Undefined)
|
Video: implement color correction to match the NTSC and PAL color spaces (and gamma) that GC and Wii targeted.
To further increase the accuracy of the post process phase, I've added (scRGB) HDR support, which is necessary
to fully display the PAL and NTSC-J color spaces, and also to improve the quality of post process texture samplings and
do them in linear space instead of gamma space (which is very important when playing at low resolutions).
For SDR, the quality is also slightly increased, at least if any post process runs, as the buffer is now
R10G10B10A2 (on Vulkan, DX11 and DX12) if supported; previously it was R8G8B8A8 but the alpha bits were wasted.
Gamma correction is arguably the most important thing as Dolphin on Windows outputted in "sRGB" (implicitly)
as that's what Windows expects by default, though sRGB gamma is very different from the gamma commonly used
by video standards dating to the pre HDR era (roughly gamma 2.35).
Additionally, the addition of HDR support (which is pretty straight forward and minimal), added support for
our own custom AutoHDR shaders, which would allow us to achieve decent looking HDR in Dolphin games without
having to use SpecialK or Windows 11 AutoHDR. Both of which don't necessarily play nice with older games
with strongly different and simpler lighting. HDR should also be supported in Linux.
Development of my own AutoHDR shader is almost complete and will come next.
This has been carefully tested and there should be no regression in any of the different features that Dolphin
offers, like multisampling, stereo rendering, other post processes, etc etc.
Fixes: https://bugs.dolphin-emu.org/issues/8941
Co-authored-by: EndlesslyFlowering <EndlesslyFlowering@protonmail.com>
Co-authored-by: Dogway <lin_ares@hotmail.com>
2023-06-10 08:48:05 +00:00
|
|
|
return true;
|
|
|
|
|
|
|
|
// If this is true, the "m_default_pipeline" won't be the only one that runs
|
|
|
|
const bool needs_intermediary_buffer = NeedsIntermediaryBuffer();
|
2023-01-29 20:35:23 +00:00
|
|
|
|
2019-02-15 01:59:50 +00:00
|
|
|
AbstractPipelineConfig config = {};
|
2023-08-06 00:11:19 +00:00
|
|
|
config.vertex_shader = m_default_vertex_shader.get();
|
Video: implement color correction to match the NTSC and PAL color spaces (and gamma) that GC and Wii targeted.
To further increase the accuracy of the post process phase, I've added (scRGB) HDR support, which is necessary
to fully display the PAL and NTSC-J color spaces, and also to improve the quality of post process texture samplings and
do them in linear space instead of gamma space (which is very important when playing at low resolutions).
For SDR, the quality is also slightly increased, at least if any post process runs, as the buffer is now
R10G10B10A2 (on Vulkan, DX11 and DX12) if supported; previously it was R8G8B8A8 but the alpha bits were wasted.
Gamma correction is arguably the most important thing as Dolphin on Windows outputted in "sRGB" (implicitly)
as that's what Windows expects by default, though sRGB gamma is very different from the gamma commonly used
by video standards dating to the pre HDR era (roughly gamma 2.35).
Additionally, the addition of HDR support (which is pretty straight forward and minimal), added support for
our own custom AutoHDR shaders, which would allow us to achieve decent looking HDR in Dolphin games without
having to use SpecialK or Windows 11 AutoHDR. Both of which don't necessarily play nice with older games
with strongly different and simpler lighting. HDR should also be supported in Linux.
Development of my own AutoHDR shader is almost complete and will come next.
This has been carefully tested and there should be no regression in any of the different features that Dolphin
offers, like multisampling, stereo rendering, other post processes, etc etc.
Fixes: https://bugs.dolphin-emu.org/issues/8941
Co-authored-by: EndlesslyFlowering <EndlesslyFlowering@protonmail.com>
Co-authored-by: Dogway <lin_ares@hotmail.com>
2023-06-10 08:48:05 +00:00
|
|
|
// This geometry shader will take care of reading both layer 0 and 1 on the source texture,
|
|
|
|
// and writing to both layer 0 and 1 on the render target.
|
|
|
|
config.geometry_shader = UseGeometryShaderForPostProcess(needs_intermediary_buffer) ?
|
|
|
|
g_shader_cache->GetTexcoordGeometryShader() :
|
|
|
|
nullptr;
|
|
|
|
config.pixel_shader = m_default_pixel_shader.get();
|
2019-02-15 01:59:50 +00:00
|
|
|
config.rasterization_state = RenderState::GetNoCullRasterizationState(PrimitiveType::Triangles);
|
|
|
|
config.depth_state = RenderState::GetNoDepthTestingDepthState();
|
|
|
|
config.blending_state = RenderState::GetNoBlendingBlendState();
|
Video: implement color correction to match the NTSC and PAL color spaces (and gamma) that GC and Wii targeted.
To further increase the accuracy of the post process phase, I've added (scRGB) HDR support, which is necessary
to fully display the PAL and NTSC-J color spaces, and also to improve the quality of post process texture samplings and
do them in linear space instead of gamma space (which is very important when playing at low resolutions).
For SDR, the quality is also slightly increased, at least if any post process runs, as the buffer is now
R10G10B10A2 (on Vulkan, DX11 and DX12) if supported; previously it was R8G8B8A8 but the alpha bits were wasted.
Gamma correction is arguably the most important thing as Dolphin on Windows outputted in "sRGB" (implicitly)
as that's what Windows expects by default, though sRGB gamma is very different from the gamma commonly used
by video standards dating to the pre HDR era (roughly gamma 2.35).
Additionally, the addition of HDR support (which is pretty straight forward and minimal), added support for
our own custom AutoHDR shaders, which would allow us to achieve decent looking HDR in Dolphin games without
having to use SpecialK or Windows 11 AutoHDR. Both of which don't necessarily play nice with older games
with strongly different and simpler lighting. HDR should also be supported in Linux.
Development of my own AutoHDR shader is almost complete and will come next.
This has been carefully tested and there should be no regression in any of the different features that Dolphin
offers, like multisampling, stereo rendering, other post processes, etc etc.
Fixes: https://bugs.dolphin-emu.org/issues/8941
Co-authored-by: EndlesslyFlowering <EndlesslyFlowering@protonmail.com>
Co-authored-by: Dogway <lin_ares@hotmail.com>
2023-06-10 08:48:05 +00:00
|
|
|
config.framebuffer_state = RenderState::GetColorFramebufferState(
|
|
|
|
needs_intermediary_buffer ? s_intermediary_buffer_format : m_framebuffer_format);
|
2019-02-15 01:59:50 +00:00
|
|
|
config.usage = AbstractPipelineUsage::Utility;
|
Video: implement color correction to match the NTSC and PAL color spaces (and gamma) that GC and Wii targeted.
To further increase the accuracy of the post process phase, I've added (scRGB) HDR support, which is necessary
to fully display the PAL and NTSC-J color spaces, and also to improve the quality of post process texture samplings and
do them in linear space instead of gamma space (which is very important when playing at low resolutions).
For SDR, the quality is also slightly increased, at least if any post process runs, as the buffer is now
R10G10B10A2 (on Vulkan, DX11 and DX12) if supported; previously it was R8G8B8A8 but the alpha bits were wasted.
Gamma correction is arguably the most important thing as Dolphin on Windows outputted in "sRGB" (implicitly)
as that's what Windows expects by default, though sRGB gamma is very different from the gamma commonly used
by video standards dating to the pre HDR era (roughly gamma 2.35).
Additionally, the addition of HDR support (which is pretty straight forward and minimal), added support for
our own custom AutoHDR shaders, which would allow us to achieve decent looking HDR in Dolphin games without
having to use SpecialK or Windows 11 AutoHDR. Both of which don't necessarily play nice with older games
with strongly different and simpler lighting. HDR should also be supported in Linux.
Development of my own AutoHDR shader is almost complete and will come next.
This has been carefully tested and there should be no regression in any of the different features that Dolphin
offers, like multisampling, stereo rendering, other post processes, etc etc.
Fixes: https://bugs.dolphin-emu.org/issues/8941
Co-authored-by: EndlesslyFlowering <EndlesslyFlowering@protonmail.com>
Co-authored-by: Dogway <lin_ares@hotmail.com>
2023-06-10 08:48:05 +00:00
|
|
|
// We continue even if it failed, it will be skipped later on
|
|
|
|
if (config.pixel_shader)
|
|
|
|
m_default_pipeline = g_gfx->CreatePipeline(config);
|
|
|
|
|
2023-08-06 00:11:19 +00:00
|
|
|
config.vertex_shader = m_vertex_shader.get();
|
Video: implement color correction to match the NTSC and PAL color spaces (and gamma) that GC and Wii targeted.
To further increase the accuracy of the post process phase, I've added (scRGB) HDR support, which is necessary
to fully display the PAL and NTSC-J color spaces, and also to improve the quality of post process texture samplings and
do them in linear space instead of gamma space (which is very important when playing at low resolutions).
For SDR, the quality is also slightly increased, at least if any post process runs, as the buffer is now
R10G10B10A2 (on Vulkan, DX11 and DX12) if supported; previously it was R8G8B8A8 but the alpha bits were wasted.
Gamma correction is arguably the most important thing as Dolphin on Windows outputted in "sRGB" (implicitly)
as that's what Windows expects by default, though sRGB gamma is very different from the gamma commonly used
by video standards dating to the pre HDR era (roughly gamma 2.35).
Additionally, the addition of HDR support (which is pretty straight forward and minimal), added support for
our own custom AutoHDR shaders, which would allow us to achieve decent looking HDR in Dolphin games without
having to use SpecialK or Windows 11 AutoHDR. Both of which don't necessarily play nice with older games
with strongly different and simpler lighting. HDR should also be supported in Linux.
Development of my own AutoHDR shader is almost complete and will come next.
This has been carefully tested and there should be no regression in any of the different features that Dolphin
offers, like multisampling, stereo rendering, other post processes, etc etc.
Fixes: https://bugs.dolphin-emu.org/issues/8941
Co-authored-by: EndlesslyFlowering <EndlesslyFlowering@protonmail.com>
Co-authored-by: Dogway <lin_ares@hotmail.com>
2023-06-10 08:48:05 +00:00
|
|
|
config.geometry_shader = UseGeometryShaderForPostProcess(false) ?
|
|
|
|
g_shader_cache->GetTexcoordGeometryShader() :
|
|
|
|
nullptr;
|
|
|
|
config.pixel_shader = m_pixel_shader.get();
|
|
|
|
config.framebuffer_state = RenderState::GetColorFramebufferState(m_framebuffer_format);
|
2023-01-26 22:34:59 +00:00
|
|
|
m_pipeline = g_gfx->CreatePipeline(config);
|
2019-02-15 01:59:50 +00:00
|
|
|
if (!m_pipeline)
|
|
|
|
return false;
|
|
|
|
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
} // namespace VideoCommon
|