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.

It has a maxframes addon which gives similar poor visual quality like Comanglia's and better FPS. Though I think it looks better than Comanglia's even with the maxframes addon.

Sorry, but what you just refuted was not at all what I said. You're skipping crucial information, one of the most important is that the driver will preemptively load the previous buffer because it doesn't know if your next draw is going to cover every pixel. I never said the driver knows where things will be rendered, I am saying because it doesn't know, it does this. Also, you seem to be confused where the clear takes place. You're clearing for the next frame, to prevent the driver from reading the buffer from the previous one. The write that clearing does is faster than reading the previous frame on the modern hardware.

Initialize a buffer? You can only clear present buffers. I think you're misunderstanding what buffer clearing does.

AFAIK, there is no Source cvar that makes it invalidate the buffer per frame (with some instruction like glInvalidateFramebuffer, don't know what the DirectX equivalent is).

Never said that. What I was saying is that GPU drivers will expect certain things with the information they have. And what you said is exactly why tiled renderers have to do this. The GPU won't know if you're going to be drawing on every pixel, nor what tiles you're going to cover. Now, I'm not a graphics driver programmer, so I'm not sure exactly about the inner workings of how/why they expect a certain different behavior on tiled rendering, but I know for a fact that the driver does act this way, and that's all I need to know for this config.

How is it worse than Comanglia's? It gets better FPS as shown in the maxframes benchmarks.

It is set to 0 for maximum frames, though I agree it makes things inconvenient. I'll try a lower value than in the main config, but something that will still allow for loading item panels. I've just found it decreases FPS when you're spectating someone.

EDIT: updated maxframes config with 0.00007, but didn't have time to test it.

Sure, but it will more optimal if it was system specific. However, I like your idea of using a default value for min heap size of 196, since that's still larger but not too large.

Sorry if my wording was confusing. I meant I wanted it to fade since it will be basically invisible at like 4000 or something, which reduces clutter. With 5000 to 5000, it will still be opaque at 4000, and disappear at 5000.

The driver will see if you call a clear on the color buffer for that frame, and if so, then it won't read what you last drew to the buffer again.

On modern hardware, clearing the color buffer is faster than the read. Sure, it would be most ideal to tell the driver to just invalidate the last buffer, but as far as I can tell, the Source Engine wasn't written for that.

Because in order to stitch tiles together efficiently, the GPU has to have a different understanding of the final scene for the next frame. It doesn't know if the draw this upcoming frame will draw on every pixel, so it preemptively reads from the last buffer.

I've tried to get into the habit of doing that. Sorry.

I agree that heapsize settings will be system specific so there won't really be a good default value. I'll comment the memory settings out and include better instructions on how to adjust the settings according to your available RAM.

The things it disables helps performance without affecting visuals too much. No one has reported the graphical issues you've claimed it causes, nor have I personally experienced them.

I used to have a hesitation to release it, but after several people asked me to post it to tftv, I did. Before, my logic was that I only wanted to release it when it was reasonably perfect, but now I've come to the conclusion that more publicity will get me better feedback, which will help me improve my config faster.

Sure, it is easier on rendering but I decided the rather insignificant extra rendering work that it has to do is worth it for reduced clutter by fading out to unnoticeable opacities faster. Perhaps for the max frames config, I'll set lod_TransitionDist to a value that avoids fading altogether.

I have explained it though. Non cleared buffers will be read by the driver per frame. gl_clear uses the standard clear method in the Source engine. If clearing is broken in Source, that's another problem that needs separate investigation.

Thanks, I appreciate your help in improving this config.

Do you mean exec gfx? I'll do that, but I have to make sure people don't forget to delete the autoexec.cfg in the mastercoms folder if they have their own autoexec.

A mistake. Fixed.