Topic-Free Mega Thread - v 1.11.2020

I don’t really know how many people can still use it but the new content is there so I’d say someone is using it. :rofl:

Pfft!!! What doofus at Remedy forgot to add HDR to Control?

Guess that settles it, I’m playing the D3D11 version with Special K adding HDR. Lazy developers :stuck_out_tongue:

It’s a weird choice for being such a otherwise high-profile title. No version of the game has HDR — not even the high-end consoles.

Oh well, I came prepared at least :slight_smile:

Give me another few months and I’ll be able to add HDR to D3D12 games… that makes me giggle a little, the notion of D3D12 games not shipping with HDR is such an absurd prospect. Of course, here we are.

1 Like

You can either use slew mode by pressing Y on your keyboard to place your plane anywhere you want, or press Insert for Drone mode, and fly around on the drone, but yeah youre gonna wanna look up the controls. There is def some Quality of Life needed to tidy the game up.

RIP, press L on your keyboard, turns your control panel lights on.

D3D12 support makes me happy. Nextgen is going to be using it a lot.

Incidentally, where does this rule-of-thumb about setting framerate -3 from nominal refresh to keep G-Sync engaged come from?

I’ve been doing some testing with my OLED in G-Sync mode (I usually run it w/ Black Frame Insertion instead), and it seems 1. NvAPI has no notion of G-Sync disabling when V-Sync rate is hit and 2. it only requires > 1 frame per-second slower than refresh rate to keep G-Sync in variable refresh mode.

I’m beginning to think that rule was found experimentally rather than analytically, and that the framerate limiter used to derive it was simply not very accurate.

-1 Would work, but framelimiters that aren’t yours are bad, especially 5 years ago, and if you capped too close, during FPS swings, it could go above the limit you set, hit the cap and enable vsync. The reason we don’t want that, is then input latency becomes really bad.

Man the server’s really chugging… :frowning:

Those don’t look like the numbers from a server that’s as weirdly unresponsive as this one is right now :frowning:

I might pack up the database and move this site over to Linnode where I host my blog and GitLab from, because there’s something seriously wrong with the server and it’s not reflected in any metrics Digital Ocean shows me.

IM makes me think of Instagram messages, and Apple iMessage XD

Global routing issues are causing reachability issues for this site.

The control panels had their lights on :slight_smile:

The lighting of the lamps inside the cockpit itself was controlled by a bunch of unlit knobs on the roof between the seats.

RIP, press Alt+L on your keyboard, turns your flashlight on. :sweat_smile:

I just had an interesting idea… what would you guys say to a mode where Special K creates a second window (D3D11) that can be moved to a different monitor that contains the control panel and floating widgets?

Initially it’d just be a cheap hack to deal with Vulkan / D3D12 games, but as time progresses (even after I finish Vk / D3D12 support) it could be handy to move the performance graphs off the primary screen and onto a different monitor. The specialized version of ImGui used in SKIF actually allows this kind of stuff.

3 Likes

I had a great reply that I lost back home, but basically the rule of thumb came to be after testing by BlurBusters and Battle(non)sense.

While 1-2 FPS worked on some monitor, others required a 2-3 FPS window to properly prevent V-Sync from engaging.

And so 3 FPS sorta became the rule of thumb.

Part of that is sure to be the frame limiter — this was before RTSS even has its modern low-variation limiter.

and it seems 1. NvAPI has no notion of G-Sync disabling when V-Sync rate is hit

I remember being annoyed by that back in 2017 when you first added the G-Sync indicator, lol. A shame they still don’t properly showcase that scenario.

“low variation” :wink:

Really wish I could talk to the guy, and give him my limiter and study his and then I’d have a really good series of blog entries to write.

Wasn’t there a discussion a month or two ago about NvAPI becoming a little more open?

I’d really like to write my own video capture software, because they all suck :stuck_out_tongue: Did they like (maybe) open up NVENC and NVFBC?

I need HDR video capture, and if you want something done right, you do it yourself. Or at least, you do, until the vidcap companies get off their ass and support HDR the right way :stuck_out_tongue:

Battle(non)sense doesn’t even acknowledge my existence :frowning: It’s sad.

They go on and on about how great RTSS is, but conveniently refuse to acknowledge I exist :wink:


BTW, can you point me to the source code for the “Tiny Injector” you wrote for SK? I imagine it uses CreateRemoteThread (...)?

Hopefully written in C or C++, but I can live with C# (yuck :P) if need be. I want to test injecting just SK’s framerate limiter and enough of its supporting services (i.e. config file, API detection and logs) to start fooling around with standalone limiters for testing.

“Might” be worth waiting for next gen cards, or at least Ampere’s keynote. Who knows, maybe Nvidia will announce HDR streaming as a new feature. I think it’s unlikely, but it’s not impossible.