MSI AB / RTSS development news thread

RTFM and please avoid continuing discussing it in this thread further.

 

Enable voltage monitoring, or scroll monitoring graphs list down if it is already enabled. And PLEASE stop using this thread for general questions, it is not intended for "help me" or "how to" questions. Why do I need to ask about it on each page and each new user think that he can ignore that? Please keep this thread clean.

 

No need to continue it here PLEASE.

 

It is going way too far and I'm really tired of it.
There are dozens of questions about specifics of zero fan speed mode implementation on 30x0 series hardware in the previous posts in this thread. You ignored that and prefered to spam exactly the same and PREVIOUSLY ANSWERED question in the same thread.
I aked to stop discussing 30x0 fan control in this thread a lot of times in the past. I explicitly warned that any attempts to discuss zero fan speed on 30x0 further in this thread will be removed without any notifications. You ignored that because you don't care.
There is detailed explanation of intended "Override zero fan speed with hardware curve" functionality in this thread. There is detailed desсription of this option functionality in the context help supplied with application. You didn't bother to read it but prefer to tell that it is broken without even understanding what it is supposed to do in reality.

What did you done after that in reactoin to my request to read manual and stop discussing that in a thread, which is not intended for that? Probably appologized? Nope, you tried to report my post instead and stole a bit of my nerves, as any lazy ego user.
My patience is over, I just start silently killing any posts containing such "quesitons" in development thread. I cannot make new forum visitors to read previous posts. But I can protect this thread from your endless flows of offtopic, which always end by "poor users trying to report posts of evil moderator".

 

New features on the way in the next RTSS beta:

- RTSS hypertext syntax got improved, <I> image embedding tag supports arbitrary rotation of embedded image now.
- New OverlayEditor uses this new hypertext feature for both static and animated images. Rotation support in animated images is the most useful thing, I made it possible to bind rotation angle with attached data source for animated images. This way you may easily create different types of animations, e.g. implement analog clock arrow styled indicatos (demonstrated in new sample overlay layout on top of sprite round CPU/GPU/RAM/VRAM usage indicators). In my sample I defined one sprite representing arrow then simply animated it by mapping 0-360 degree clockwise rotation range to 0-100% range of CPU/GPU/RAM/VRAM usage. Rotation support for animated images also allows to implement existing animated fan speed indicator much easier now: you no longer need to define multiple sprites for each frame of rotation, instead you may define just two sprites for fan frame and fan blade and rotate the second one.

 

I've added more useful things to upcoming RTSS beta during past weekend. Probably some of you who actively used RTSS & OverlayEditor know, that it can display correct independent framerates / frametimes in graph or text form in overlays of multiple simultaneously running 3D applications. That is acheived by avoiding formatting framerate/frametime text explicitly and using hypertext <FR>/<FT> tags, which are converted to final text/graph form by hypertext parser in context of running 3D application using framerate and frametime specific to host process. However, it was not possible to do the same with animated indicators associated with framerate/frametime because animation tags were formatted globally by OverlayEditor, so it could reflect framerate of foreground 3D process only if you run multiple 3D applications. Now it is possible to bind animation with such process specific data sources and it will work correctly in multiple independently running 3D applications. This is acheived by introducing concept of general purpose variables and adding new <V> tag to hypertext parser. Now hypertext can use general purpose variables to calculate and store some dynamic helper values using application specific framerate and frametime. A variable can be referenced by subsequent hypertext tags as the parameter. If you look at focused analog frametime gauge indicator displayed on this screenshot and peek into hypertext debugger window, displayed in the bottom of editor, you can see how it works now. Hypertext of focused frametime gauge layer is highlighted by blue color on the screenshot. As you can see, hypertext first assigns result of _MAP function call to V1 variable. The function is using current frametime and mapping it from [0;100] to [-112;112] range. Then subsequent image embedding <I> tag uses V1 as image rotation angle.

 

All

Official Vulkan support has been recently released in Ryujinx emulator, I've seen a few reports claiming that it doesn't work with RTSS at the moment. I can confirm it after testing it myself. Happily you can easily fix it yourself: to make it working with Vulkan backend of this emulator open and edit .\Vulkan\RTSSVkLayer64.json, find "api_version" item and replace "1.1.73" with "1.2.135".

 

Too much of DXVK, sorry. I cannot constantly chase for their “improvements”.

 

Tried latest CEMU 1.27.1 with current public RTSS beta, see no problems there:

 

All that unnecessary mess about patching API version inside layer's JSON seem like some bug inside Vulkan layer loader for me. As far as I see the concept, the versions are inteded to reflect the API version layer itself is using for Vulkan runtimes, versions are forward compatible so the case with Ryujinx when loader refusing to load 1.1 layer in application manifesting 1.2 API usage sounds illogical for me.

 

Found this comment from Vulkan creators. Backward compatibility break in layer loader is intentoional. So patching it each time new loader version is released is a must sadly, otherwise the layer won't work.