It’s finally here! Bout to watch it.
3 Likes
I saw this as well and Congrats Kal! Hopefully it brings some new traffic through here and the patreon.
I know that the video focuses on HDR but I was hoping DF would at least mention SK’s framerate limiter capability.
I really want DF to shows people how much gaming experience can be improved with a proper framerate limiter.
Like, in AC:Odyssey, that game insists on running at +1fps natively (31fps, 61fps,… WHY?
) and it’s terribly stuttery without SK.
I just got AC:O in the recent sale and super thankful
that Special K exists and supports this game.
Nice, special K is working in ac odyssey? I had a rough time of it last year
Hmm, that and basically every other major feature. Perhaps in a separate video 
The trailer summarises a lot of the features quickly, and i intend to finish the shader debugging document soon.
1 Like
I could of sworn at the beginning something about using it to improve framerates/frame times in some game, but ya would have been nice to give a run down of the features, even if they didn’t go into depth on them. Although just having this should help with exposure.
It’s mentioned Special K can do more, and has an OSD, but the other features including how consistent the frame limiter is were basically glossed over. Not a bad thing, since the video is specifically about HDR injection, but i do hope they dedicate another video to the tool itself.
1 Like
When it comes to the special k limiter, I think genuinely reaching some of the competitive scenes that would benefit from special k (like the fighting game community especially, tekken, streetfighter, dbfz, melee on dolphin emulator etc) as they’re all terrible ports or emulated. The scene has huge social media followings often and it would reach many ears, at least that’s my goal.
The only caveat is that Special K would need to guarantee not adding latency with its framerate limiter. That should truly be an easy task considering many of them have to use RTSS’ framerate limiter for fixing stutters on PC.
So… TL;DR
I’m waiting for LDAT to finally be put into the hands of Kaldaien and Jorimt from Blurbusters so there can be more empirical data and proof (and improvements)
Once that happens, I’ll do my part of getting it spread in big circles given that it works of course 
That’s impossible. I can remove worst-case and average-case latency, but any framerate limiter is always going to have an impact on best-case latency. I don’t usually optimize for best-case, I don’t consider it a valid way of optimizing things, but to make that guarantee, requires no change in best-case.
I understand that completely, I may have hugely misworded myself - the delays added by special K for the benefits of reduced delay elsewhere / consistent frametimes etc need to at minimum “equal out” and since RTSS is able to do this trade-off at an acceptable level… I have faith in special k 
There’s people using RTSS for this very purpose right now - meaning that there is no way Special K wouldn’t be able to do the same, but a million times better (at least in my opinion) your swapchain optimization techniques along with some other low latency features + nvidia limiter as you showcased had ridiculously low render latencies shown by capframex, although that’s somewhat “faulty” testing. I’m very curious to see what LDAT results end up being. I have a lot of belief in special K boosted fighting games as they are truly terribly optimized.
With the new framelimiter options in RTSS + 100% busy wait you can get the same results in RTSS, I’m not seeing the issue. It sleeps by default to reduce CPU usage.
This forum in a nutshell is
“RTSS bad!”
and ego stroking of single person.
The latest beta releases sounds like they contain a few new requested features like per-process memory monitoring instead of the total or allocated amount but I think one other feature is also HDR support and retaining functionality although the info around this is spread over multiple topics or even different forums.
(Kaldaien on Assassin’s Creed Valhalla from Reset Era’s PC Performance topic.)
Otherwise I think some configuration could yield some pretty good results with RTSS that are even if not the best possible probably fairly good overall and compared to many issues with in-game FPS limiters and even AMD’s and NVIDIA’s although their newer one seems to be much improved for what driver controlled framerate limiting can achieve.
Haven’t gone into it as much myself though far as latency and input delay is affected here or how SpecialK further leverages flip model presentation with VSync in addition to FPS limiting and functionality in Windows 8 to Windows 10 it’s quite technical for my own level of understanding about some of these functions.
Meh, that’s simplifying it. Both tools are different but somewhat related answers to similar questions, with their own advantages or disadvantages. For SK it comes down to how its swapchain management features can improve the rendering and FPS limiting situation, and for RTSS it comes down to it’s higher compatibility as well as DX12 and Vulcan render support.
If you actually stick around you’d see RTSS get recommended or mentioned to users enough times as an alternative to SK to make the difference irrelevant — it’s not as if SK users are incapable of recommending it after all.
Beyond that, did you really not expect praise be levied at a creator by users on a place of discussion created by the creator and dedicated to said creation?
Uh, so do I. Why would you want a limiter that busy-waits? That just burns through CPU cycles.
You can wait on a lot of scheduler constructs… 1) the swapchain, 2) a high-precision event timer, 3) a secondary thread that signals the limiter thread to wake up before VBLANK.
None of that has anything to do with, well, anything
If it took RTSS busy-waiting to achieve the same results as Special K, then time to go back to the drawing board. SK only spends 18.5% of its projected wait time in a tight spin, the rest is comfortably asleep.
Nonetheless, happy to see RTSS’s framerate limiter is improving. I have offered the source code for mine for quite some time now, figured it was going to continue falling on deaf ears.
Yes, I am now compatible with Ubisoft’s DRM / anti-debug. I kinda had to sell my soul to make it happen though
A lot of debug features that made analyzing games a lot easier in SK had to be turned off and they’re not worth making configurable, so this means whenever I need those features in the future I will have to compile a special build on my end. Nobody else really needs the debug features I was using, they were enabled by default so that I could gauge their performance / compatibility. I have gauged both and if Ubisoft didn’t exist, the features would be 100% performant and compatible and would be on all the time
Apparently, it’s really fun to drive Civ01 crazy 
What was that discussion we were having about RTSS supposedly sleeping to save CPU? Cause, SK uses less CPU than RTSS did before this busy-wait feature discussed was added. RTSS’s CPU usage has nowhere to go but even higher and if that’s what it takes to match SK’s performance, the whole thing should be scrapped in favor of something more efficient.
Realistically, SK’s limiter should just be integrated because it’s not even a fair fight. It’s open source, Unwinder can have it as long as the LGPL obligations are upheld.
Narcissistic and condescending person calls someone else’s behaviour crazy. What a joke.
What this out of context test supposed to show? RTSS limit and custom sync never was intended to be used in D3D12 with waitable swapchains, there is no POINT there. You wanna throw random advantages around? Okay:
RTSS works on Windows XP
RTSS works on Windows 7
RTSS works on Windows 10
RTSS supports D3D9
RTSS supports D3D10
RTSS supports D3D11
RTSS supports D3D12
RTSS supports Vulkan
RTSS supports custom scanline-sync, now customizable more than ever
RTSS compatible with more games
Shall we continue this childish behavior? Or it is time for you to get upset that someone pointed out such behabipour of yours and ban the blasphemous? Clearly that is the only solution to the problems (which you’ve cultivated as a matter of fact) yourself you understand. Ban, blacklist steam id, etc.
You’re the one who came into this discussion with some kind of stupid stick up your butt, talking about how efficient RTSS is. I’m humoring you, but really, we both know you had nothing productive in mind when you came here. You just wanted to be a nuisance and throw labels around – why? I really don’t know, and I don’t care either.
WTF are you even talking about? LOL
No, I don’t want to throw random anything around. I want you to acknowledge that busy-waiting will only serve to make RTSS use more CPU than it already does. Your claim was that it was designed to sleep for efficiency, and that by busy-waiting it now achieves the same results.
It most certainly does not, by busy-waiting, it blows through an entire CPU core’s CPU cycles. It got less efficient, not more. SK already used less CPU than RTSS did in the first place.
You can accuse me of all manner of ridiculous things you want, but the fact of the matter is that SK is Open Source and I have offered my framerate limiter to anyone who wants it. If I were “narcissistic,” don’t you think I would kinda, you know, not do that?
RTSS using twice as much CPU even before it got your supposed change to busy-wait.
You can run these tests in any game you want, they’ll always come back the same. Why do you think I’ve been pushing so hard to try and get SK’s limiter in RTSS? It does a better job, and all of PC gaming would be better off with it. Don’t care in the slightest whether it carries my name.
No idea WTF custom sync is. That wasn’t a D3D12 game, and Waitable SwapChains weren’t used. This is a completely fair fight, and RTSS is still chewing through 2x as much CPU and loading a single thread to 100%.
It’s poorly implemented, and the sooner we can agree on this, perhaps it can be improved.