RTSS Rivatuner Statistics Server Download Free – 7.3.5

Initially designed as a small helper application for RivaTuner graphics card utility, RivaTuner Statistics Server became de-facto framerate monitoring, On-Screen Display and high-performance videocapture service provider for other graphics card utilities.

Features

• The server provides framerate and frametime monitoring support to the client applications. Framerate and frametime statistics is being collected for DirectX, OpenGL and VULKAN applications. The statistics can be rendered in On-Screen Display or provided to client applications connected to the server.
• The server provides 3D acceleration usage statistics to the client applications. The clients can use the statistics to determine if any 3D applications are currently running and apply different hardware profiles depending on it.
• The server provides On-Screen Display support to the client applications. The clients can display any text info in the On-Screen
• Display in DirectX and OpenGL applications. The server can be also used as a standalone framerate monitoring solution and display own framerate statistics in the On-Screen Display.
• The server provides desktop and in-game screen capture support to the client applications. BMP, PNG and JPG screen capture formats are supported.
• The server provides high-performance real-time desktop and in-game video capture support to the client applications.
• Uncompressed, high-performance custom RTV1 and native MJPG video encoding, encoding with third-party external VFW compatible codecs (e.g. Lagarith or x264vfw) and hardware accelerated H.264 encoding via Intel QuickSync, NVIDIA NVENC and AMD VCE are supported in conjunction with wide range of additional video capture related options, multisource stereo and multichannel (for Window Vista and newer) audio capture with Push-To-Talk support. The functionality of expensive commercial video capture products is now available to everyone absolutely for free! There is no need to buy dedicated video capture software anymore!
• Framerate limiting support. Limiting the framerate during gaming can help to reduce the power consumption as well as it can improve gaming experience due to removing unwanted micro stuttering effect caused by framerate fluctuations.
• User extendable architecture. You may express your creativity and design your own skins for RivaTuner Statistics Server, create localization for your native language, use the server to display any custom text in On-Screen Display directly from your own application and many, many more!

Know Limitations:

• RivaTuner Statistics Server can be incompatible with some third-party On-Screen Display software (e.g. XFire or Steam In-Game Chat). The limitation is not specific to our product, many third-party products are designed to be the only On-Screen Display products in the system and to block their own functionality when any other On-Screen Display software is running
• Anticheat systems of some online games may restrict On-Screen Display usage and block connection to the server when the RivaTuner Statistics Server is running
• RTV1 encoder performance in 64-bit applications is currently lower than in 32-bit applications
• Stealth hooking mode is currently not supported in 64-bit applications, so it is strongly not recommended to run other 64-bit OnScreen Display software in conjunction with RivaTuner Statistics Server

System Requirements:

• Windows XP, Windows Vista, Windows 7, Windows 8, Windows 8.1, Windows 10 or Windows 11 (both x86 and x64 versions) with full administrative rights
• Any DirectX, Vulkan or OpenGL compatible graphics card

What’s New

