TF2 Classic: Backspace/Delete broken after alt-tabbing with "Continue Rendering" on

[Mykinius]

I recently started using Special K with Team Fortress 2 Classic in (non-borderless) windowed mode; it’s pretty great. I’ve hit a weird issue with alt-tabbing though:

• Without Special K, vanilla behavior when I alt-tab is that the game lowers itself to ~20fps, but the window I switch to (such as Firefox or Discord) renders at full speed. But with Special K active, when I alt-tab, those other windows get locked to TF2C’s 20ish fps and are very unresponsive.
• I experimented a little bit and found an option in the Special K overlay’s Control Panel: Window Management → Input/Output Behavior → Continue Rendering. This successfully made TF2C continue to render at full speed even when not the active foreground window, allowing me to use other windows I alt-tabbed to like Firefox/Discord just fine.
• HOWEVER, if I alt-tab with Continue Rendering on, a variety of buttons stop doing anything within TF2C’s text fields (like text chat or the server browser), including Backspace, Delete, Home, End, and the arrow keys. Letters, the Shift keys, and Enter still work.

Other troubleshooting notes:

• This doesn’t happen if I click another window to change my active window rather than alt-tabbing. Only alt-tabbing OUT of TF2C causes this, so if I click another window and then alt-tab back into TF2C, everything remains working.
• It only goes away if I restart the game. It is not fixed by clicking another window and then clicking back on TF2C, nor by turning Continue Rendering back off.
• The “broken” buttons DO still work in a few other places, like setting keybinds in the TF2C Options menu, or using keybinds for ingame actions.
• Checking “Treat Foreground as Active” next to “Continue Rendering” doesn’t change anything either.

I don’t mind turning Continue Rendering off if there’s another way I don’t know of to keep the game’s low background framerate from affecting my other active windows’ framerates.

Edit: Apparently hitting Alt in TF2C fixes this until I alt-tab out of it again. Very odd. Not a proper fix, but at least an easy workaround.

[Kaldaien]

Unfortunately this is very difficult to solve, because the game needs to be sent a fake key release event for Alt when you activate the Windows task switcher dialog by pressing Alt+Tab.

SK does send these events, but they won’t be received by all possible input APIs a game can use to poll keyboard state.

If I sent a proper event to release the Alt key, it would actually prevent you from activating the Windows task switcher altogether

---

You can probably get in the habit of pressing and releasing the Alt key after alt-tabbing back into a game. Typically the “Continue Rendering” feature is used by gamepad users, and they can block -all- keyboard input to avoid this problem.

For kb&m users, I don’t have a great solution

It’s possible you can use Windows+Tab instead of Alt+Tab, because it’s unlikely the game cares about the state of the Windows key (it might think Tab is stuck down, but that’s less of a problem than Alt).

[Gias]

i see kal explained the situation that can happen with input when using the continue rendering feature with some games

but you were using sk’s continue rendering feature here to avoid another issue that you were only running into with sk… and maybe you don’t need to use continue rendering for that.

some questions: what render api is the game using ? i believe this game uses d3d9ex by default. are you also using dxvk ? actually can you post a screenshot of your desktop showing the game’s window along with sk’s control panel menu open ?

[Mykinius]

Kaldaien: Understandable, thanks. As a curiosity, Win+Tab gets around the problem, but I think it’s slightly more annoying to use than just pressing alt when I refocus the game, which I was able to remember easily enough last night when playing.

Gias: Yes, I believe TF2 uses DirectX 9 (more details than that I do not know). When I first launched the game with the steam parameters “SKIF %COMMAND%”, I think there was a popup saying that the game supported native dxvk or something like that and I could use it, and I think I clicked Yes. That said, I don’t see anything about dxvk in the Special K Control Panel. Here’s a screenshot with some relevant dropdowns expanded:

[Gias]

hm that sounds like you added a dxvk d3d9.dll in the game’s folder at some point

i just installed the game and it is reporting d3d9ex on my end (also, i didn’t get the prompt to enable dxvk support…)

