Change Details

Making the night more natural and fair This is a suggestion of a shader which improves the gameplay at and the look of the night in DayZ. It makes the abuse of the gamma and brightness settings almost useless (especially for PVP) while keeping the full range of these settings. [Update 2015-12-18] - NEW: Uploaded source to pastebin.com for public testing - NEW: Added controls to toggle the shader and the gamma correction indepentently at runtime - Updated and tested the shader for ReShade with ReShade 1.1.0 - Performance optimization, code cleanup and updated documentation/comments - Further optimization for low visual impact while playing with normal gamma settings - New images [Update 2015-02-23] - NEW: Shader for ReShade (HLSL) - NEW: Shader for SweetFX (HLSL) - NEW: Shader+Sketch for Processing (GLSL) - Optimized performance - Optimized for low visual impact while playing with normal gamma settings - New Images [Submitted 2013-12-18] 0) INDEX: 0) Index 1) Theory 2) Implementation 3) Summary 4) Results 4.1) Performance 4.2) Images 5) Conclusion 6) Source 6.1) Installation and use 1) THEORY: If you aren't interested in the theory, skip to the "RESULTS" section to see the screenshots. One important problem in DayZ on night time servers is the abuse of the gamma settings. It forces you to decide to either play with normal gamma settings and having a disadvantage but a nice looking game or to increase gamma to have a greater chance to survive but everything looks awful. Aside from the aesthetical aspect the night doesn't make much sense if the main aspect, the restricted vision, can be circumvented so easily like at the moment. Quite often the nights in DayZ (and ArmA 2 and sometimes even Arma 3) seem to be either to dark or to bright: One the one hand we have the dark (new moon) nights which are quite realistic in terms of the lighting (after all it's the apocalypse; the power grid seems broken down, so large scale electric light sources shouldn't work). But sometimes it is nearly impossible to even navigate (not to mention looting, fighting, etc.). On the other hand we have the full moon nights which are so bright that you can see and recognize players several hundreds meters away. The problem is, that the maximum "useful" view distance, up to which you can recognize important details, doesn't correlate with the actual brightness of the ambient light. If the brightness exceeds the level at which you are able to recognize your close surroundings, you can also recognize details hundreds meters away. But below that level you nearly can't see anything. What is missing is a continuous transition between recognizable and not recognizable details for the full range of light intensities. In reallife at some point everything gets more and more blurred the darker it gets and even in a full moon night you are barely able to recognize an idle person >100m away in a field of tall grass or >30m in the woods. But you are able to see and recognize large objects like trees, large rocks or bushes at great distance but way less detailed compared to daytime. To understand why this happens we look at the physiological characteristics of the human eye. The human eye contains mainly two different types of photoreceptor cells; the cones and the rods: The cone cells are responsible for the vision in daylight. They provide color vision and are connected to the brain more or less one by one to achieve a high resolution, but they need relatively bright light to work. At night the rod cells take over. They are about a hundred times more sensitive to light compared to the cones but can not differentiate between colors. Additionally they form clusters of several rod cells to accumulate and amplify the light, leading to even more sensitivity. But because these clusters are connected to the brain as a whole, instead of every single cell on its own, they provide a lower resolution. That leads to a blurier vision at night compared to the vision in daylight. To simulate this behaviour the shader blurs each pixel depending on the local brightness around it. The darker an area is, the more it gets blurred: An object below a bright street light isn't modified at all, while a dark tree line gets heavily blurred. In addition to the more natural look of the night the shader significantly reduces the benefits of abusing the gamma settings: If you increase gamma the dark areas may be brighter but stay blurred and the removed details can't be recovered. While the shader is optimized for low visual impact when playing with normal gamma settings, you still can't reveal significant additional details by increasing gamma. This leads to a much wider usable range of the brightness of the ambient light which can be used for balancing: You neither need pitch black nights to restrict vision nor you need to reveal details hundreds meters away if you just want to allow player to travel the map at night without additional light sources. 2) IMPLEMENTATION: The shader roughly works like this: 1. The image is blurred with a gaussian kernel and the luminance is calculated for each blurred pixel (The result contains the weighted average luminance of the neighborhood of each pixel) 2. Calculate the amount of blur to be applied to each pixel based on the weighted average luminances (Simplified: blur=1/brightness) 3. Blur each pixel according to the calculated values In addition to that we need to consider the following: - The shader should be applied prior to the HDR-mapping to guarantee that it only takes effect in low light environments like at night and not on dark textures at day - If you aim for physiological correctness you would need to configure the 2. step so that the effect starts to fade in at the same luminance at which the colors start to fade out (at this point the transition between day- and night vision starts) - To reduce the abuse of the gamma settings it has to be applied prior to the gamma correction. (obvious) Then you have a fair solution, because everything has exactly the same level of detail for everybody. Besides that you wouldn't need to restrict the gamma correction itself. (Simply restricting the gamma correction is unfair to those players who really need it.) The shader could be controlled server side, because on the one hand it might lower performance on old systems, but would greatly improve the fairness on the other. Then it would be up to the player to choose between servers with and servers without the shader, but if they choose one with it enabled, they can be certain everybody uses it. 3) SUMMARY: Pro: - Combats the abuse of the gamma correction without restricting the gamma correction itself - Improves realism and authenticity - Gives the night a more natural look - Good performance (see below) Con: - Might reduce the performance on very old or "minimalist" systems (But could be controlled server side) - Could cause some problems for players who are prone to gaming sickness (But after many hours of testing I assume that the shader could even improve the situation for some of these players because it leads to a more natural and "familiar" look --> Further testing needed!) 4) RESULTS: 4.1) Performance: Tested on: - AMD Phenom II X4 965 Black Edition @ 3,4GHz - NVIDIA GeForce GTX 560 Ti - ASUS M4A89GTD-PRO/USB3 - 12GB RAM @ 1333MHz With ReShade 1.1.0 and the recent version of the shader. Test of ArmA 2 CO: The Shader takes 0.1-0.2ms to process one frame. No reduction of the framerate observed. Test of ArmA 3: The Shader takes 0.01-0.02ms to process one frame. No reduction of the framerate observed. The difference of one magnitude in the processing time between ArmA 2 and ArmA 3 might be a result of the different DirectX versions used by both engines. The shader should be at least as fast as in the test with ArmA 3 if it is included directly in the post processing of the new renderer (DirectX 11). 4.2) Images: The screenshots are made with ArmA 2/3, because it is easier to get a greater variety of scenes while ArmA and DayZ are comparable in terms of brightness/gamma. The previous screenshots (2015-02-23) were taken with ArmA 2 CO in Chernarus, the new ones (2015-12-18) with ArmA 3 in Chernarus and Altis. Example 1: shader=off, gamma=1.0: http://i.imgur.com/vUy36UQ.png shader=on, gamma=1.0: http://i.imgur.com/3o81CeK.png shader=off, gamma=2.0: http://i.imgur.com/b5TpP6d.png shader=on, gamma=2.0: http://i.imgur.com/Jhp9yNp.png Example 2: shader=off, gamma=1.0: http://i.imgur.com/woCzgqU.jpg shader=on, gamma=1.0: http://i.imgur.com/FmWA7aH.png shader=off, gamma=2.0: http://i.imgur.com/8Huxw0e.jpg shader=on, gamma=2.0: http://i.imgur.com/7Xwn7lf.png Example 3: shader=off, gamma=1.0: http://i.imgur.com/5Hj7lg8.jpg shader=on, gamma=1.0: http://i.imgur.com/QfybDkh.png shader=off, gamma=2.0: http://i.imgur.com/KJaDEKT.jpg shader=on, gamma=2.0: http://i.imgur.com/bKiTRgN.jpg More examples in the same order like above for every row: New screenshots: http://imgur.com/a/7G0b7/all (Chernarus) http://imgur.com/a/kuhsl/all (Altis) Previous screenshots: (These are outdated, but I left them for comparison) https://imgur.com/a/1wWjW/ (Chernarus) https://imgur.com/a/S7Db4/ (Chernarus) 5) CONCLUSION: The shader improves the authenticity and gameplay without changing the rest of the game or forcing the players to certain gamma and brightness settings. 6) SOURCE: The attached source files are outdated and for the record only. The updated source can be found at: http://pastebin.com/Cm4y12Qq 6.1) Installation and use: IMPORTANT NOTE: The shader hooks into the renderer and thus it might modify the memory of the running game. This could be classified as a sign of cheating/hacking and because of this it is recomended to test the shader in singleplayer/editor with disconnected networking. After testing and before reconnecting you should uninstall it by deleting the two files you copied during the installation. That might sound a bit paranoid, but better safe than sorry... :) During the installation you need to rename two files and change their file extensions too. For this you need to activate/show the file extensions in the windows explorer, if you haven't done it already: http://windows.microsoft.com/en-us/windows/show-hide-file-name-extensions 1. Download ReShade During the testing Reshade is needed for hooking into the renderer and loading/starting/toggeling the shader. It is available at http://reshade.me/ 2. Copy ReShade32.dll from the downloaded archive into ArmAs main directory (same directory like the arma2.exe/ArmA2OA.exe/arma3.exe) 3. For ArmA 2 (OA/CO) rename the copied ReShade32.dll to d3d9.dll, for ArmA 3 rename it to dxgi.dll 4. Download the shader file http://pastebin.com/Cm4y12Qq 5. Rename it to ReShade.fx 6. Copy this ReShade.fx into ArmAs main directory too. That's it. If you now start ArmA ReShade should load the shader. Press [Insert] to toggle the shader on/off Press [Home] to toggle gamma 1.0/2.0 It might be helpfull to note that ReShade is not compatible with software like screen capturing or overlays and you would need to deactivate them in order to test the shader. To take screenshots nevertheless ReShade brings its own screenshot functionality: Press [Print] to take a screenshot (they are saved to the same directory where you put the shader files)