• Ported to VC++ 2022 compiler. Please take a note that due to this change RivaTuner Statistics Server will no longer be able to start under Windows XP. Please stay on the previous versions of the product if you need this OS support
• Please take a note that size of mandatory VC++ 2022 runtime redistributables roughly doubled comparing to the previously used VC++ 2008 redistributables, and we’d like to avoid providing overblown application distributive, drastically increased in size due to bundling newer and much heavier VC++ redistributables with it. To deal with this issue we provide our own original tiny web installer for VC++ redistributables, which allowed decreasing the size of final application distributive drastically even comparing to the previous VC++ 2008 based version. Please take a note that install time can be increased slightly due to downloading VC++ 2022 runtimes redistributables on the fly during installation. If you install RivaTuner Statistics Server offline, you can always deploy required VC++ 2022 distributives later with web installer by launching .\Redist\VCRedistDeploy.bat
• Fixed issue in asynchronous skin scaling implementation, which could cause deadlocked RTSS.exe to stay in memory after closing application with [x] button from skinned GUI when skin scaling was enabled
• Fixed issue in RTSS desktop video capture module, which caused some cursor shapes to be captured improperly (e.g. ][ cursor displayed when hovering over edit boxes)
• Added extra synchronization to detours uninstallation implementation to minimize risk of crashing on attempt to exit RivaTuner Statistics Server during a game runtime when driver level framerate limiter is active and “Use Microsoft Detours API hooking” option is enabled
• Height of application profile names in application profiles list is now scaled properly when you adjust skin scaling ratio
• Now RivaTuner Statistics Server reinitializes skin scaling engine on DPI scaling change events to prevent cases when GUI looks cut off in some cases (e.e. after switching between display resolutions with different DPI scaling settings)
• Now uninstaller removes configuration files for OverlayEditor, HotkeyHandler and DesktopOverlayHost when you choose clean uninstallation mode. Please take a note that your own overlay layouts stored inside .\Plugins\Client\Overlays folder will never be removed during uninstallation by design
• Now RivaTuner Statistics Server ignores its own process and DesktopOverlayHost in screen and videocapture requests. So you no longer see unwanted screenshots or videos captured from OverlayEditor’s or DesktopOverlayHost’s 3D windows when you open them simultaneously with other 3D applications and initiate screen or video capture
• A few improvements in delayed injection implementation, aimed to minimize cases when delayed injection needs to wait for keyboard or mouse input event to be triggered:
• Now delayed injection events are excluded from filtering by minimum allowed reinjection interval
• Now delayed injection events are invoked by dummy window creation instead of posting dummy system message
• Added EOSSDK-Win64-Shipping.dll to the list of delayed injection trigger modules to enable delayed injection for the games compiled with Epic SDK, but using delayed loading of Epic overlay hook module
• Improved IgnoreDXGIInterop profile entry functionality. Previously this entry was used to ignore interoperability DXGI flips in OpenGL/Vulkan presentation environment, now it can be set to 2 to achieve opposite effect: ignore OpenGL/Vulkan presentation and favor DXGI instead. Such mode can be used if you prefer to use Direct3D overlay rendering implementation in native OpenGL/Vulkan applications using OpenGL/Vulkan<->DXGI interoperability. Currently RivaTuner Statistics Server enables such mode via application profile for NvRemixBridge.exe only to address native Vulkan renderer’s incompatibility with NVIDIA’s Vulkan Frame Generation implementation in Portal Prelude RTX
• Slightly optimized the process of ignoring interoperability DXGI flips in OpenGL/Vulkan presentation environment. Previously DXGI flips were ignored after rendering the first overlay frame on interop DXGI swapchain, now Direct3D overlay renderer is not initialized in such environment at all
• Added late initialization of bootstrapped objects aimed to improve Vulkan hooking reliability in the applications dynamically loading vulkan-1.dll (e.g. Ryujinx or Rage 2) on the systems with multiple installed third party Vulkan layers
• Improved hypertext parser:
• Image loading <LI> hypertext tag handler has been improved to allow loading embedded images from external folders
• Now hypertext parser supports application specific embedded images. You may use this feature to display game specific logos in your overlay layouts. ovl layout included into distributive demonstrates this technique by displaying game specific logos for Escape From Tarkov, Forza Horizon 5 and Ratchet and Clank : Rift Apart
• Now hypertext parser accepts both ANSI and UTF-8 encoded degree Celsius symbol
• Added new rendering style for embedded graph objects – bar range graphs. New style is the subset of previously existing barchart, but it is aimed to visualize the range instead of a single value. Please take a note that bar range graphs cannot be attached to arbitrary data sources, it requires specifically encoded data sources containing both min and max range limits packed inside each data sample. Currently NVIDIA Reflex timespan data sources group (see below) are the only ones using such packed data format, compatible with bar range graphs
• Added NVIDIA Reflex latency markers support:
• Added NVIDIA Reflex latency markers monitoring for Direct3D11/Direct3D12 applications with native NVIDIA Reflex support. Reflex latency markers are embedded into the games as a part of NVIDIA Reflex technology integration process. The markers are allowing game developers and NVIDIA Reflex software infrastructure to track precise timings of different stages of rendering pipeline and estimate the effect of enabling Reflex low-laterncy mode. Now such markers can be also analyzed via RivaTuner Statistics Server. Furthermore, RivaTuner Statistics Server also exports raw NVIDIA Reflex latency markers as is via shared memory to third party client applications (e.g. HwInfo, AIDA64 or CapFrameX), so such applications also get easy access to Reflex latency markers and can visualize them or calculate additional statistics based on raw markers
• Added NVIDIA Reflex latency markers injection for Direct3D11/Direct3D12 applications with no NVIDIA Reflex support. Please take a note that injected simulation related latency markers can be inaccurate if the game is not starting simulating world in render thread immediately after presenting the previous frame
• Added ID3D11DeviceContext::ClearRenderTargetView hook for render submission start related NVIDIA Reflex latency markers injection in Direct3D11 applications
• ID3D12CommanQueue::ExecuteCommandLists hook is now always active and used for render submission start related NVIDIA Reflex latency markers injection in Direct3D12 applications. Now this hook forcibly uses Detours injection mode to improve concurrent command queue hooking reliability
• Improved framerate limiter:
• Added new framerate limiting mode : NVIDIA Reflex mode. In this mode RivaTuner Statistics Server completely disables its own precise framepacing implementation and uses NVIDIA’s own framerate limiter instead. This mode is mainly intended to be used in conjunction with DLSS Frame Generation, which is generally not compatible with any third party framerate limiters. However you can also use this mode in the games with no native NVIDIA Reflex support, because enabling NVIDIA Reflex framerate limiter in such titles will also enable Reflex low-latency mode as a side effect. Please take a note that NVIDIA Reflex framerate limiting mode is currently supported on NVIDIA GPUs and in Direct3D11/Direct3D12 applications only. If you try to enable it on unsupported hardware on in unsupported applications, RivaTuner Statistics Server will fall back to default async framerate limiting mode
• Default passive waiting threshold has been decreased from 90% to 70%
• Minimum active waiting time limit is no longer hardcoded, it can be customized by power users via profile now
• Added alternate high resolution waitable timer implementation for Windows 10 1803 and later
• Added experimental interleaved passive waiting implementation. In this mode passive waiting can be performed on each N-th frame instead of every frame to tune balance between precision and power consumption
• Now you may right click framerate limit edit field to display the context menu. The menu allows you to select precise refresh rates of each connected display (so you can use it to simplify the process of setting up hybrid scanline sync mode) or select VRR cap calculated as 95% of each connected display’s refresh rate. Please take a note that the previous alternate way of setting framerate limiter to precise refresh rate of desired display is still supported too. You may hold <Alt> and click framerate limit edit field to set it to refresh rate of display showing RivaTuner Statistics Server’s window
• Added experimental preemptive waiting implementation. Power users may use it in hybrid scanline syncmode in conjunction with front edge sync framerate limiting mode to shift balance between front edge sync (favors tearline stability) and back edge sync (favors latency) mode
• Improved scanline sync technology:
• Now specified framerate limit is automatically multiplied or divided by 2 if you select scanline sync 2x or x/2 modes when hybrid mode is enabled. So it is no longer necessary to specify double or half refresh rate value as a framerate limit manually for such usage scenario
• Now you may right click scanline sync edit field to display the context menu. The menu allows you to select target display device for scanline synchronization in multimonitor environment. It is no longer necessary to specify it manually via SyncDisplay profile entry
• Improved OverlayEditor plugin:
• Fixed keyboard based layer position adjustment when “Snap to grid” option is disabled
• Fixed buffer overrun in OverlayEditor’s GUI, causing it to crash when total text length displayed in “Cell” column of “Text table properties” window was longer than 260 symbols
• Fixed Intel IGCL GPU enumeration routine, causing additional ghost GPU to be detected on the systems with multiple Intel GPUs
• Fixed status bar panes and hypertext debugger panel rendering for high DPI scaling modes
• Added experimental support for mobile AMD Ryzen 7xxx CPUs
• Now OverlayEditor supports saving overlay layouts to or loading overlay layouts from external folders. To allow you to differentiate local (i.e. stored inside .\Plugins\Client\Overlays) and external layouts, local layouts will be displayed as naked filename only in editor’s window caption (e.g. “Overlay editor – sample.ovl”), while external layouts will be displayed with full filepath
• Now OverlayEditor supports context highlighting for text file embedding <F=textfile.txt> hypertext tag. Visual tag browser displayed when you type in <> in hypertext field also support inserting <F> tag
• OverlayEditor is no longer rendering the very first frame with no sensor data displayed, now it is always rendering the first frame after polling all data sources
• %CPUShort% macro is additionally packing Ryzen CPU names now. “Ryzen N” name is packed to “RN”, and “Ryzen Threadripper” is packed to “TR” with this macro
• Added %GPU2%, %GPU2Full%, %VRAM2%, %Driver2% … %GPUx%… macro names support for multi-GPU systems
• Added conditional layers support. This powerful feature allows you to add programmability to your overlays and make them look different depending on some conditions, which you can program yourself. For example, you may create differently looking overlay on AMD and NVIDIA GPUs, you may create different representation of CPU usage bars depending on logical CPU count, add special layers displaying thermal alerts when either CPU or GPU is overheating, add layers visible depending on PTT-styled keyboard polling and so on. Conditional layers support is based on two key components:Seriously improved correction formula parser in data source settings window, which is allowing you to program complex logical conditions and create so called boolean data sources, which report true (1) or false (0) depending on condition you define:
• Relational operators support: <,>,<=,>=,== and !=. Result is boolean true (1) or false (0). For example, you may define boolean data source called IsGpuOverheating with correction formula “GPU1 temperature” >= 80, which will return 1 when GPU temperature is above or equal 80C, otherwise it will return 0
• Logical operators support: ||, &&, !. Result is boolean true (1) or false (0). Logical operators allow you to combine multiple conditions, for example you may define boolean data source called IsGpuFanFail with correction formula (“GPU1 temperature” >= 80) && (“GPU1 fan tachometer” == 0), which will return 1 when GPU fan is not spinning AND temperature is critical (so it is not an idle fan stop case)
• Bitwise operators support: &, |, ^, ~, << and >>. Please take a note that ^ was used for power operator before, however we see no practical use for power operators in correction formulas so it is no longer supported. ^ is used for bitwise XOR operator now
• Ternary conditional operator support: condition ? expression1 : expression2. Result is expression1 if condition is true, otherwise it is expression2. Please take a note that Basic-styled syntax for ternary conditional operator syntax is also supported, so you can also use alternate if(condition, expression1, expression2) syntax depending on your preferences
• Hexadecimal const values support. C-styled syntax with 0x prefix is supported, for example x+10 formula can be also represented as x+0xa
• New cpuvendor, gpuvendor and cpucount variables support allow you to check CPU/GPU vendor identifiers or logical CPU count and use it in your overlay. For example, you may define IsNVIDIAGpu boolean data source and set correction formula to gpuvendor == 0x10de, then use it to display NVIDIA logo in your overlay only when NVIDIA GPU is installed on end user’s PC. Modified sample.ovl overlay layout demonstrates this technique to display AMD/Intel CPU logos depending on CPU vendor id and use different CPU usage bars layouts depending on logical CPU count
• New rtssflags variable support allows you to check some global RTSS flags. It allows you to check if framerate limiter, video capture or benchmark mode is currently active. For example, you may define boolean data source called IsBenchmarkActive and set correction formula to (rtssflags & 0x100) != 0 to check state of benchmark mode activity bit
• New validate(expression) function returns boolean true (1) when expression result is valid, otherwise it returns 0. For example, you may use it to check if some data source if physically supported on your system (unsupported values are invalid and reported as N/A). If you’re importing a data source from external provider, e.g. HwInfo, data can be invalid and reported as N/A when provider application is not running, so you may also effectively use validate() function to check if data is currently available. This function is useful when you combine it with ternary conditional operator, for example you may define formula validate(x) ? x : 0 for a data source importing data from HwInfo to make sensor report 0 when HwInfo is not running
• New key(vkcode) functions allows to poll keyboard and return key press counter and current key up/down state bit. Please take a note that OverlayEditor uses new dedicated HotkeyHandler’s interface to access its low-latency keyboard polling status, so HotkeyHandler must be also active for this function to work. For example, you may define boolean data source called IsKeyDown and set correction formula to (key(0x41) & 0x80000000) != 0 to report 1 when keyboard key ‘A’ is down, then use it to apply PTT-styled visibility to show some specific layer. Alternately, you may define boolean data source called IsKeyToggled and set correction formula to (key(0x41) & 1) != 0 to check bit 0 of key press counter, which is incremented each time you press it. This way you can effectively implement some layer visibility toggle depending of this pre-programmed key in your overlay
• New “Visibility source” setting in layer properties allows you to use one of boolean data sources defined in your overlay and representing some logical condition to show or hide the layer depending on it. If there is no binding in “Visibility source” setting, the layer will be always visible as before. Otherwise it will be visible only when visibility source reports a value different from zero
• Added <IF>/<ELSE> and <SWITCH>/<CASE> hypertext extension tags support. Power users may embed these extension tags directly into hypertext instead of “Visibility source” setting to make some parts of layer visible depending on some condition. Please take a note that nested conditional blocks are not supported, so new <IF> tag always closes the previous open conditional block or immediately opens new one. Also, more complex expressions are not allowed into hypertext too, you can only use boolean data sources there. The only exception is ! (NOT) symbol, which is allowing you to invert value reported by boolean data source. Also, please take a note that <IF>/<ELSE>/<SWITCH>/<CASE> tags are extension tags parsed at OverlayEditor plugin level. They are not native hypertext tags, so you cannot use them to format hypertext inside external applications like CapFrameX or AIDA
• Added PresentMon data provider. Now presentation related metrics from Intel PresentMon (including GPU busy, introduced in PresentMon 1.9.0) can be displayed directly in OverlayEditor’s layouts:
• Added helper PresentMonDataProvider.exe application, which localizes all PresentMon interoperability in a separate process. PresentMonDataProvider supports PresentMon data streaming either from modern independently installable PresentMon service (downloadable from https://game.intel.com/story/intel-presentmon/) or from legacy PresentMon console application, bundled with the plugin. Please take a note that modern PresentMon service provides additional CPU/GPU telemetry, so this data is not available in OverlayEditor’s PresentMon data provider if you don’t install the service and stream it from legacy console PresentMon
• Please take a note that PresentMon reports data with noticeable time lag, which varies from 0.5 to 2.5 seconds on our hi-end test system. We added our own msReportingLag to PresentMon data provider, so you may see it in your overlay layouts. Lag is just a part of problem, the worst thing is that the lag is not static due to batching streamed frames inside PresentMon (which means that it may collect a few frames then stream them all at once). So, if you try to render PresentMon’s frametime graph in realtime using streamed data as soon as you receive it, graph scrolling will be extremely jerky due to batching. However, it is still possible to implement smooth scrolling of PresentMon’s frametimes with a simple trick, if you apply some fixed delay to it. Delay must be large enough to compensate the maximum PresentMon’s reporting lag. We selected fixed 3000ms delay in our implementation, which allows smooth scrolling. Delay is not hardcoded, it is defined by PM_DisplayDelay overlay environment variable (can be edited in Layouts -> Edit -> Environment variables)
• Added new built-in overlay layouts demonstrating PresentMon integration functionality and displaying native realtime RivaTuner Statistics Server’s frametime graph on top and overlapped PresentMon’s frametime and GPU busy graphs below. Most of reviewers prefer to see the frametime graph displayed on per-frame scale, as it is the only real way to diagnose and see single frame stutters. However, native Intel’s PresentMon overlay displays it on averaged time scale. So to allow you to compare apples to apples we included two different versions of overlay layouts for PresentMon in RivaTuner Statistics Server distributive: ovl and presentmon_time_scale.ovl. presentmon_frame_scale.ovl displays PresentMon’t frametimes on per-frame scale, similar to native RivaTuner Statistics Server’s frametime graph. presentmon_time_scale.ovl displays PresentMon’s frametimes on fixed time scale, defined by user adjustable overlay refresh period (33ms by default). Averaging window for this overlay layout is adjustable via environment PM_AveragingWindow variable and it is set to double refresh period (66ms) by default. Both layouts display PresentMon’s data with fixed 3000ms display delay to allow smooth scrolling
• Added ovl overlay layout. This layout demonstrates alternate foreground application based PresentMon data collection mode, controllable via PM_ProcessId environment variable. You may use this layout to display PresentMon’s framerate and frametime in applications like BF 2042, FIFA 23, CS2 or Destiny 2, which do not support RivaTuner Statistics Server’s native hook based framerate / frametime monitoring
• Both built-in PresentMon based overlay layouts use new conditional layers functionality to display dynamic “Limited by CPU/GPU” bottleneck indicator. The indicator is based on boolean IsGpuLimited data source applied to PresentMon’s frametime and GPU busy streams and defined as (msGpuActive / msBetweenPresents) >= 0.75. In ideal GPU limited case this ratio should be as close to 1 as it is possible, but in reality there is always some CPU overhead so the threshold was reduced to 0.75 to take overhead into account. Please don’t forget that you can always edit built-in layout and increase the ratio inside IsGpuLimited data source’s formula, if you find the threshold too low
• Now OverlayEditor supports environment variables for overlay layout. The variables can be changed in Layouts -> Edit -> Environment variables Currently environment variables are used to tune advanced properties of PresentMon data provider. Power users may also use environment variables during development of complex overlay layouts with hardware dependent conditional layers (e.g. sample.ovl, which is displaying Intel or AMD logo depending on CPU vendor). In such usage scenario you may use overlay environment variables to emulate different hardware and test your overlay look on it (e.g. set environment variables to “cpuvendor=0x1022;cpucount=8;gpuvendor=0x1002” to emulate a system with 8 thread AMD CPU and AMD/ATI GPU on a PC with Intel CPU and NVIDIA GPU)
• Minimum refresh period for overlay layout is no longer limited by 100ms. Now you can decrease it down to 16ms. Please take a note that such low refresh period is intended to be used with PresentMon’s data sources only. Use it with caution and avoid defining such low refresh period values for overlays using other types sources, which poll hardware on each refresh period and may decrease system performance due to such high polling rate
• Improved OverlayEditor’s data sources polling architecture. Now each data source can be polled asynchronically with own refresh period. This feature is currently reserved for new PresentMon’s data sources only, which can be polled and updated with independent refresh period. New PM_RefreshPeriod environment variable defines asynchronous refresh period for all PresentMon’s data sources at once. If PM_RefreshPeriod is not defined or set to 0 in environment variables, PresentMon’s data sources will be also polled synchronously with the rest data sources
• Added power user oriented config file switch allowing using idle based rendering loop for OverlayEditor’s window instead of default timer based rendering loop
• Now you can use the layer’s refresh period setting to slow down layer updates. Initially this setting was intended for speeding up layer updates only, when you were rendering timer driven sprite animations there
• Added “NVIDIA Reflex XXX timespan” and “NVIDIA Reflex XXX latency” groups of data sources, based on NVIDIA Reflex latency markers. Timespan sources contain packed ranges for independent stages of rendering pipeline, normalized relatively to the rest stages. Latency sources contain absolute times of each stage. All new sources are internal, which means that they are always available and you don’t need to add them to data sources list prior to referencing them in your overlay layouts. Please take a note that timespan sources contain specifically packed ranges, which are designed to be used with new bar range graphs
• Added ovl overlay layout. This layout demonstrates the usage of new “NVIDIA Reflex XXX timespan” and “NVIDIA Reflex XXX latency” groups of data sources and new bar range styled graphs to visualize NVIDIA Reflex latencies in debugger-styled color timebands form
• Improved data source statistics access functionality. Previously you could access each data source’s statistics via local xmin/xavg/xmax/xswa variables specified inside the source’s correction formulas only and such variables couldn’t be accessed from other data sources. Such local statistics variables are deprecated since this version, now you can use more robust functions for accessing each data source’s statistics:
• New statmin, statavg, statmax and statstd functions can be used to get global min/avg/max/std statistics for each data source and you can access it from other sources, e.g. you may use statavg(“CPU power”) + statavg(“GPU1 power”)) to calculate average CPU+GPU power consumption. Global statistics is collected during whole OverlayEditor’s runtime session for synchronically polled sources only, for frametime and PresentMon’s data sources it reflects the last 1024 samples only
• New swmin, swavg, swmax and swstd functions can be used to get sliding window based min/avg/max/std statistics for each data source, for example you may use swavg(“CPU power”, 8) to smooth CPU power consumption graph by calculating average CPU power with sliding window by 8 last sampled CPU power values. Maximum sliding window size is limited by each data source’s ring buffer size, it is 512 samples for the most of OverlayEditor’s data sources and 1024 for internal frametime and PresentMon’s data sources. You may specify sliding window size as 0 to use whole ring buffer
• New percentile and percentilei functions can be used to calculate classic (linear) and integral percentiles on ring buffer contents, so you can use it to calculate 1%/0.1% low framerates on PresentMon’s data or add you own percentile based metrics. New ovl demonstrates new functions usage to display 1%/0.1% low framerates
• Added new hardware VBlank counter based data sources to internal HAL. New data sources provide dynamic refresh rate monitoring functionality for displays connected to NVIDIA GPUs
• Added new ovl overlay layout. This layout simulates pixelated look of display’s native refresh rate counter and displays it next to the application’s framerate. You can use it to monitor GSync activity status, analyze LFC behavior specifics of your display etc
• Fixed instances enumeration for some performance counters with no localized names in Windows performance counter data provider (e.g. GPU related Windows performance counters)
• Improved HotkeyHandler plugin:
• Added asynchronous keyboard status polling interface for interoperability with new OverlayEditor plugin
• Bundled DesktopOverlayHost tool has been upgraded to v1.3.3:
• DesktopOverlayHost is now compiled as UIAccess process, which allows it to be displayed on top of most of modern fullscreen applications similar to xbox gamebar gadgets. You may use it to display mirrored overlay copy on top of applications like Destiny 2 and CSGO, which do not allow traditional hook based overlay rendering. Please take a note that Microsoft is allowing UIAccess window to be displayed on top of normal windows (including fullscreen game applications) only when the process is installed in secure location (i.e. Program files and subfolders). So you won’t be able to use UIAccess topmost rendering functionality if you install RivaTuner Statistics Server inside some custom location (e.g. D:\Applications\RTSS)
• Added tiny DesktopOverlayHostLoader.exe companion process. UIAccess processes cannot be launched by Windows task scheduler, so companion loader process is necessary to start DesktopOverlayHost at Windows startup
• Added power user oriented config file switch allowing enabling flip model for DesktopOverlayHost’s Direct3D11 rendering backend
• ReShade compatibility related D3D1xDevicePriority setting has been reverted to select old ascending D3D1x device selection priority by default. So it is no longer necessary to change this setting to unlock overlay support in D3D10 applications
• Slightly changed Vulkan layer to improve conformance to Vulkan specs
• Added experimental support for “Beta : Use Unicode UTF-8 for global language support” option enabled in administrative regional OS settings. Now each localization description file contains additional “Codepage” field, defining runtime ANSI to UTF8 conversion rule for selected language pack
• Seriously revamped German and Ukrainian localizations
• Removed outdated Spanish and Korean localizations, abandoned by their creators
• Added target process filtering support for debug logging system
• Added On-Screen Display profile for The Texas Chainsaw Massacre and common technique aimed to improve stability in future applications using similar behaviors
• Added On-Screen Display profiles for OpenGL renderers of some console emulators to select framebuffer as On-Screen Display coordinate space for such applications
• Updated On-Screen Display profile for Prepar3D v5 to remove WPF runtime modules from injection ignore triggers for this application
• Updated profiles list