i also know that sk automatically gives that prompt about enabling native vulkan support if you launch a d3d9 game that is also using dxvk

the sk cp menu in your screenshot is also saying d3d11.4

normally when sk’s vulkan bridge option is enabled, you’d see “vulkan” in the sk cp menu. however, in some cases (mostly if you have a global injection delay or if something caused sk to inject/activate with some delay…) you won’t see the sk cp menu showing “vulkan” and, instead, you may see d3d11.4 (or d3d12).

a d3d9 game using dxvk is basically rendering with vulkan

and with the vulkan bridge feature, sk is enabling nvidia’s driver dxgi swapchain interop for vulkan (along with some extra driver flags to improve it). in that case, the game is using vulkan but for final presentation it’s using d3d11; and sk is hooking into the d3d11 part.

[Gias]

so i tested this more… and the cause it’s as i suspected: the windowed game with sk after enabling the vulkan bridge option is enabling vrr/gsync since the game has engaged independent flip presentation

(due to dxvk making the game use vulkan and the vulkan bridge feature switching to d3d11 for final presentation… as well as active MPO planes for the display – which allow for independent flip presentaion and vrr with a window that doesn’t cover the entire screen even while only having the fullscreen gsync option selected from the nvidia control panel)

without sk, the game is stuck on d3d9ex and on “composed: copy with gpu gdi” for presentation (since it doesn’t use flipex), and vrr/gsync does not engage with that type of presentation (unless you used the windowed gsync option from the nvidia cp… but i generally don’t recommend using that windowed gsync option from the nvidia cp since it can have some issues…)

vrr/gsync is what causes the fps to drop in other apps when the game is in the background or out of focus. that is because the game renders at about 17fps while it’s not focused and vrr is still active (active while using sk, whereas without sk the game doesn’t have vrr…) and so other apps get stuck with really low fps too because the compositor was told by the windows vrr setting (from windows’s graphics settings) to match its composition rate to the game’s presentation rate…

i imagine you have the windows vrr setting on.

basically one of the things that the windows vrr setting does, when it’s on and working, is keep the vrr locked to the game even when the game isn’t what’s on the foreground focused. this can be good in certain cases. for example: when you’re adjusting the windows volume.

both MPOs AND the windows vrr setting are needed if you want to keep vrr properly synced to the game when you got something on top of the game with activity (like the windows volume overlay with volume sliders that are moving as you adjust the volume, or gamebar/presentmon widgets with moving graphs). otherwise (if your windows vrr setting is off or not working for some reason), you’d either lose vrr completely or the synchronization with the game will have issues when you’re adjusting the windows volume or have something on top with graphs or certain type of activity…

anyway…

ways you could avoid having your other apps affected by the low fps of your game while its in the background or not focused (no need to use sk’s continue rendering feature here):

#1) you could disable gsync/vrr for the game or globally. i don’t recommend disabling gsync though unless your gsync is causing some sort of flickering in the game and you can’t fix that and you don’t like that.

#2) you could toggle off the windows vrr setting in windows’s graphics settings (while keeping gsync enabled in the nvidia control panel and for the game), but i don’t recommend toggling off this option… since having it on has its benefits and there’s another/better option to avoid the issue you were having while using sk (see the following option # 3)

#3) simply set a background fps limit in sk that’s less than half of your display’s max refresh rate (even if the game set the fps even lower. that’s fine). with such a background fps limit, sk also enables fractional vsync for the game while the game is not focused… and fractional vsync breaks vrr… which then means that the game will render at low fps when it’s not focused but it will not have vrr active then (so will not mess with your other apps). vrr would become active again when the game is focused and, if you kept the windows vrr setting on, you’d still even keep the vrr working properly (synced properly to the game) while adjusting the windows volume etc

here for example, i got a display with a maximum refresh of 239.97hz and i set a background fps limit of 119 (which is a bit less than half of my max 239.97hz) with sk -

