Topic-Free Mega Thread - v 1.11.2020

One of the plans I have for when Kaldaien launches his own wiki website is to cover these sorts of things — common configurations to obtain various intended use cases.

There’s not a single one approach as it’s all based on the user’s desired end result, which is why PCGW doesn’t cover it at the moment.

Wasn’t there something about higher values for above 60 FPS too or some such, what the default of 2 and 3 respectively was though Kaldaien often seem to be using 5 or even 6 for back buffers which I’m not entirely sure how it corresponds to say 75, 90, 120, 144 or the full 240 or even 300 FPS range and modern displays if using VSync with or without hardware support (G or Free Sync, VRR.) plus the flip model presentation and flip discard which seem to be what really helps out with latency and responsiveness particularly in addition to DWM tearing and Windows 10 what is it Redstone 3+ or where this landed. :smiley:

I see Assassin’s Creed Valhalla is also deviating slightly from the recommended but then it’s D3D12 and without on-screen display support it’s hard to use the various tools and widgets to fully measure and compare results and using other overlay software could conflict. :slight_smile:

Something about the additional number of back buffers (Slightly?) increasing VRAM usage as well and however AMD and NVIDIA’s limiters and input responsiveness tweaks (hacks?) could help or interfere like capping or removing pre-rendered frames and what not.

EDIT: Makes it all sound a bit more complicated than it has to be I suppose, use the on-screen display maybe the full framerate widget and graphs and see how the framerate monitoring goes, somewhere like 33.3ms flat graph 30 FPS if that’s the cap and then 16.6 for 60 FPS again ideally a mostly flat graph and then I think it’s 8ms something at 120 FPS and then I’m kinda lost because I’m really bad at these calculations and how it works, 4ms something 240 FPS presumably so maybe around 6ms for 144-160Hz displays then.

Optimization can be a pain in the behind too Ultra options taking 30 up to 50% of the GPU or a combination of GPU and CPU resources for a minimal image quality difference even if the actual shader complexity and behind the scenes or game engine stuff is all nice and complex.

Bottlenecks and game engine hitches or limits also complicates stuff either limiting or hindering or outright preventing smoothness, CPU, GPU, RAM or any combination of factors and sometimes the engine just won’t co-operate nicely at all.

EDIT: Ask Kaldaien about Unity Engine.
Or probably others, part of that might be Super RGB and HDR and other swap chain or back buffer related problems or format issues too beyond more common or regular used stuff.

Sleepless Window Thread is less about preventing sleep and more about making sure Window Messages get dispatched as soon as they arrive. It won’t actually prevent sleep, it just uses a smarter form of it that wakes up whenever there’s input that needs to be processed.

My guess is that Final Fantasy is using a WM_TIMER to drive its framerate limiter, which is downright stupid because that only has 1 ms granularity. Throw in code that is sleeping the normal way on the window thread and those timer events don’t get processed at regular intervals unless SK steps in and fixes things.

2 Likes

Final Fantasy 4 on PC is a port of the DS version so a bit more than sticking the ROM file from mobile through what looks like a emulation software shell around it.
(Probably simplifying some of it but it’s in there.)

But it’s been updated a lot too over time and gradually smoothed out and fixed, quite a improvement actually not sure if it’s D3D or OpenGL though but that doesn’t affect some of these things I suppose just some of the extras that can further help if supported. :slight_smile:

Yeah, engine limitations or lack of specific optimizations in regards to hitches and stuttering are the major annoyance when attempting to obtain good overall frame pacing. SK goes a long way of being able to smooth out the pacing and work around other otherwise less-than-satisfactory decisions in regards to the swapchain etc of the game, but it can only go so far.

I often find myself lowering the graphical settings an additional step if I noticed that a certain graphics level causes additional annoying hitches every now and then that otherwise harms the frame pacing.

Imagine featuring a compendium on your SK wiki site that goes through and documents what each single parameter does :smiley:

Completely overkill, of course, but it would’ve been awesome to see explanations for all parameters, their intended use case, as well as potential benefits / negatives in enabling them.

Every time you call it a few milliseconds a part of me dies :frowning:

I understand how irrelevant it always sounds in the big scope of things and I also at a certain point will almost always prefer framepacing over ~1-5ms of latency decrease. But… if my grand silly scheme of trying to attempt using Special K as the savior of poor fighting game pc-ports, these things ultimately might matter in the end :stuck_out_tongue_winking_eye:

(with that being said, I finally get my AW2521H from NVIDIA next week, I’ll be able to actually do my own testing for once! (One of the 360hz reflex latency monitors)

I also convinced the Brawlhalla Devs after ~3 year battle to make a DX11 build of the game. The problem is that it probably will still not help support the game regardless as Kaldaien explicitly stated any game that uses GDI will be no-go no matter what for Special K. Makes me a bit sad considering how hard it was to convince the devs to swap from DX9 to DX11, however! the world is not that gloomy. Now that it’s DX11 the devs can actually properly program the correct flip models required to bypass DWM, so it wasn’t all for nothing.

P.S thank you to you and Kaldaien over the year with all the helpful info, I feel like I stepped into a secret world of hidden hieroglyphs that everyone is trying to decipher. Well… at least the people that know how to decipher, I just enjoy watching the show.

1 Like

That will be a huge undertaking considering how often I refine the design of these things, but thankfully some of SK’s features haven’t changed much over the years.

What I actually intend to do is use that text description in config.cpp to generate tooltips in a future version of SK’s command console using ImGui. Sort of like tab-completion, where you can cycle through all the config variables that match and see a description.

1 Like

1-5 ms of latency decrease is nothing compared to the 100+ ms removed elsewhere. It’s not even statistically significant :slight_smile: Just turning the limiter on in the first place is adequate usually, turning the additional lower latency stuff on will start to induce stutter.

Yup yup, agreed.

If you’re ever bored or manage to find the time - I wonder if there’s things you can debunk or learn from a person who does a lot of great work for lag in fighting games. He currently works with Ubisoft & Parsec specifically in the latency department (of course)

This site he made was specifically for fighting game devs to improve their code for their laggy fighting games, probably is the best primer on why most fighting game ports have excessive lag. Anywhere from 3-8 frames!

Game Engine lag explanation + how to improve it; https://inputlag.science/engine
How to test a game for “game engine lag”: https://inputlag.science/engine/methodology

Pretty sure it’s all stuff you already know though. But maybe there’s something cool to find there in combination with your LDAT arriving and more latency/framerate limiting stuff being the focus again.

I’ve read that before, actually. Very good information there.

This amuses me a little bit:

if the input appears between game update #0 and #1 , the reaction frame will start its display during Game Update #3 . Thus, this pipeline has a 2.5f average of lag (the additional 0.5f comes from the fact that the input can appear anywhere during #0 and #1 ).

You can tell he is an engine programmer, because he writes f after decimals. That is a precision indicator, it forces single-precision rather than double-precision and is faster. It’s weird to see that carry over outside of programming :slight_smile:

2 Likes

That’s why SK has that 120 frame window of frames it analyzes for stutter and 1000 frames for percentiles. I have no idea how RTSS’s statistics are calculated :-\

A lot of these hitches from high graphics settings are cyclical and can be seen happening regularly.

I think a 120 frame window might actually be too small for users targeting framerates > 60, since 120 frames is only 1 second at 120 FPS. But I wanted to keep the number of frames analyzed small enough that the analysis itself wasn’t contributing to problems and also small enough that the graph doesn’t appear to be vertical lines the way it does in RTSS.

Ubisoft’s performance graph suffers the same problem, just so it doesn’t look like I’m picking on RTSS :wink:

Something did just occur to me after re-reading your linked article.

How often does framerate dip below refresh rate in a fighting game? Special K’s limiter is currently designed to allow input latency to increase during framerate stutter events, and will bring the render queue back down to 0-1 frames when framerate normalizes.

That behavior is incredibly valuable in most games, but potentially terrible in racing / fighting games. But I think most of them are designed to run at a constant framerate anyway, so if framerate is fluctuating, there are bigger problems that need dealing with.

I think fighting games occupy their own unique niche when it comes to timing issues.

Normally, users who play with gamepads are more sensitive to frametime stability than they are input latency, because they’ve often got an analog stick pushed to its limit and motion / camera rotation is expected to happen at a constant velocity. Even the smallest of stuttering will be felt hard by a gamepad user and G-Sync doesn’t fix that, despite what everyone claims about G-Sync

Mouse users are sensitive to input latency, they don’t generally have constant velocity and have a pretty high tolerance for / inability to see stutter as a result.

Fighting games, I would imagine, are sensitive to both. It’s not a genre of game I ever play, so this stuff’s always going to be taking a backseat :frowning:

image

Second home on ResetEra now :slight_smile: I’ve found a forum to replace Steam, where civil conversation occurs. And am even recognized as an “industry insider.”

1 Like

Was thinking it might be Meta Council but that’s good to see hopefully it goes well. :slight_smile:
Steam could have worked for your own community section and the product forums but I assume there would be a lot of thread management and cleanup going by well I don’t know even Valve’s own sections on the Steam forums I suppose or anything really outside of perhaps some of the other community sections?

I read Metacouncil was a site without moderation, or something to that effect. And then quickly ran away wanting nothing to do with 4-chan lite :slight_smile:

It’s well a bit complicated I see it as a small community that in part formed after a lot of the older PC enthusiast got banned or left Reset Era in big part following the early days of the Epic Games Store discussion.

Durante for example for one name and while it’s more open it’s not Something Awful or the Chan network or what to compare to older more chaotic BBS anything goes boards.

EDIT: I do find Reset Era really useful for news and the still active insiders give a unique perspective in some topics too thus I frequently browse the forums though I also utilize Meta Council a lot more even if it’s a smaller community it’s really good.

Many of the former large or older boards and communities have slowly kinda gotten either really bad or dwindled or a combination of the two, NeoGaf and all it’s problems, Something Awful and it’s back and forth issues with the admin and some of the mods and then splits from these to smaller boards.

Suppose the overall negativity or hostility is a thing too that has grown Steam forums themselves as a good indicator but that’s been present for many years and the discussion and topics are not the best source of info as a result I mostly only ever use the news sections for patch notes and the topics on the Steam beta client and updates though there can be useful information too. :slight_smile:

From the AMD Reddit.

I wonder how many minutes it’s going to take for these to sell out.
3090’s and a couple of 3070’s are stocked in somewhat more than singular quantities now but the 3080’s and the entirety of the Ryzen 5000’s are just gone.

AMD really should have had the unboxing yesterday (As they did.) and then reviews today not tomorrow just as the product launches and then immediately disappears into resellers and their garage storage units and what not auctioned off for markup pricing due to incredible demand and limited supply.

Sounds like stock situations for the 6800’s and 6800XT’s aren’t the greatest either and then there’s third party designs following which might be even more limited finally the December launch for the 6900XT and how that’s going to go…probably going to go in a few minutes really. :stuck_out_tongue: