Oh, actually, to amend my previous essay, at the end I mentioned VR. At least on the NVIDIA front, this bug won't impact VR headsets at all. It would in some cases with older headsets, but newer ones that support VR Direct will completely bypass DWM, so they won't be affected. VR Direct is intended to bypass DWM and any issues with it, including the amount of lag that happens when the CPU is bogged down (though that may be limited to DX11 singlethreading). I don't think this thread's bug was the reason for VR Direct, but it is a workaround, at least for VR.

s-senpai has noticed me!

I've really just been dealing with this same issue like you have ever since I got my 144Hz monitor last September. It's been bugging me so much that I haven't been able to figure it out, but I researched into it a lot today and this is basically what I think the situation is, from a lot of reverse engineering and testing. Thankfully, I'm on 7 and my visual style actually has a non-Aero version that looks great, so that's what I've been using. I still want to get this solved though. There's almost nothing about it online.

It's an issue that crops up from a windowed application, a 144Hz monitor, a secondary monitor of any lower refresh rate, and DWM's forced double buffering + vsync (after researching, it's not triple buffering). When all of these cases are true, the issue crops up. Essentially, DWM has issues with 3D output at a higher refresh rate than the lowest refresh rate monitor on the system, because they're all being tied together. You don't notice the lag when the application isn't 3D.

From what I understand, what's happening is core to how DWM works, as a compositing window manager. Window contents are rendered as frames per-window. When DWM is in charge of vsync (aka not in exclusive, standard fullscreen mode), each time it wants to send a new frame to the monitor, it gathers every current frame from each window and composites them into a single image. With a 3D application, if a frame isn't complete, it ignores that frame and instead takes the last frame, giving the appearance of lag. The game still continues to render that frame and every frame in-between, so the measured framerate isn't affected, but those frames are discarded by DWM and so are never actually pushed to the display. The issue is, I believe DWM isn't pulling the last finished frame at the refresh interval of the monitor, but rather the last finished frame at the refresh interval of the lowest refresh rate monitor.

The solutions involve basically setting one of the previous cases to false. That means you can either disable Aero transparency or Aero entirely (and in turn, disable the double buffer + vsync), which isn't possible on Win8, or you can either remove any monitors that are less than 120Hz, or just run in fullscreen mode so that DWM has no control over what frames you send.

In essence, you can disable Aero transparency in 7, or lose multimonitor productivity by either removing the other monitors or running in fullscreen.

This bug is up to Microsoft to fix. They either have to fix the bug within DWM itself by using a true per-monitor refresh rate, on top of allowing incomplete frames for 3D applications (they should let those applications handle incomplete frames on their own), or make it so that applications can request exclusive refresh rate control for each monitor, so that DWM doesn't manage it on monitors with 3D applications running. This second method would be the best, because the graphics driver could handle this refresh rate timing for the application, in case an application doesn't support it. It would also mean that GSync displays can have the exclusive refresh rate control that they need while running games in a borderless windowed mode.

NVIDIA needs to contact Microsoft about this while they still have open communication regarding DX12. It's probably too late to fix this in Win8, but they can at least get it set up for Win10, especially if the DirectX team and NVIDIA want to push VR so much.

Not relevant when running in windowed mode, iirc? At that point, DWM is in charge of vsync. If that can be disabled please let me know. DWM has forced triple buffering and it's probably the root cause of this issue, not lowering the framerate but displaying less frames. In 7, disabling transparency would disable the GPU acceleration, which would disable triple buffering, but that's not an option in 8.

Windows is weird sometimes.

Can you try it on a 7 install to see if that would fix the issue, or is that not really an option?

Oh another thing that I've noticed when I was having this issue was that cl_showfps showed a frame rate far above 144, even when it looked more like 50 to my eyes. That's what told me it was something with how the window was being displayed that caused the issue.

I actually contacted NVIDIA about this to see if they knew anything but they weren't helpful at all.

won't do anything if running in a window

I'm not the nerd dragger this game needs, but I'm the nerd dragger this game deserves

Sorry I just had to say that. Sign me up to coach. I've also donated a server to Kevin because just having 4 servers isn't gunna work.

Isn't it worth testing, just to see if it works?

The thing is, I don't think it's TF2. I think it's actually DWM causing this issue, and I've experienced it myself. Some kind of bug with hardware acceleration. In 7, you can disable Aero and it'll fix the issue, but that isn't an option in 8.1 I guess...

Is Aero enabled and do you have multiple monitors, with at least one of them that isn't running at 144?

If so, try disabling Aero.

I casted a match with budsquad where they ran a full time combat medic

fucking steven

Willing to coach and donate a server for the night, if it would help you guys. You only have like 4 servers right?

Not sure why you got downvoted, you're blatantly right. There are a few instances where it really is a binary thing (Caber, Pomson), but in most cases, it's possible to detach solutions from the original problem, and it should always be done.

Rebalancing isn't done by just changing it to what sounds cool. Rebalancing is done by pointing out an unbiased problematic stat and coming up with a bunch of solutions to fix it, playtesting those, and then picking the best one. There are a lot of possible solutions to the BFB in this thread and I love almost every single one of them. Valve should reopen the Beta and make BFB1, BFB2, and BFB3 and see how they work out, similar to the Equalizer (Beta Equalizer 1&2, which both got accepted, becoming the Equalizer and Escape Plan).

just some points about a few weapons. everything is just technical, nothing here is opinion

does 150 damage to anyone "stunned". explosive knockback, natascha slow, and airblast count as being stunned. scouts can toss the cleaver and 1shot a medic who got airblasted or knocked into the air.

i believe the main issue here is that a soldier who spams can completely negate a kritz uber, since it makes those affected immune to crits. if it's a 5v6 situation, with 6 defending last and the 5 missing their medic, and they've built a Backup with spam damage, if the defending team has a kritz uber, the offensive team can just push in with the backup popped and the uber is negated, and with 30% resistance, they'll probably win the fight anyway unless their DM is shit. if it's a stock uber, the resistance is still really strong and they might win anyway.

competitive 6s tends to ban any weapons that, when used, force the other team to either run them or be at a disadvantage. this is why the vitasaw is banned.

the main argument against the caber is that it can be crit boosted

if the duration/intensity falloff was a bit more aggressive, i think this would be okay

generally banned in 6s because it can heal a med. if you couldn't drop it as often or could only drop it once, or if it didn't heal as much, i think it would be accepted more often