you can see that has my gsync status on “supported + inactive” while i don’t have the game’s window focused, and sure enough my other apps aren’t suffering in this case despite the game rendering at about 17 fps there. if i removed the background fps limit from sk, then sk would stop applying fractional vsync while the game is out of focus and my vrr/gsync would still stay active at very low fps and affect my other apps (basically the issue you had).

in your screenshot i see that your maximum refresh rate is 144hz, so i’d suggest setting a background fps limit with sk that’s less than half of 144

tl;dr:

i believe your issue is caused basically by vrr/gsync staying engaged (at very low fps) while the game is out of focus.

to avoid your original issue… what i suggest is to simply set a background fps limit of 71 fps or less with sk’s background fps option

that’ll turn off your vrr/gsync while the game is out of focus because sk, in that case with such a background fps limit while the game is out of focus, would apply fractional vsync – which breaks vrr (and your vrr/gsync may be active again when the game is focused). you don’t need to use the continue rendering feature for this.

[Gias]

well another thing… i don’t know at what fps you’re playing this game

if you’re playing at fps above your display’s refresh rate with the game focused… then you’re not even playing with vrr/gsync active (and your vrr/gsync was then only becoming active, with sk, while your game was out focus… and causing the issue…)

in that case, if you don’t want to play with vrr/gsync, you could also force off gsync for this specific game with sk by right clicking on the gsync status indicator in the sk cp menu, unchecking the gsync box, and then restarting the game-

or just set a background fps limit with sk that’s less than half of your display’s max refresh rate (so, in your case, set a background fps limit of 71 fps or less…) as i suggested in my previous post

either of those should get you what you want without needing the continue rendering feature here…

[Mykinius]

Wow Gias, I didn’t have a chance to mess with this this weekend, thanks for these responses. You were correct: I had apparently added a d3d9.dll to C:\Program Files (x86)\Steam\steamapps\common\Source SDK Base 2013 Multiplayer\bin a year ago and completely forgotten about it. Similarly, you’re correct about me having the Windows VRR setting on, and I’m aware of the issues with the NVCP’s windowed gsync option, so that’s set to fullscreen only. Interesting about the Windows VRR setting not requiring the window to be active for that reason, and good to know.

I wonder why your SK CP shows Vulkan whereas mine shows DX11.

I will experiment with these different options to see which one feels the smoothest. The reason I started using Special K in the first place was actually because of issues where the game looked jittery despite very powerful hardware and a high on-paper framerate, even when trying to use NVCP or SK’s frame-limiting feature to set it to, say 139, or something more 100% achievable like 100. At the time of my original post, the least-stuttery option I’d found was just keeping v-sync off and bruteforcing smoothness with high raw framerate, but that wasn’t ideal because of the slightly noticeable tearing.

I’ll report back with my findings tonight or tomorrow probably.

[Mykinius]

Checking back in:

• Setting a background fps limit of 71 fixes the low-framerate-when-background issue, allowing me to forgo the slightly problematic Continue Rendering setting! Hooray!
• Disabling g-sync entirely without any framerate limits also works. This may be the most straightforward solution here.

Tangentially, some other odd behavior I’ve noticed is that the game feels stuttery when any fps limit is active in it, including basic v-sync. This is a bit of a shame, since I definitely notice the tearing artifacts from v-sync being off. The tearing is usually unnoticeable when the framerate seems to be greater than twice my refresh rate (2*144=288), which is the case probably 3/4 of the time. I do not seem to have this problem with other games like Deep Rock Galactic and Vermintide 2, where I employ framerate limits of 120-140 that make the game feel consistently smooth. Removing the DXVK d3d9.dll from the game’s directory results in an experience that has no tearing and seems to have so-so smoothness.

Here are the things I’ve tried to lock the framerate at or below the maximum 144hz to prevent tearing but unfortunately leading to perceived poor smoothness by me. I tried a variety of values like 120 (a nice round number below my monitor’s 144 max) and 137 (the recommended 99.5%-of-max for avoiding clipping over 144):

• NVCP’s per-game Max Frame Rate setting, set to 120 and 137. Both felt bad.
• NVCP’s per-game v-sync (with SK disabled, since it overrides it)
• ingame v-sync. No perceptible difference from the NVCP forced v-sync.
• ingame console: fps_max was 300 by default. Tried 120 and 137, which still felt stuttery. 300 was slightly better, but the game actually felt smoothest when under 300 (such as at 200). I’ve now left this at 0 so the feature is disabled.
• SKCP: Framerate Limit set to 120 or 137ish. No tangible difference between them; both feel bad. Changing framerate limit mode from “Low-Latency (VRR Optimized)” to “Normal” made no difference. Same with unchecking Drop Late Frames.
• SKCP: Framerate Limit off, “Enable Tearing” off. Feels the same as fps limit On.
• SKCP: Framerate Limit on, or Enable Tearing off, but with Reflex Mode set to Off instead of Low Latency. Might actually be a tiny improvement, but nowhere near unlimited framerate and v-sync off.

If it matters, I’m using the Alienware AW3821DW, which has a native g-sync module, rather than being a typical g-sync “compatible” monitor. This is just baffling. Maybe I’ve just been so used to keeping v-sync on for the last decade that I never realized that high fps will look smoother (barring tearing) even when the monitor can’t keep up. Is that true?

[Gias]

yep you could stop using the continue rendering feature for this game.

eh higher fps may look smoother, but i believe that’s more when fps is below the max refresh and ideally still with a good fps limiter so that there’s more consistent frame pacing, plus more consistently predictable input behavior. you won’t be fully seeing frames past your max refresh rate (you’d have tearing…) but you can stil get lower latency with fps above your display’s refresh rate.

higher fps doesn’t always result in lower latency though. gpu load is a factor. very high gpu load can result in higher latency, and capping fps with a good fps limiter in that case can actually result in lower latency. uncapped fps or vsync off is also likely to result in not only screen tearing, but also judder or stutter from inconsistent pacing and/or dropped frames.

with fast sync, for example, the penalty for a misaligned (dropped) frame at lower frame/refresh rates is normally more visually noticeable, and so without a good limiter, it’s recommended to use it with fps that’s 2-3x above the display’s max refresh rate (btw fast sync does not work with d3d12 games). not only does tearing (when using vsync off) become harder to see at high fps/hz (compared to, say, 60fps at 60hz) but also the game can recover from frametime spikes quicker due to QFT (quick frame transport – as the display refreshes faster with, well, higher/faster refresh / scanout)

also, there are games that have some logic tied to a specific fps/tick such as 50 (some unity games for example…) and in those cases the games tend to have judder or stutter unless you cap at 50 or multiples of 50 (like 100). i don’t know if this game you’re playing is like that though. i’ve not been playing it.

but yes playing at high enough fps could help in some cases… i believe there was also a game that had motion blur that apparently could essentially be removed by playing with fps above the display’s refresh rate.

generally i’d recommend trying a good fps limiter first and capping fps to your average or something you can more consistently maintain at least if using vrr/gsync (without vrr, you’d ideally cap fps 1:1 or at factors of the display’s max refresh rate such as 60 fps at 120hz) for more consistent framepacing and more consistent input behavior. uncapped fps would have variable latency, which can feel bad… capping fps at some multiple above your display’s max refresh rate could also work depending on how much fps you’re getting etc

something else you could try is using fast sync + sk’s normal fps limiter or fast sync + sk’s latent sync with fps at 1:1 (so 144 fps at your 144hz max refresh) or with fps at a factor of your max refresh rate. fast sync is a form of triple buffering that can help in some cases… and removes tearing. you could also try latent sync with input delay bias at 50% or higher (right click on sk’s framerate limiter area in the sk cp menu to get to the latent sync settings). increase the input delay bias percentage as high as you can without the mouse icon in the latent sync window going into the negative numbers. this depends on your hardware and the game basically, but increasing the input delay bias can reduce latency further. also, try with gsync unchecked for the game in the sk cp menu (and restart the game).