This is a suggestion for a post-processing shader to improve the gameplay at and the look of the night in DayZ. It makes the abuse of the gamma and brightness settings almost useless (especially for PvP) without restricting these settings. ---Update 2016-06-12--- - Updated description - Created thread in suggestions section of the forum ---Update 2015-12-18--- - NEW: Uploaded source to pastebin.com for public testing - NEW: Added controls to toggle the shader and the gamma correction independently at runtime - Updated and tested the shader for ReShade with ReShade 1.1.0 - Performance optimization, code clean-up and updated documentation/comments - Further optimization for low visual impact while playing with normal gamma settings - New images ---Update 2015-02-23--- - NEW: Shader for ReShade (HLSL) - NEW: Shader for SweetFX (HLSL) - NEW: Shader & Sketch for Processing (GLSL) - Optimized performance - Optimized for low visual impact while playing with normal gamma settings - New images ---Submitted 2013-12-18--- 0) INDEX: 0) Index 1) Theory 2) Implementation 3) Results 3.1) Images 3.2) Performance 4) Summary 5) Conclusion 6) Source 6.1) Installation and use 1) THEORY: If you aren't interested in the theory, skip to the "RESULTS" section to see the screenshots. One important problem in DayZ on night time servers is the abuse of the gamma settings as it is easy to change the in-game gamma-/brightness settings, the systems graphic settings or even the display settings accordingly. And since it is that easy and literally undetectable many players seem to use it for their advantage today. This forces each player to decide to either play with normal gamma settings and having a disadvantage but a nice looking game or to increase gamma to have a greater chance to survive but everything looks awful. Aside from its aesthetic appeal the night doesn't make much sense if the main aspect, the restricted vision, can be circumvented so easily like at the moment. Comparison of normal gamma settings and abusive gamma settings: Normal gamma settings: https://i.imgur.com/99aiT5h.png Abusive gamma settings: https://i.imgur.com/WoybbOo.jpg To make things worse the nights in DayZ (and ArmA 2 & 3) seem to be either to dark or to bright: On the one hand we have the very dark nights around new moon which are quite realistic in terms of lighting: After all it's the apocalypse; the power grid seems broken down, so large scale electric light sources shouldn't work. But then it is nearly impossible to even navigate, not to mention looting, fighting, etc. and this could lead even players not really interested in PvP to exploit the gamma settings. On the other hand we have the nights around full moon which are so bright that you can see and recognize players several hundred meters away. But this is neither realistic nor authentic. Opposed to the big difference between full and new moon nights the difference between winter and summer nights seems quite small: While the winter nights are OK, the summer nights seem too dark and you can see much less than in the real world. Example of the relatively dark new moon, summer nights at 2035-06-12 20:20 in-game time. At least in Central Europe this darkness isn't reached until around 23:30 at this date: http://i.imgur.com/4Y7qqH9.png Example of the relatively bright full moon nights: http://i.imgur.com/8PsM7tz.jpg (The white object in the background is a radome) But only changing the ambient light wouldn't be a solution as the problem is not just the lighting, but that the maximum "useful" view distance, up to which you can recognize important details, doesn't correlate with the actual brightness of the ambient light. If the brightness exceeds the level at which you are able to recognize your close surroundings, you can also recognize details hundreds meters away. But below that level you almost instantly can't see your hand in front of your face. What is missing is a continuous transition from details being recognizable to details being not recognizable for the transition from day to night and back. Some details visible both nearby and a few hundred meters away too: http://i.imgur.com/z1XW5hX.jpg No significant details visible, neither close nor at a distance: http://i.imgur.com/En1iti0.png In the real world at some point everything looks more and more blurred the darker it gets and even in a full moon night you are barely able to recognize an idle person >100m away in a field of tall grass or >30m in the woods. But you are able to see and recognize large objects like trees, large rocks or bushes at great distance but way less detailed compared to daytime. To understand why this happens we have to look at the physiological characteristics of the human eye. The human eye contains mainly two different types of photoreceptor cells; the cones and the rods: Here we have a simplified representation of the retina showing the photo receptive rods (gray) and cones (colored) and some of the neurons (brown) responsible for the summation of the values of several rod cells and for connecting all photo receptors to the next layers of the retina: https://i.imgur.com/FgY38ol.png The cone cells are responsible for the vision in daylight. They provide color vision and are connected to the brain more or less one by one to achieve a high resolution, but they need relatively bright light to work. At night the rod cells take over. They are about a hundred times more sensitive to light compared to the cones but can not differentiate between colors. Additionally they form clusters of several rod cells to accumulate and amplify the light, leading to even more sensitivity. But because each of these clusters is connected to the brain as a whole, instead of every single cell on its own, they provide a lower resolution. That leads to a blurrier vision at night compared to the vision in daylight. To simulate this behavior the shader needs to blur each pixel depending on the brightness of the area around it. The darker an area is, the more it gets blurred: An object below a bright street light isn't modified at all, while a dark tree line gets heavily blurred. In addition to the more natural look of the night the shader significantly reduces the benefits of abusing the gamma settings: If you increase the gamma value the dark areas may be brighter but stay blurred and the removed details can not be recovered. While the shader is optimized for low visual impact when playing with normal gamma settings, you still can't reveal significant additional details by increasing gamma. Comparison of abusive gamma settings without and with the shader activated: shader off: https://i.imgur.com/WoybbOo.jpg shader on: https://i.imgur.com/NClatiF.png This leads to a much wider range of brightness of the ambient light usable for balancing: You neither need pitch black nights to restrict vision nor you need to reveal details hundreds meters away if you just want to allow player to travel the map at night without additional light sources. Besides that you wouldn't have to restrict the gamma correction itself as simply restricting the gamma correction is unfair to those players who really need it. While the blurriness is barely visible it could induce gaming sickness for some sensitive players. This is most likely to happen at some point during the in-game (nautical) twilight. At this time the ambient light reaches a level at which most of the surroundings are already a bit blurred but it is not yet dark enough to "cover it up". While this is the same in the real world, it is rather unusual in computer games. This discrepancy between expectation and reality could cause negative symptoms for some players. But it is also possible that the shader reduces the symptoms for other players if these symptoms are caused by small, noisy, barely visible details in the dark surroundings. As these details are hard to see, the tracking and focusing of them could draw much concentration or be tiring for the eyes and lead to headache or dizziness. Since the shader removes exactly these details it could reduce or even prevent this sort of gaming sickness. To evaluate these assumptions more players need to test the shader and report back. I know from my own experience that it takes a while to get used to the slightly changed look and feel of the game. When you test the shader for the very first time or the first time after a bigger change of some parameters it can take up to two hours until you have adapted to it. That means you shouldn't give up too early and keep on testing for a while even if you aren't pleased by the results right from the start. As described above; the shader is configured to cause as little visual blur as possible. This leads to even less blurriness than in the real world and should be kept in mind when comparing the results to real world examples. 2) IMPLEMENTATION: The following descriptions of two possible approaches are simplified as the detailed ones would go beyond the scope of this overview. First approach: https://i.imgur.com/1nP35pM.png rectangle - data ellipse - processing step The first approach uses adaptive blurring of the image: 1. The luminance of the neighborhood of each pixel is determined by calculating the luminance of each pixel, save the result in a separate buffer and then blur it with a fixed radius. 2. The result of step 1 is used to calculate the radii for the actual blurring of the frame. For this a function similar to 1.0/luminance is used. That means the brighter the neighborhood of a pixel is, the less blurred it gets. 3. The frame gets blurred according to the result of step 2. Second approach: https://i.imgur.com/w187akC.png rectangle - data ellipse - processing step The second approach uses the blending of the original and a blurred version of the image: 1. To get the luminance of the neighborhood of each pixel the image is blurred first and the result is saved in a separate buffer. Then the luminance is calculated and saved to another buffer. 2. Almost the same function like in the first approach is used to calculate the proportion of the original image and its blurred version for each pixel. 3. The original image and its blurred version are blended pixel-wise according to the result of step 2. If we want to compare the two approaches we just need to examine the third step as the first two steps are almost the same for both approaches. It is easy to see that the second approach is faster because a simple interpolation is faster than a convolution with a kernel of reasonable size. When it comes to the efficiency of the gamma exploitation prevention the first approach is superior. This becomes clear when we look at the frequency spectra of the results of both approaches: We assume that all frequencies of the input are equally distributed so its spectrum looks like this: Homogeneous input spectrum: https://i.imgur.com/x6ie9yS.png Then the output of a shader using the first approach would have the following spectra: The output spectra of the first approach for different light intensities: Day: https://i.imgur.com/eFfe3RI.png Early twilight: https://i.imgur.com/FI57zsg.png Late twilight: https://i.imgur.com/Xt9sS0i.png Midnight: https://i.imgur.com/WXb2HJA.png As you can see the darker the input is the lower is the cut-off frequency. All frequencies significantly higher than the cut-off are suppressed enough to be technically unrecoverable as their amplitude reaches virtually zero. So more and more details are removed beginning with the smallest(highest frequency) ones. For the second approach we assume the same input and the following spectrum of the blurred version of the input calculated by the first step: Fixed radius blur spectrum: https://i.imgur.com/CZHdJJ6.png Then a shader using the second approach would have the following output spectra: The output spectra of the second approach for different light intensities: Day: https://i.imgur.com/Z4dw7ob.png Early twilight: https://i.imgur.com/CurxrW3.png Late twilight: https://i.imgur.com/B5XwsHb.png Midnight: https://i.imgur.com/gf0b8jl.png In contrast to the first, the second approach lowers the amplitudes of all higher frequencies altogether. That means that unless in complete darkness all higher frequency details have significant non-zero amplitudes and could be recovered by unsharp masking. This renders the second approach ineffective against gamma exploitation as even a simple sharpen effect of the graphics card or the display could recover significant details. As the effectiveness against gamma exploitation is one important requirement the shader has to meet, it has to use the first approach. In addition to that you need to consider the following: - The shader should be applied prior to the tone mapping to guarantee that it only takes effect in low light environments like at night and not on dark surfaces at day - If you aim for physiological correctness you would need to configure the 2. step that the effect starts to fade in at the same luminance at which the colors start to fade out as at this time the transition between day- and night vision starts - To reduce the abuse of the gamma settings it has to be applied prior to the gamma correction. - If you plan to allow post-processing injectors like ReShade and shader suits like SweetFX (I hope you will!) then you need to decide whether you want to make the depth map accessible or not. Because if you do, you need to blur it too; otherwise it could be exploited as well to get something like "bat-/sonar-vision". If you follow these recommendations then you should have a fair solution, because everything has exactly the same level of detail for everybody regardless of their gamma- and brightness settings. The shader could be controlled server side, as it might lower performance on very old systems or could induce gaming sickness, but would really improve the fairness. Then it would be up to the player to choose between servers with and servers without the shader, but if they choose one with it enabled, they can be certain everybody uses it. 3) RESULTS: 3.1) Images: The screenshots were taken with ArmA 2 & 3, because it is easier to get a greater variety of scenes while ArmA and DayZ are comparable in terms of brightness/gamma. The previous screenshots (2015-02-23) were taken with ArmA 2 CO in Chernarus, the new ones (2015-12-18) with ArmA 3 in Chernarus and Altis. Example 1: NWAF shader=off, gamma=1.0: http://i.imgur.com/vUy36UQ.png shader=on, gamma=1.0: http://i.imgur.com/3o81CeK.png shader=off, gamma=2.0: http://i.imgur.com/b5TpP6d.png shader=on, gamma=2.0: http://i.imgur.com/Jhp9yNp.png Example 2: Hills north of Chernogorsk shader=off, gamma=1.0: http://i.imgur.com/woCzgqU.jpg shader=on, gamma=1.0: http://i.imgur.com/FmWA7aH.png shader=off, gamma=2.0: http://i.imgur.com/8Huxw0e.jpg shader=on, gamma=2.0: http://i.imgur.com/7Xwn7lf.png Example 3: Country house on Altis shader=off, gamma=1.0: http://i.imgur.com/5Hj7lg8.jpg shader=on, gamma=1.0: http://i.imgur.com/QfybDkh.png shader=off, gamma=2.0: http://i.imgur.com/KJaDEKT.jpg shader=on, gamma=2.0: http://i.imgur.com/bKiTRgN.jpg More examples in the same order like above for every row: New screenshots (2015-12-18): http://imgur.com/a/7G0b7/all (Chernarus) http://imgur.com/a/kuhsl/all (Altis) Previous screenshots (2015-02-23): (These are outdated, but I left them for comparison) https://imgur.com/a/1wWjW/ (Chernarus) https://imgur.com/a/S7Db4/ (Chernarus) 3.2) Performance: Tested on: - AMD Phenom II X4 965 Black Edition @ 3,4GHz - NVIDIA GeForce GTX 560 Ti - ASUS M4A89GTD-PRO/USB3 - 12GB RAM @ 1333MHz With ReShade 1.1.0 and the recent version of the shader. Test of ArmA 2 CO: The Shader takes 0.1-0.2ms to process one frame. No reduction of the frame rate observed. Test of ArmA 3: The Shader takes 0.01-0.02ms to process one frame. No reduction of the frame rate observed. The difference of one magnitude in the processing time between ArmA 2 and ArmA 3 might be a result of the different DirectX versions used by both engines. The shader should be at least as fast as in the test with ArmA 3 if it is included directly in the post processing of the new renderer (DirectX 11). 4) SUMMARY: Pro: - Combats the abuse of the gamma correction without restricting the gamma correction itself - Improves realism and authenticity - Gives the night a more natural look - Good performance Con: - Might reduce the performance on very old or minimalist systems without dedicated graphics - Could cause some problems for players who are prone to gaming sickness 5) CONCLUSION: The shader improves the authenticity and gameplay without changing the rest of the game or forcing the players to certain gamma and brightness settings. 6) SOURCE: The source can be found at: http://pastebin.com/Cm4y12Qq The attached source files are outdated and for the record only. 6.1) Installation and use: IMPORTANT NOTE: The shader hooks into the renderer and thus it might modify the memory of the running game. This could be classified as a sign of cheating/hacking and because of this it is recommended to test the shader in singleplayer/editor with disconnected networking. After testing and before reconnecting you should uninstall it by deleting the two files you copied during the installation. That might sound a bit paranoid, but better safe than sorry... :) During the installation you need to rename two files and change their file extensions too. For this you need to activate/show the file extensions in the windows explorer, if you haven't done it already: http://windows.microsoft.com/en-us/windows/show-hide-file-name-extensions 1. Download ReShade During the testing Reshade is needed for hooking into the renderer and loading/starting/toggeling the shader. It is available at http://reshade.me/ 2. Copy ReShade32.dll from the downloaded archive into ArmAs main directory (same directory like the arma2.exe/ArmA2OA.exe/arma3.exe) 3. For ArmA 2 (OA/CO) rename the copied ReShade32.dll to d3d9.dll, for ArmA 3 rename it to dxgi.dll 4. Download the shader file http://pastebin.com/Cm4y12Qq 5. Rename it to ReShade.fx 6. Copy this ReShade.fx into ArmAs main directory too. 7. That's it. If you now start ArmA ReShade should load the shader. Press [Insert] to toggle the shader on/off Press [Home] to toggle gamma 1.0/2.0 ReShade is not compatible with software like screen capturing or overlays and you need to deactivate them in order to test the shader. To take screenshots ReShade has its own screenshot functionality (but sometimes it seems to miss some keystrokes): Press [Print] to take a screenshot (they are saved to the same directory where you put the shader files)

