They've been there since release. I just looked through the source code to find them.

I don't know why Chris claimed this because I can verify even without source code that nojoy does affect the game's behavior. TF2 outputs "Did not detect any valid joysticks" to stdout when nojoy is not present. Not sure about the mouse acceleration commands since I haven't used Windows in years. But from my memory, I remember them affecting mouse acceleration.

I would definitely recommend cl_SetupAllBones 0. Also any reason why you didn't use -nops2b?

After looking at the code again, I think setting any of the violence_ cvars to 0 enables low violence mode/silly gibs, but I'm pretty sure the code I'm looking at is outdated so I'll have to test in game. The best way to disable gibs is through the prop break max pieces commands, I believe. Not sure about blood, how was this done traditionally?

Found a few more launch options, though I haven't fully investigated them yet

-mat_softwaretl : forces software vertex processing, might be useful for bad GPUs
-limitvsconst : limits hardware vertex shader constants to 256, don't think this one will be too useful
-primarysound : uses a single sound buffer, not sure what the real impact of this is
-snoforceformat : skips force setting of sound buffer format, not sure what the real impact of this is
-reuse : allow network sockets to be reused when busy (sets SO_REUSEADDR), not sure about this one but i tested it earlier and i didn't have any bad results with it, maybe someone with a better feel for net settings can test this
-usetcp : allows usage of TCP, probably useless because I'm not sure where TCP would be used in TF2, I'll have to investigate further

Some more kinda useless ones:
-shadersondemand : initialize shaders on use, though it still seems to allocate memory for the shaders, so don't see any use case for this...
-random_invariant : use the same seed for local RNG every launch, don't see a use besides debugging
-small : allow resolutions smaller than 640x480
-filmgrain : may enable a film grain effect, crashed on my PC when I entered a game

So benchmarks soon then?

He's trying his best, and admits when he is unsure about things.

You know which launch option causes this? Most likely -nouserclip

Also are you still using dx8?

Eh, unlikely. Most likely placebo.

I've found some launch options that you peeps might want to test:

-nosrgb : disables SRGB (limits variety of colors) results in flatter/smoother colors, and brighter lighting
-nouserclip : disables user clip planes and enables fast clipping (I experienced a fps boost with this)
-nops2b : uses pixel shaders 2.0 instead of 2.0b, reduces fps impact of some shaders
-softparticlesdefaultoff : disable depth blending for particles and sprites

Please don't use these settings with my config. I already set these to optimal values in my main config and maxframes.cfg.

Main offenders: r_lod 2 (sets all models lod 2, even if they can go down to a lower lod, use r_rootlod 2 instead and set r_lod to -1), blink_duration 0 (doesn't do anything except divide by zero and possibly cause some errors/memory leaks), g_ragdoll_fadespeed 0 (this is the rate at which the ragdoll fades out, if it is 0 then it just takes up memory trying to do the impossible fade task per frame, though this might have been fixed in Tough Break), and I thought violence_hgibs 0 enabled low violence mode, which is worse for performance.

It is better to remove any extra configs you have for graphics and just suggest values to me. They might be ruining performance.

I know, but most ragdolls disabling configs get a value wrong and cause a memory leak (possibly fixed in Tough Break). I wanted to make sure what values they were using.

How did you remove gibs and ragdolls?

What is LOD tweak?

And I recommend using the highest dxlevel supported by your card. But it comes down to what the benchmarks say, and personal preference. There are some things in dx8 that hurt performance depending on your specs. It makes up for it by disabling some effects not supported by it, but I think most of the important effects can be disabled in dx9 anyway.

Hm, so I guess it comes down to benchmarking it with some perf tool.

Yeah, it was frustrating, but I'm glad it was sorted out. Sorry about that whole social drama thing in #111, I was just kind of frustrated from our conversation.

Anyway, the thing I was asking was the StackOverflow post's claim about fast clears, saying that glClear actually saves write and read time, on any GPU, not just Maxwell and Pascal.

Oh ok, sorry. I see. You're right then. I'd like to thank you for walking me through it. I was missing the deferred vs immediate mode bit and why it would matter.

Could you explain this too? https://stackoverflow.com/questions/37335281/is-glcleargl-color-buffer-bit-preferred-before-a-whole-frame-buffer-overwritte/37336947#37336947

Excuse you, I have a Hale's Own Text Editor and I'm proud!

Setsul, this isn't going to be worth my time if you aren't willing to understand what I say, nor if you are going to discuss these things in a non-pretentious manner. But, that's not what I meant. Here's the source I meant: http://www.seas.upenn.edu/~pcozzi/OpenGLInsights/OpenGLInsights-TileBasedArchitectures.pdf (23.3 on page 5 or 326 and 23.4 on the next page)

I've tried to remain as friendly as possible but Setsul's behavior and discussion habits makes it quite hard.

Thanks! I'm not a guy though :(

I've been saying the same thing over and over, just in different ways so you could understand.

Drivers skip reading all buffers if you use glClear. And it might take a bit to find the link, I'm trying to figure what keywords to use. It might also be on ASM or IEEE so I'll have to look there too if I don't find it from googling it.

I believe it is in materials\sprites\crosshairs.vtf in the textures vpk.

Stencil and depth buffer don't need to be dealt with for the driver to understand that it can skip reading buffer.
It is faster and does this only on tiled renderers because the write is faster on GPUs with tiled rendering.

I'm trying to find the link, but you are obviously misunderstanding what I'm saying.

Let me give you a simple example before I find the link. Let's say you are rendering a simple UI. That UI has a few buttons, and something just triggered a hover effect on one of the buttons. So you would update that part of the UI. The GPU has to read the previous buffer to draw the rest of the UI that you didn't update.

But lets say your draw is covering every pixel. The GPU doesn't know that this draw will cover every pixel, so it will still read the previous buffer, assuming that you won't update every pixel and expect what you drew last to stay there. If you call glClear, the GPU knows that it won't have to read the previous buffer because you've cleared the color buffer. This writing to the color buffer will be faster than the read.