2015-05-24 06:55:12 +02:00
|
|
|
// Copyright 2014 Dolphin Emulator Project
|
2021-07-05 03:22:19 +02:00
|
|
|
// SPDX-License-Identifier: GPL-2.0-or-later
|
2014-07-29 18:47:56 +02:00
|
|
|
|
|
|
|
#pragma once
|
|
|
|
|
|
|
|
#include <map>
|
2019-07-17 02:18:48 +02:00
|
|
|
#include <memory>
|
2014-07-29 18:47:56 +02:00
|
|
|
#include <string>
|
|
|
|
#include <vector>
|
|
|
|
|
2016-01-17 22:54:31 +01:00
|
|
|
#include "Common/CommonTypes.h"
|
2019-07-17 02:18:48 +02:00
|
|
|
#include "Common/MathUtil.h"
|
2014-07-29 18:47:56 +02:00
|
|
|
#include "Common/Timer.h"
|
2019-02-15 02:59:50 +01:00
|
|
|
#include "VideoCommon/TextureConfig.h"
|
2014-10-18 09:32:24 +02:00
|
|
|
|
2019-02-15 02:59:50 +01:00
|
|
|
class AbstractPipeline;
|
|
|
|
class AbstractShader;
|
2019-07-17 02:18:48 +02:00
|
|
|
class AbstractTexture;
|
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 10:48:05 +02:00
|
|
|
class AbstractFramebuffer;
|
2019-02-15 02:59:50 +01:00
|
|
|
|
|
|
|
namespace VideoCommon
|
|
|
|
{
|
|
|
|
class PostProcessingConfiguration
|
2014-07-29 18:47:56 +02:00
|
|
|
{
|
|
|
|
public:
|
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 10:48:05 +02:00
|
|
|
// User defined post process
|
2014-07-29 18:47:56 +02:00
|
|
|
struct ConfigurationOption
|
|
|
|
{
|
2022-02-17 18:54:07 +01:00
|
|
|
enum class OptionType
|
2014-07-29 18:47:56 +02:00
|
|
|
{
|
2022-02-17 18:54:07 +01:00
|
|
|
Bool = 0,
|
|
|
|
Float,
|
|
|
|
Integer,
|
2014-07-29 18:47:56 +02:00
|
|
|
};
|
2016-06-24 10:43:46 +02:00
|
|
|
|
2021-09-04 06:43:19 +02:00
|
|
|
bool m_bool_value = false;
|
2016-06-24 10:43:46 +02:00
|
|
|
|
2014-07-29 18:47:56 +02:00
|
|
|
std::vector<float> m_float_values;
|
|
|
|
std::vector<s32> m_integer_values;
|
2016-06-24 10:43:46 +02:00
|
|
|
|
2014-07-29 18:47:56 +02:00
|
|
|
std::vector<float> m_float_min_values;
|
|
|
|
std::vector<s32> m_integer_min_values;
|
2016-06-24 10:43:46 +02:00
|
|
|
|
2014-07-29 18:47:56 +02:00
|
|
|
std::vector<float> m_float_max_values;
|
|
|
|
std::vector<s32> m_integer_max_values;
|
2016-06-24 10:43:46 +02:00
|
|
|
|
2014-07-29 18:47:56 +02:00
|
|
|
std::vector<float> m_float_step_values;
|
|
|
|
std::vector<s32> m_integer_step_values;
|
2016-06-24 10:43:46 +02:00
|
|
|
|
2022-02-17 18:54:07 +01:00
|
|
|
OptionType m_type = OptionType::Bool;
|
2016-06-24 10:43:46 +02:00
|
|
|
|
2014-07-29 18:47:56 +02:00
|
|
|
std::string m_gui_name;
|
|
|
|
std::string m_option_name;
|
|
|
|
std::string m_dependent_option;
|
2021-09-04 06:43:19 +02:00
|
|
|
bool m_dirty = false;
|
2014-07-29 18:47:56 +02:00
|
|
|
};
|
2016-06-24 10:43:46 +02:00
|
|
|
|
2018-05-21 17:57:15 +02:00
|
|
|
using ConfigMap = std::map<std::string, ConfigurationOption>;
|
2016-06-24 10:43:46 +02:00
|
|
|
|
2019-02-15 02:59:50 +01:00
|
|
|
PostProcessingConfiguration();
|
|
|
|
virtual ~PostProcessingConfiguration();
|
2018-05-21 17:54:53 +02:00
|
|
|
|
2014-07-29 18:47:56 +02:00
|
|
|
// Loads the configuration with a shader
|
|
|
|
// If the argument is "" the class will load the shader from the g_activeConfig option.
|
|
|
|
// Returns the loaded shader source from file
|
2019-02-15 02:59:50 +01:00
|
|
|
void LoadShader(const std::string& shader);
|
|
|
|
void LoadDefaultShader();
|
2014-07-29 18:47:56 +02:00
|
|
|
void SaveOptionsConfiguration();
|
2018-05-21 18:07:46 +02:00
|
|
|
const std::string& GetShader() const { return m_current_shader; }
|
2019-02-15 02:59:50 +01:00
|
|
|
const std::string& GetShaderCode() const { return m_current_shader_code; }
|
2018-05-21 17:59:04 +02:00
|
|
|
bool IsDirty() const { return m_any_options_dirty; }
|
2014-07-29 18:47:56 +02:00
|
|
|
void SetDirty(bool dirty) { m_any_options_dirty = dirty; }
|
2018-05-21 17:59:04 +02:00
|
|
|
bool HasOptions() const { return m_options.size() > 0; }
|
2017-04-21 15:33:12 +02:00
|
|
|
const ConfigMap& GetOptions() const { return m_options; }
|
2014-07-29 18:47:56 +02:00
|
|
|
ConfigMap& GetOptions() { return m_options; }
|
|
|
|
const ConfigurationOption& GetOption(const std::string& option) { return m_options[option]; }
|
|
|
|
// For updating option's values
|
2015-05-29 02:28:48 +02:00
|
|
|
void SetOptionf(const std::string& option, int index, float value);
|
|
|
|
void SetOptioni(const std::string& option, int index, s32 value);
|
|
|
|
void SetOptionb(const std::string& option, bool value);
|
2014-07-29 18:47:56 +02:00
|
|
|
|
|
|
|
private:
|
2018-05-21 17:54:53 +02:00
|
|
|
bool m_any_options_dirty = false;
|
2014-07-29 18:47:56 +02:00
|
|
|
std::string m_current_shader;
|
2019-02-15 02:59:50 +01:00
|
|
|
std::string m_current_shader_code;
|
2014-07-29 18:47:56 +02:00
|
|
|
ConfigMap m_options;
|
|
|
|
|
|
|
|
void LoadOptions(const std::string& code);
|
|
|
|
void LoadOptionsConfiguration();
|
|
|
|
};
|
|
|
|
|
2019-02-15 02:59:50 +01:00
|
|
|
class PostProcessing
|
2014-07-29 18:47:56 +02:00
|
|
|
{
|
|
|
|
public:
|
2019-02-15 02:59:50 +01:00
|
|
|
PostProcessing();
|
|
|
|
virtual ~PostProcessing();
|
|
|
|
|
|
|
|
static std::vector<std::string> GetShaderList();
|
2019-05-02 04:47:50 +02:00
|
|
|
static std::vector<std::string> GetPassiveShaderList();
|
2019-02-15 02:59:50 +01:00
|
|
|
static std::vector<std::string> GetAnaglyphShaderList();
|
|
|
|
|
|
|
|
PostProcessingConfiguration* GetConfig() { return &m_config; }
|
2014-07-29 18:47:56 +02:00
|
|
|
|
2019-02-15 02:59:50 +01:00
|
|
|
bool Initialize(AbstractTextureFormat format);
|
2017-04-21 15:59:45 +02:00
|
|
|
|
2019-02-15 02:59:50 +01:00
|
|
|
void RecompileShader();
|
|
|
|
void RecompilePipeline();
|
|
|
|
|
|
|
|
void BlitFromTexture(const MathUtil::Rectangle<int>& dst, 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 10:48:05 +02:00
|
|
|
const AbstractTexture* src_tex, int src_layer = -1);
|
|
|
|
|
|
|
|
bool IsColorCorrectionActive() const;
|
|
|
|
bool NeedsIntermediaryBuffer() const;
|
2018-04-12 14:18:04 +02:00
|
|
|
|
2014-07-29 18:47:56 +02:00
|
|
|
protected:
|
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 10:48:05 +02:00
|
|
|
std::string GetUniformBufferHeader(bool user_post_process) const;
|
|
|
|
std::string GetHeader(bool user_post_process) const;
|
2019-02-15 02:59:50 +01:00
|
|
|
std::string GetFooter() const;
|
|
|
|
|
|
|
|
bool CompileVertexShader();
|
|
|
|
bool CompilePixelShader();
|
|
|
|
bool 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 10:48:05 +02:00
|
|
|
size_t CalculateUniformsSize(bool user_post_process) const;
|
2019-02-15 02:59:50 +01:00
|
|
|
void FillUniformBuffer(const MathUtil::Rectangle<int>& src, const AbstractTexture* 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 10:48:05 +02:00
|
|
|
int src_layer, const MathUtil::Rectangle<int>& dst,
|
2023-08-06 02:11:19 +02:00
|
|
|
const MathUtil::Rectangle<int>& wnd, u8* buffer, bool user_post_process,
|
|
|
|
bool intermediary_buffer);
|
2019-02-15 02:59:50 +01:00
|
|
|
|
2014-07-29 18:47:56 +02:00
|
|
|
// Timer for determining our time value
|
|
|
|
Common::Timer m_timer;
|
|
|
|
|
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 10:48:05 +02:00
|
|
|
// Dolphin fixed post process:
|
|
|
|
PostProcessingConfiguration::ConfigMap m_default_options;
|
|
|
|
std::unique_ptr<AbstractShader> m_default_vertex_shader;
|
|
|
|
std::unique_ptr<AbstractShader> m_default_pixel_shader;
|
|
|
|
std::unique_ptr<AbstractPipeline> m_default_pipeline;
|
|
|
|
std::unique_ptr<AbstractFramebuffer> m_intermediary_frame_buffer;
|
|
|
|
std::unique_ptr<AbstractTexture> m_intermediary_color_texture;
|
|
|
|
std::vector<u8> m_default_uniform_staging_buffer;
|
|
|
|
// User post process:
|
|
|
|
PostProcessingConfiguration m_config;
|
2019-02-15 02:59:50 +01:00
|
|
|
std::unique_ptr<AbstractShader> m_vertex_shader;
|
|
|
|
std::unique_ptr<AbstractShader> m_pixel_shader;
|
|
|
|
std::unique_ptr<AbstractPipeline> m_pipeline;
|
|
|
|
std::vector<u8> m_uniform_staging_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 10:48:05 +02:00
|
|
|
|
|
|
|
AbstractTextureFormat m_framebuffer_format = AbstractTextureFormat::Undefined;
|
2014-07-29 18:47:56 +02:00
|
|
|
};
|
2019-02-15 02:59:50 +01:00
|
|
|
} // namespace VideoCommon
|