Making the night more natural and fair This is a suggestion of a shader which improves the gameplay at and the look of the night in DayZ. It makes the abuse of the gamma and brightness settings almost useless (especially for PVP) while keeping the full range of these settings. [Update 2015-12-18] - NEW: Uploaded source to pastebin.com for public testing - NEW: Added controls to toggle the shader and the gamma correction indepentently at runtime - Updated and tested the shader for ReShade with ReShade 1.1.0 - Performance optimization, code cleanup and updated documentation/comments - Further optimization for low visual impact while playing with normal gamma settings - New images [Update 2015-02-23] - NEW: Shader for ReShade (HLSL) - NEW: Shader for SweetFX (HLSL) - NEW: Shader+Sketch for Processing (GLSL) - Optimized performance - Optimized for low visual impact while playing with normal gamma settings - New Images [Submitted 2013-12-18] 0) INDEX: 0) Index 1) Theory 2) Implementation 3) Summary 4) Results 4.1) Performance 4.2) Images 5) Conclusion 6) Source 6.1) Installation and use 1) THEORY: If you aren't interested in the theory, skip to the "RESULTS" section to see the screenshots. One important problem in DayZ on night time servers is the abuse of the gamma settings. It forces you to decide to either play with normal gamma settings and having a disadvantage but a nice looking game or to increase gamma to have a greater chance to survive but everything looks awful. Aside from the aesthetical aspect the night doesn't make much sense if the main aspect, the restricted vision, can be circumvented so easily like at the moment. Quite often the nights in DayZ (and ArmA 2 and sometimes even Arma 3) seem to be either to dark or to bright: One the one hand we have the dark (new moon) nights which are quite realistic in terms of the lighting (after all it's the apocalypse; the power grid seems broken down, so large scale electric light sources shouldn't work). But sometimes it is nearly impossible to even navigate (not to mention looting, fighting, etc.). On the other hand we have the full moon nights which are so bright that you can see and recognize players several hundreds meters away. The problem is, that the maximum "useful" view distance, up to which you can recognize important details, doesn't correlate with the actual brightness of the ambient light. If the brightness exceeds the level at which you are able to recognize your close surroundings, you can also recognize details hundreds meters away. But below that level you nearly can't see anything. What is missing is a continuous transition between recognizable and not recognizable details for the full range of light intensities. In reallife at some point everything gets more and more blurred the darker it gets and even in a full moon night you are barely able to recognize an idle person >100m away in a field of tall grass or >30m in the woods. But you are able to see and recognize large objects like trees, large rocks or bushes at great distance but way less detailed compared to daytime. To understand why this happens we look at the physiological characteristics of the human eye. The human eye contains mainly two different types of photoreceptor cells; the cones and the rods: The cone cells are responsible for the vision in daylight. They provide color vision and are connected to the brain more or less one by one to achieve a high resolution, but they need relatively bright light to work. At night the rod cells take over. They are about a hundred times more sensitive to light compared to the cones but can not differentiate between colors. Additionally they form clusters of several rod cells to accumulate and amplify the light, leading to even more sensitivity. But because these clusters are connected to the brain as a whole, instead of every single cell on its own, they provide a lower resolution. That leads to a blurier vision at night compared to the vision in daylight. To simulate this behaviour the shader blurs each pixel depending on the local brightness around it. The darker an area is, the more it gets blurred: An object below a bright street light isn't modified at all, while a dark tree line gets heavily blurred. In addition to the more natural look of the night the shader significantly reduces the benefits of abusing the gamma settings: If you increase gamma the dark areas may be brighter but stay blurred and the removed details can't be recovered. While the shader is optimized for low visual impact when playing with normal gamma settings, you still can't reveal significant additional details by increasing gamma. This leads to a much wider usable range of the brightness of the ambient light which can be used for balancing: You neither need pitch black nights to restrict vision nor you need to reveal details hundreds meters away if you just want to allow player to travel the map at night without additional light sources. 2) IMPLEMENTATION: The shader roughly works like this: 1. The image is blurred with a gaussian kernel and the luminance is calculated for each blurred pixel (The result contains the weighted average luminance of the neighborhood of each pixel) 2. Calculate the amount of blur to be applied to each pixel based on the weighted average luminances (Simplified: blur=1/brightness) 3. Blur each pixel according to the calculated values In addition to that we need to consider the following: - The shader should be applied prior to the HDR-mapping to guarantee that it only takes effect in low light environments like at night and not on dark textures at day - If you aim for physiological correctness you would need to configure the 2. step so that the effect starts to fade in at the same luminance at which the colors start to fade out (at this point the transition between day- and night vision starts) - To reduce the abuse of the gamma settings it has to be applied prior to the gamma correction. (obvious) Then you have a fair solution, because everything has exactly the same level of detail for everybody. Besides that you wouldn't need to restrict the gamma correction itself. (Simply restricting the gamma correction is unfair to those players who really need it.) The shader could be controlled server side, because on the one hand it might lower performance on old systems, but would greatly improve the fairness on the other. Then it would be up to the player to choose between servers with and servers without the shader, but if they choose one with it enabled, they can be certain everybody uses it. 3) SUMMARY: Pro: - Combats the abuse of the gamma correction without restricting the gamma correction itself - Improves realism and authenticity - Gives the night a more natural look - Good performance (see below) Con: - Might reduce the performance on very old or "minimalist" systems (But could be controlled server side) - Could cause some problems for players who are prone to gaming sickness (But after many hours of testing I assume that the shader could even improve the situation for some of these players because it leads to a more natural and "familiar" look --> Further testing needed!) 4) RESULTS: 4.1) Performance: Tested on: - AMD Phenom II X4 965 Black Edition @ 3,4GHz - NVIDIA GeForce GTX 560 Ti - ASUS M4A89GTD-PRO/USB3 - 12GB RAM @ 1333MHz With ReShade 1.1.0 and the recent version of the shader. Test of ArmA 2 CO: The Shader takes 0.1-0.2ms to process one frame. No reduction of the framerate observed. Test of ArmA 3: The Shader takes 0.01-0.02ms to process one frame. No reduction of the framerate observed. The difference of one magnitude in the processing time between ArmA 2 and ArmA 3 might be a result of the different DirectX versions used by both engines. The shader should be at least as fast as in the test with ArmA 3 if it is included directly in the post processing of the new renderer (DirectX 11). 4.2) Images: The screenshots are made with ArmA 2/3, because it is easier to get a greater variety of scenes while ArmA and DayZ are comparable in terms of brightness/gamma. The previous screenshots (2015-02-23) were taken with ArmA 2 CO in Chernarus, the new ones (2015-12-18) with ArmA 3 in Chernarus and Altis. Example 1: shader=off, gamma=1.0: http://i.imgur.com/vUy36UQ.png shader=on, gamma=1.0: http://i.imgur.com/3o81CeK.png shader=off, gamma=2.0: http://i.imgur.com/b5TpP6d.png shader=on, gamma=2.0: http://i.imgur.com/Jhp9yNp.png Example 2: shader=off, gamma=1.0: http://i.imgur.com/woCzgqU.jpg shader=on, gamma=1.0: http://i.imgur.com/FmWA7aH.png shader=off, gamma=2.0: http://i.imgur.com/8Huxw0e.jpg shader=on, gamma=2.0: http://i.imgur.com/7Xwn7lf.png Example 3: shader=off, gamma=1.0: http://i.imgur.com/5Hj7lg8.jpg shader=on, gamma=1.0: http://i.imgur.com/QfybDkh.png shader=off, gamma=2.0: http://i.imgur.com/KJaDEKT.jpg shader=on, gamma=2.0: http://i.imgur.com/bKiTRgN.jpg More examples in the same order like above for every row: New screenshots: http://imgur.com/a/7G0b7/all (Chernarus) http://imgur.com/a/kuhsl/all (Altis) Previous screenshots: (These are outdated, but I left them for comparison) https://imgur.com/a/1wWjW/ (Chernarus) https://imgur.com/a/S7Db4/ (Chernarus) 5) CONCLUSION: The shader improves the authenticity and gameplay without changing the rest of the game or forcing the players to certain gamma and brightness settings. 6) SOURCE: The attached source files are outdated and for the record only. The updated source can be found at: http://pastebin.com/Cm4y12Qq 6.1) Installation and use: IMPORTANT NOTE: The shader hooks into the renderer and thus it might modify the memory of the running game. This could be classified as a sign of cheating/hacking and because of this it is recomended to test the shader in singleplayer/editor with disconnected networking. After testing and before reconnecting you should uninstall it by deleting the two files you copied during the installation. That might sound a bit paranoid, but better safe than sorry... :) During the installation you need to rename two files and change their file extensions too. For this you need to activate/show the file extensions in the windows explorer, if you haven't done it already: http://windows.microsoft.com/en-us/windows/show-hide-file-name-extensions 1. Download ReShade During the testing Reshade is needed for hooking into the renderer and loading/starting/toggeling the shader. It is available at http://reshade.me/ 2. Copy ReShade32.dll from the downloaded archive into ArmAs main directory (same directory like the arma2.exe/ArmA2OA.exe/arma3.exe) 3. For ArmA 2 (OA/CO) rename the copied ReShade32.dll to d3d9.dll, for ArmA 3 rename it to dxgi.dll 4. Download the shader file http://pastebin.com/Cm4y12Qq 5. Rename it to ReShade.fx 6. Copy this ReShade.fx into ArmAs main directory too. That's it. If you now start ArmA ReShade should load the shader. Press [Insert] to toggle the shader on/off Press [Home] to toggle gamma 1.0/2.0 It might be helpfull to note that ReShade is not compatible with software like screen capturing or overlays and you would need to deactivate them in order to test the shader. To take screenshots nevertheless ReShade brings its own screenshot functionality: Press [Print] to take a screenshot (they are saved to the same directory where you put the shader files) This is a suggestion for a post-processing shader to improve the gameplay at and the look of the night in DayZ. It makes the abuse of the gamma and brightness settings almost useless (especially for PvP) without restricting these settings. ---Update 2016-06-12--- - Updated description - Created thread in suggestions section of the forum ---Update 2015-12-18--- - NEW: Uploaded source to pastebin.com for public testing - NEW: Added controls to toggle the shader and the gamma correction independently at runtime - Updated and tested the shader for ReShade with ReShade 1.1.0 - Performance optimization, code clean-up and updated documentation/comments - Further optimization for low visual impact while playing with normal gamma settings - New images ---Update 2015-02-23--- - NEW: Shader for ReShade (HLSL) - NEW: Shader for SweetFX (HLSL) - NEW: Shader & Sketch for Processing (GLSL) - Optimized performance - Optimized for low visual impact while playing with normal gamma settings - New images ---Submitted 2013-12-18--- 0) INDEX: 0) Index 1) Theory 2) Implementation 3) Results 3.1) Images 3.2) Performance 4) Summary 5) Conclusion 6) Source 6.1) Installation and use 1) THEORY: If you aren't interested in the theory, skip to the "RESULTS" section to see the screenshots. One important problem in DayZ on night time servers is the abuse of the gamma settings as it is easy to change the in-game gamma-/brightness settings, the systems graphic settings or even the display settings accordingly. And since it is that easy and literally undetectable many players seem to use it for their advantage today. This forces each player to decide to either play with normal gamma settings and having a disadvantage but a nice looking game or to increase gamma to have a greater chance to survive but everything looks awful. Aside from its aesthetic appeal the night doesn't make much sense if the main aspect, the restricted vision, can be circumvented so easily like at the moment. Comparison of normal gamma settings and abusive gamma settings: Normal gamma settings: https://i.imgur.com/99aiT5h.png Abusive gamma settings: https://i.imgur.com/WoybbOo.jpg To make things worse the nights in DayZ (and ArmA 2 & 3) seem to be either to dark or to bright: On the one hand we have the very dark nights around new moon which are quite realistic in terms of lighting: After all it's the apocalypse; the power grid seems broken down, so large scale electric light sources shouldn't work. But then it is nearly impossible to even navigate, not to mention looting, fighting, etc. and this could lead even players not really interested in PvP to exploit the gamma settings. On the other hand we have the nights around full moon which are so bright that you can see and recognize players several hundred meters away. But this is neither realistic nor authentic. Opposed to the big difference between full and new moon nights the difference between winter and summer nights seems quite small: While the winter nights are OK, the summer nights seem too dark and you can see much less than in the real world. Example of the relatively dark new moon, summer nights at 2035-06-12 20:20 in-game time. At least in Central Europe this darkness isn't reached until around 23:30 at this date: http://i.imgur.com/4Y7qqH9.png Example of the relatively bright full moon nights: http://i.imgur.com/8PsM7tz.jpg (The white object in the background is a radome) But only changing the ambient light wouldn't be a solution as the problem is not just the lighting, but that the maximum "useful" view distance, up to which you can recognize important details, doesn't correlate with the actual brightness of the ambient light. If the brightness exceeds the level at which you are able to recognize your close surroundings, you can also recognize details hundreds meters away. But below that level you almost instantly can't see your hand in front of your face. What is missing is a continuous transition from details being recognizable to details being not recognizable for the transition from day to night and back. Some details visible both nearby and a few hundred meters away too: http://i.imgur.com/z1XW5hX.jpg No significant details visible, neither close nor at a distance: http://i.imgur.com/En1iti0.png In the real world at some point everything looks more and more blurred the darker it gets and even in a full moon night you are barely able to recognize an idle person >100m away in a field of tall grass or >30m in the woods. But you are able to see and recognize large objects like trees, large rocks or bushes at great distance but way less detailed compared to daytime. To understand why this happens we have to look at the physiological characteristics of the human eye. The human eye contains mainly two different types of photoreceptor cells; the cones and the rods: Here we have a simplified representation of the retina showing the photo receptive rods (gray) and cones (colored) and some of the neurons (brown) responsible for the summation of the values of several rod cells and for connecting all photo receptors to the next layers of the retina: https://i.imgur.com/FgY38ol.png The cone cells are responsible for the vision in daylight. They provide color vision and are connected to the brain more or less one by one to achieve a high resolution, but they need relatively bright light to work. At night the rod cells take over. They are about a hundred times more sensitive to light compared to the cones but can not differentiate between colors. Additionally they form clusters of several rod cells to accumulate and amplify the light, leading to even more sensitivity. But because each of these clusters is connected to the brain as a whole, instead of every single cell on its own, they provide a lower resolution. That leads to a blurrier vision at night compared to the vision in daylight. To simulate this behavior the shader needs to blur each pixel depending on the brightness of the area around it. The darker an area is, the more it gets blurred: An object below a bright street light isn't modified at all, while a dark tree line gets heavily blurred. In addition to the more natural look of the night the shader significantly reduces the benefits of abusing the gamma settings: If you increase the gamma value the dark areas may be brighter but stay blurred and the removed details can not be recovered. While the shader is optimized for low visual impact when playing with normal gamma settings, you still can't reveal significant additional details by increasing gamma. Comparison of abusive gamma settings without and with the shader activated: shader off: https://i.imgur.com/WoybbOo.jpg shader on: https://i.imgur.com/NClatiF.png This leads to a much wider range of brightness of the ambient light usable for balancing: You neither need pitch black nights to restrict vision nor you need to reveal details hundreds meters away if you just want to allow player to travel the map at night without additional light sources. Besides that you wouldn't have to restrict the gamma correction itself as simply restricting the gamma correction is unfair to those players who really need it. While the blurriness is barely visible it could induce gaming sickness for some sensitive players. This is most likely to happen at some point during the in-game (nautical) twilight. At this time the ambient light reaches a level at which most of the surroundings are already a bit blurred but it is not yet dark enough to "cover it up". While this is the same in the real world, it is rather unusual in computer games. This discrepancy between expectation and reality could cause negative symptoms for some players. But it is also possible that the shader reduces the symptoms for other players if these symptoms are caused by small, noisy, barely visible details in the dark surroundings. As these details are hard to see, the tracking and focusing of them could draw much concentration or be tiring for the eyes and lead to headache or dizziness. Since the shader removes exactly these details it could reduce or even prevent this sort of gaming sickness. To evaluate these assumptions more players need to test the shader and report back. I know from my own experience that it takes a while to get used to the slightly changed look and feel of the game. When you test the shader for the very first time or the first time after a bigger change of some parameters it can take up to two hours until you have adapted to it. That means you shouldn't give up too early and keep on testing for a while even if you aren't pleased by the results right from the start. As described above; the shader is configured to cause as little visual blur as possible. This leads to even less blurriness than in the real world and should be kept in mind when comparing the results to real world examples. 2) IMPLEMENTATION: The following descriptions of two possible approaches are simplified as the detailed ones would go beyond the scope of this overview. First approach: https://i.imgur.com/1nP35pM.png rectangle - data ellipse - processing step The first approach uses adaptive blurring of the image: 1. The luminance of the neighborhood of each pixel is determined by calculating the luminance of each pixel, save the result in a separate buffer and then blur it with a fixed radius. 2. The result of step 1 is used to calculate the radii for the actual blurring of the frame. For this a function similar to 1.0/luminance is used. That means the brighter the neighborhood of a pixel is, the less blurred it gets. 3. The frame gets blurred according to the result of step 2. Second approach: https://i.imgur.com/w187akC.png rectangle - data ellipse - processing step The second approach uses the blending of the original and a blurred version of the image: 1. To get the luminance of the neighborhood of each pixel the image is blurred first and the result is saved in a separate buffer. Then the luminance is calculated and saved to another buffer. 2. Almost the same function like in the first approach is used to calculate the proportion of the original image and its blurred version for each pixel. 3. The original image and its blurred version are blended pixel-wise according to the result of step 2. If we want to compare the two approaches we just need to examine the third step as the first two steps are almost the same for both approaches. It is easy to see that the second approach is faster because a simple interpolation is faster than a convolution with a kernel of reasonable size. When it comes to the efficiency of the gamma exploitation prevention the first approach is superior. This becomes clear when we look at the frequency spectra of the results of both approaches: We assume that all frequencies of the input are equally distributed so its spectrum looks like this: Homogeneous input spectrum: https://i.imgur.com/x6ie9yS.png Then the output of a shader using the first approach would have the following spectra: The output spectra of the first approach for different light intensities: Day: https://i.imgur.com/eFfe3RI.png Early twilight: https://i.imgur.com/FI57zsg.png Late twilight: https://i.imgur.com/Xt9sS0i.png Midnight: https://i.imgur.com/WXb2HJA.png As you can see the darker the input is the lower is the cut-off frequency. All frequencies significantly higher than the cut-off are suppressed enough to be technically unrecoverable as their amplitude reaches virtually zero. So more and more details are removed beginning with the smallest(highest frequency) ones. For the second approach we assume the same input and the following spectrum of the blurred version of the input calculated by the first step: Fixed radius blur spectrum: https://i.imgur.com/CZHdJJ6.png Then a shader using the second approach would have the following output spectra: The output spectra of the second approach for different light intensities: Day: https://i.imgur.com/Z4dw7ob.png Early twilight: https://i.imgur.com/CurxrW3.png Late twilight: https://i.imgur.com/B5XwsHb.png Midnight: https://i.imgur.com/gf0b8jl.png In contrast to the first, the second approach lowers the amplitudes of all higher frequencies altogether. That means that unless in complete darkness all higher frequency details have significant non-zero amplitudes and could be recovered by unsharp masking. This renders the second approach ineffective against gamma exploitation as even a simple sharpen effect of the graphics card or the display could recover significant details. As the effectiveness against gamma exploitation is one important requirement the shader has to meet, it has to use the first approach. In addition to that you need to consider the following: - The shader should be applied prior to the tone mapping to guarantee that it only takes effect in low light environments like at night and not on dark surfaces at day - If you aim for physiological correctness you would need to configure the 2. step that the effect starts to fade in at the same luminance at which the colors start to fade out as at this time the transition between day- and night vision starts - To reduce the abuse of the gamma settings it has to be applied prior to the gamma correction. - If you plan to allow post-processing injectors like ReShade and shader suits like SweetFX (I hope you will!) then you need to decide whether you want to make the depth map accessible or not. Because if you do, you need to blur it too; otherwise it could be exploited as well to get something like "bat-/sonar-vision". If you follow these recommendations then you should have a fair solution, because everything has exactly the same level of detail for everybody regardless of their gamma- and brightness settings. The shader could be controlled server side, as it might lower performance on very old systems or could induce gaming sickness, but would really improve the fairness. Then it would be up to the player to choose between servers with and servers without the shader, but if they choose one with it enabled, they can be certain everybody uses it. 3) RESULTS: 3.1) Images: The screenshots were taken with ArmA 2 & 3, because it is easier to get a greater variety of scenes while ArmA and DayZ are comparable in terms of brightness/gamma. The previous screenshots (2015-02-23) were taken with ArmA 2 CO in Chernarus, the new ones (2015-12-18) with ArmA 3 in Chernarus and Altis. Example 1: NWAF shader=off, gamma=1.0: http://i.imgur.com/vUy36UQ.png shader=on, gamma=1.0: http://i.imgur.com/3o81CeK.png shader=off, gamma=2.0: http://i.imgur.com/b5TpP6d.png shader=on, gamma=2.0: http://i.imgur.com/Jhp9yNp.png Example 2: Hills north of Chernogorsk shader=off, gamma=1.0: http://i.imgur.com/woCzgqU.jpg shader=on, gamma=1.0: http://i.imgur.com/FmWA7aH.png shader=off, gamma=2.0: http://i.imgur.com/8Huxw0e.jpg shader=on, gamma=2.0: http://i.imgur.com/7Xwn7lf.png Example 3: Country house on Altis shader=off, gamma=1.0: http://i.imgur.com/5Hj7lg8.jpg shader=on, gamma=1.0: http://i.imgur.com/QfybDkh.png shader=off, gamma=2.0: http://i.imgur.com/KJaDEKT.jpg shader=on, gamma=2.0: http://i.imgur.com/bKiTRgN.jpg More examples in the same order like above for every row: New screenshots (2015-12-18): http://imgur.com/a/7G0b7/all (Chernarus) http://imgur.com/a/kuhsl/all (Altis) Previous screenshots (2015-02-23): (These are outdated, but I left them for comparison) https://imgur.com/a/1wWjW/ (Chernarus) https://imgur.com/a/S7Db4/ (Chernarus) 3.2) Performance: Tested on: - AMD Phenom II X4 965 Black Edition @ 3,4GHz - NVIDIA GeForce GTX 560 Ti - ASUS M4A89GTD-PRO/USB3 - 12GB RAM @ 1333MHz With ReShade 1.1.0 and the recent version of the shader. Test of ArmA 2 CO: The Shader takes 0.1-0.2ms to process one frame. No reduction of the frame rate observed. Test of ArmA 3: The Shader takes 0.01-0.02ms to process one frame. No reduction of the frame rate observed. The difference of one magnitude in the processing time between ArmA 2 and ArmA 3 might be a result of the different DirectX versions used by both engines. The shader should be at least as fast as in the test with ArmA 3 if it is included directly in the post processing of the new renderer (DirectX 11). 4) SUMMARY: Pro: - Combats the abuse of the gamma correction without restricting the gamma correction itself - Improves realism and authenticity - Gives the night a more natural look - Good performance Con: - Might reduce the performance on very old or minimalist systems without dedicated graphics - Could cause some problems for players who are prone to gaming sickness 5) CONCLUSION: The shader improves the authenticity and gameplay without changing the rest of the game or forcing the players to certain gamma and brightness settings. 6) SOURCE: The source can be found at: http://pastebin.com/Cm4y12Qq The attached source files are outdated and for the record only. 6.1) Installation and use: IMPORTANT NOTE: The shader hooks into the renderer and thus it might modify the memory of the running game. This could be classified as a sign of cheating/hacking and because of this it is recommended to test the shader in singleplayer/editor with disconnected networking. After testing and before reconnecting you should uninstall it by deleting the two files you copied during the installation. That might sound a bit paranoid, but better safe than sorry... :) During the installation you need to rename two files and change their file extensions too. For this you need to activate/show the file extensions in the windows explorer, if you haven't done it already: http://windows.microsoft.com/en-us/windows/show-hide-file-name-extensions 1. Download ReShade During the testing Reshade is needed for hooking into the renderer and loading/starting/toggeling the shader. It is available at http://reshade.me/ 2. Copy ReShade32.dll from the downloaded archive into ArmAs main directory (same directory like the arma2.exe/ArmA2OA.exe/arma3.exe) 3. For ArmA 2 (OA/CO) rename the copied ReShade32.dll to d3d9.dll, for ArmA 3 rename it to dxgi.dll 4. Download the shader file http://pastebin.com/Cm4y12Qq 5. Rename it to ReShade.fx 6. Copy this ReShade.fx into ArmAs main directory too. 7. That's it. If you now start ArmA ReShade should load the shader. Press [Insert] to toggle the shader on/off Press [Home] to toggle gamma 1.0/2.0 ReShade is not compatible with software like screen capturing or overlays and you need to deactivate them in order to test the shader. To take screenshots ReShade has its own screenshot functionality (but sometimes it seems to miss some keystrokes): Press [Print] to take a screenshot (they are saved to the same directory where you put the shader files)