removing the dxvk d3d9.dll from the game’s directory results in an experience that has no tearing because the game is then using the old bitblt model with “composed: copy with gpu gdi” for presentation. it’s basically not possible to get tearing in that case due to the windows desktop manager preventing it.

is there are reason you’re playing with a small non-borderless window ? actually keep in mind that can also result in stutters especially with gsync active if you have other hardware accelerated content running on the same display where you have the game running even if the game is using independent flip for presentation. borderless fullscreen may perform better.

oh and i don’t think reflex low latency mode is working for you in that game. sk’s reflex low latency mode normally only works with opengl-ik, native d3d11, and d3d12. it won’t work with d3d9 or dxvk. your sk cp menu may say d3d11, but it’s because the game is using that for final presentation thanks to the dxgi swapchain interop layer from nvidia that sk enabled after you told it to. it’s still using vulkan first, and yeah normally sk will still say vulkan in the sk cp menu when the game is using vulkan (with only dxgi for final presentation); i imagine something caused your sk to not inject/activate quick enough… but, anyway, sk’s reflex “nothing but boost” normally still works.

[Gias]

i’ve also run into some unity games that got stutters when using sk’s fps limiter while having the in-game vsync on, so something to lookout for… at least i believe it’s rare that a game’s vsync setting causes a conflict with sk

but in such a case, we could turn off the game’s vsync and use sk’s vsync setting from sk’s display menu or presentation interval 1 from sk’s swapchain management section, but yeah, for frametime compensation… generally vsync should be used alongside gsync with fps capped enough below the display’s max refresh rate (to prevent the game from switching to traditional vsync and incurring a ton of latency…)

[Mykinius]

Out of desperation, I updated my nvidia driver from 537.58 to 551.86, and the issue is gone. Turning off “Enable Tearing” now correctly limits the framerate to a smooth-feeling tear-less 144, and alternatively, setting the framerate limit to 137 maintains that smooth feeling and tear prevention while shearing off 15+ ms of latency. I don’t yet have any idea why my previous driver would cause this issue, nor what I could have looked at that would reflect the stutter I saw when the 1% lows were basically the same as the average. I’ll look over the changelogs tomorrow and see if anything seems relevant.

(That hardware-accelerated gsync stutter tip may explain some stutter I see when simultaneously having a Discord stream open, so thanks for that lead. Also, I run games in non-borderless windows since I want to be able to multitask as if I had two monitors without dealing with (IMO) Windows’s poor multi-monitor behavior, and I got this 38" 3840x1600 monitor because it was wide enough to allow a 2560x1440 game window on 2/3 of the screen and a decently wide Discord or Firefox window on the remaining third. It was a tradeoff I made expecting occasional jank like this, but it’s overall been worth it. Shame I’m stuck with Windows 11 for that “Optimizations for windowed games” feature, though, but I’m keeping a close eye on Linux Wayland/driver news so I can switch once it gains parity for that feature.)

Gias, thanks so much for assisting with this problem. I really appreciate it and learned a lot along the way.

I can’t see a way to edit the thread title to reflect this, but I consider the problem solved.

[Gias]

ah. yeah drivers sometimes could cause issues too.

over time multi-monitor support has gotten better (i use 4 monitors usually), but there are still some issues yeah…

good news is there are more improvements coming; like what was mentioned in the windows insider blog here:

We have improved refresh rate logic to allow different refresh rates on different monitors, depending on the refresh rate for each monitor and content shown on the screen. This will help most with refresh rate-dependent multitasking, like playing a game and watching a video at the same time.

Announcing Windows 11 Insider Preview Build 25915

that hasn’t made it to the public/mainstream release for everyone yet… but maybe later this year.

anyway, glad things are working better for you now

[Gias]

oh and doesn’t really matter… but if you wanted to mark a thread/post as solved, i believe you should have the option by clicking the following for a post -

i guess the thread would also then automatically get a little icon with a tooltip saying this topic has a solution. like this one:

anyway, you don’t have to do that… but you can if you want i guess