I'm assuming you want to compare yours and mastercoms, if not I apologize.

I'm not sure if you were expecting something more significant than simply lower framerate (based on your CSGO graph), but that's all I see.

comanglia hq v mastercomfig
https://i.imgur.com/8DTWfMH.png
(sorry the graph lines aren't very defined, the graphs are just from here. I don't yet know how to plot graphs myself. This is literally the 1st time I've tried this.)

I ran each config 3 times with benchmark1.dem and graphed the 3rd run of each. I did not do any of the OpenGL shader/native libraries stuff from mastercomfig, only the autoexec.cfg.

I appreciate the effort you put in but I think the underlined settings are different than what mastercomfig has.

Basically the graph I linked shows the time between each frame granted the graph I showed isn't a great comparison but basically by doing it this way with a graph of how long it took between each frame you can find the Average, and Minimum FPS, as well as see which one has a more consistent framerate (which in practice would be a lot smoother if it was more consistent even if it has a lower average and minimum framerate by a small margin)

Question why is cl_hud_minmode on by default?

If I'm not mistaken, i think min mode saves a bit of frames, I'm no expert though.

I guess for default hud but most huds don't have minmode which breaks stuff

Possibly something to do with conflicting HDR settings. I haven't had that issue, so if you could log your console with con_logfile console.log and then run cvarlist, I can check your CVar values to see where the problem is.

Because disabling trilinear reduces the stuff the material system has to do for textures.

A mistake. It should be commented. Sorry about that.

I'd like to point out that the whole point of the extensive commenting was so people could understand the values and choose the best value for their needs.

I'll post a max frames config soon for benchmarks.

You are correct. Those seem to just be autoconfig/stale settings as I misspelt mastercomfig as masterconfig when executing it. Sorry for my carelessness.

These should be the correct settings.

https://i.imgur.com/MlEAnUQ.png

I don't think I'll get anything as significant as your CS:GO graph, as they seem to be graphing the effect of powersaving modes.

You're on Linux, right? gl_mtglflush_at_tof should be set to 0.

Added a new max frames preset addon config. Would really appreciate it if it was benchmarked!

(still don't have a lot of mat_ CVars, but this should give a lot better FPS)

Oh, another config with random cvars.

Server cvars.
Host thread mode is broken and you know it. Why would you put it in an fps config?
I don't care if you've read the source code if you ignore even the most basic documentation. TF2 itself will tell you

It's utterly useless to change it since it will never affect the TF2 client, ever.
anim_3wayblend isn't the gold standard for uselessness, it's like triple platinum certified useless. It's been broken since before it was (accidentally) released. https://developer.valvesoftware.com/wiki/VCD_Blocking_Tool

So you really want to make sure bloom is disabled?
Then what the fuck are these settings supposed to do?

How important is it to set bloom tint when you've tried so hard to make sure that bloom is definitely disabled entirely?

Uhm what? This simply enables the command buildcubemaps. It's most definitely not meant as a way to disable bloom.

cl_ragdoll_forcefade 1 fades ragdolls instantly, what are you trying to accomplish with non-zero fade_time and sleepaftertime?

So on one hand you want high model quality on the other hand you want it to switch to lower LOD quality at a negative distance?

How would that even work? Apart from the fact that only one chip in the 700 series is actually Maxwell.

I could go on but I'm tired.

i feel like this config will break my tf2 after skimming that setsul post

isn't the intent of this config to have all of them in one place in case you want to change it? it should be commented out since it's useless here, but getting mad at it for existing at all is silly

The ai and some other server replicated commands were put in because I wanted to accommodate some singleplayer Source engine experiences for myself. My bad for keeping them, but I didn't see the problem in keeping them since there isn't any harm in doing so.

Not sure why you think it is useless just because that choreography tool isn't released to the public. anim_3wayblend is still used in the Source Engine for calculating bone poses, not just in the VCD Blocking Tool. Anyway, although it is server replicated, it has the same reason as the other commands in that I've kept it in there for singleplayer Source Engine use.

Because it isn't broken, except in local servers, and that's because of an oversight with input and networking logic differences for client and servers. Using threaded mode better runs what the engine is tasked to do per frame.

I read the documentation, but documentation can be inaccurate. For systems with 512MB of RAM, the Source Engine uses mem_max_heapsize_dedicated instead of mem_max_heapsize.

I'm sorry if traditionally TF2 configs weren't like this, but mine is made out of editable text. I've also included any values people may find helpful for them to adjust. Instead of others spending the time to find how to customize a specific option, I've included it in my config for them. Anyway, since bloom is by default disabled in the config, you should know that having those CVars there don't actually affect anything.

It keeps track of if you're currently building cubemap samples. Some rendering features are disabled by this command because the game thinks you're building cubemaps. Source code can reveal some wacky stuff.

Nothing by default. As you said, they do nothing if cl_ragdoll_forcefade is enabled. So it's not a problem for them to be there.

Model LOD and LOD fade controlled by lod_TransitionDist are completely different things. lod_TransitionDist controls the fade distance for the func_lod brush entity, which is an emulation of LOD by literally fading models out of view, rather than fading down to a lower quality. r_rootlod 1 was chosen because people who are looking for max performance will find it, while more casual users will not feel comfortable changing options. I looked for feedback from users about model quality, and I found that r_rootlod 1 was the average preference. Anyway, you seem more confused about the -5000 value and rightfully so. lod_TransitionDist is not the actual final fade distance value. There is a min fade distance of 5000 (where closer than this the object is not faded at all) and lod_TransitionDist is added onto that to get the max fade distance (where at or further away the object is fully faded). By setting it to -5000, you get a min fade distance of 5000 and a max fade distance of 0. Thankfully, the Source engine swaps the min and max values if the min value is greater than the max. So with this, you get an object fade from 0 distance to 5000 distance, rather than from 5000 distance to at least 5000 distance.

Drivers for tile based rendered graphics cards will do reads on framebuffers unless you specifically clear them, because the driver will assume you'll need it in a rendering step later since you didn't explicitly clear the buffer. My mistake for saying 700 series, I'll correct the comment there.

Thank you for your work on reviewing my config! I'm happy to see more discussions come of this.

I'm sure you won't have to worry about that.

i saw the title and was excited for this but after reading this thread i dont want to fuck up my tf2 for like a 3 frame decrease in performance

I've made a new preset for the config for max frames, while all benchmarks so far use my default config which does not squeeze out every last frame.

Please check back soon for benchmarks for my max frames preset!

So on one hand you left in settings for a better single player experience, on the other hand you left in a setting that completely breaks single player. That seems a bit inconsistent, doesn't it?

Apparently you read the code, but only 2 or 3 lines and then skipped the next 10 which are kind of important. This will become a recurring theme.

// take one quarter the physical memory
		if ( host_parms.memsize <= 512*1024*1024)
		{
			host_parms.memsize >>= 2;
			// Apply cap of 64MB for 512MB systems
			// this keeps the code the same as HL2 gold
			// but allows us to use more memory on 1GB+ systems
			if (host_parms.memsize > MAXIMUM_DEDICATED_MEMORY)
			{
				host_parms.memsize = MAXIMUM_DEDICATED_MEMORY;
			}
		}
		else
		{
			// just take one quarter, no cap
			host_parms.memsize >>= 2;
		}

		// At least MINIMUM_WIN_MEMORY mb, even if we have to swap a lot.
		if (host_parms.memsize < MINIMUM_WIN_MEMORY)
		{
			host_parms.memsize = MINIMUM_WIN_MEMORY;
		}

		// Apply cap
		if (host_parms.memsize > MAXIMUM_WIN_MEMORY)
		{
			host_parms.memsize = MAXIMUM_WIN_MEMORY;
}

I'm going to help you with the math. 512MB >> 2 equal 128MB. So not only is 196MB a weird value, it will always be ignored, since it can never be less than a quarter of host_parms.memsize, if that is <512MB.
It will then be overwritten by mem_min_heapsize anyway. Both the default (144) and your setting (512) are larger than 128MB so dedicated will never be used. Also you're forcing 512MB heapsize on systems with <512MB RAM. Off to the pagefiles we go. Think of the poor TLB. Look at this.

http://i.imgur.com/nIH2Glx.png

Does he not suffer enough? Why do you have to do this to him? Think of his family!
In all seriousness though, min_heapsize is set to 144 for a reason, leave it be. On systems with more than 576MB RAM it'll be set higher automatically anyway. If you insist increase max_heapsize. You can put that at 4GB if you want, since that would only be used with 16GB RAM available. It'll probably fuck with the TLB so much though that it ends up being slower.

Why do you think building_cubemaps 1 is the only way to disable these things? If you want to disable bloom do it via the settings that are meant for this. building_cubemaps 1 can break things horribly, e.g. epilepsy inducing flickering because the low pass filter is turned off.

So you document bloom settings and set them to something reasonable but you don't document the ragdoll settings and set them to completely random values that will result in garbage tier ragdolls with forcefade 0? Again, this seems rather inconsistent. If you don't want anyone to use those settings leave them out of the cfg. If you want them to be usable either set them to sane values for forcefade 0 or set them to non-conflicting values (read: 0) and provide a set of sane values in the comments. The way you're doing it it's annoying for those who do know what these settings do and useless for those who don't.

Again, you want high model detail, but you want other things to disappear completely? Inconsistent.
Also it won't work. I don't know how you do this, but you always ignore very relevant lines that come immediately after things that you appear to have read.

if( flMinDist > flMaxDist )
	{
		V_swap( flMinDist, flMaxDist );
	}

	// If a negative value is provided for the min fade distance, then base it off the max.
	if( flMinDist < 0 )
	{
		flMinDist = flMaxDist - 400;
		if( flMinDist < 0 )
		{
			flMinDist = 0;
		}
}

So yes, it'll swap because positive number > negative number, but your negative value will then be ignored and actually lead to a higher min distance than 0. Good job.

I haven't looked this up but since before DirectX existed user accessible glclear vars have been used to set the colour buffer to a solid bright colour, to find holes in the map. I know that it only sets the colour clear flag in source, so I have no reason to believe it'll to anything weird beyond that. Stencil and depth buffer are unaffected.
Now how does having to write the whole colour buffer before rendering help?

#74
Because it's incredibly inconsistent.
He documents bloom with a level of detail that is so incredibly redundant (that they're the rgb values for bloom and between 0 to 1 could've been put on a single line instead of spreading it across 4), even though basically no one will use bloom, but then sets ragdolls to random values and doesn't comment them because "they don't matter anyway".
It just doesn't make sense.

maxframes addon got me more frames than comanglia. I ll be sticking with it for a while

i think its about time for setsul to make the ultimate fps cfg

Are gibs meant to be enabled? I have sillygibs in maxframes and regular gibs on your main config. I did a run with the nogibs section taken from comanglia's anyway.

No, because at best that'll end with octochris levels of autism, testing every single setting in isolation and at worst it'll end with me testing every possible combination on every architecture available only to realize 10 years later that the pyro update finally hit and made all the testing done before that point useless.
I don't have time for either.
I simply accepted that TF2 will never run smoothly, got an i7-4790K for VT-d anyway, overclocked it and filed TF2 fps configs away as SEP/PAL.

I do however like to call out people on their bullshit.
Also this week I'm getting triggered by inconsistencies.

I've just tested the new one out and here are the results:

Mastercomfig max fps:

Comanglia for hq PCs:

btw why are silly gibs enabled in the max frames version?
Edit: this was fixed

Nope, because people can change values. Though, I could do a better job of helping people find that host_thread_mode needs to be set to 0.

I know what bitshifting is. My point with my previous response was to tell you that it is indeed used by the TF2 client, contrary to what you had said. Anyway, you're right about the code logic. I just didn't pay much attention to it because it was such a fringe case anyway (512MB of system RAM). Sorry.

I wanted to ensure heapsize started bigger because audio cache takes up a quarter of memory. When using the async sound system, I needed to ensure that the heapsize was big enough to keep enough of the sound cache to prevent stuttering in most cases.

I don't. But it disables some things that can't be disabled normally. I haven't seen that problem.

I agree that the documentation needs to be better. But the documentation is a work in progress. I agree for consistency that the values should be different.

Because model detail is much more noticeable than some map objects that fade out of view sooner. You need to look at how that function is used. flMinDist is not going to be negative, because as I explained before, flMinDist will be 5000 + -5000, and flMaxDist will be 5000.

It clears the color buffer. I think you're thinking of gl_clear_randomcolor, which clears the buffer to a random color. Admittedly, I don't have a GPU that supports tiled rendering (stuck with a GTX660 for now :( ) so I can't test the effects of gl_clear. I should label it as an experimental CVar, then.

A mistake. Fixed.

You can edit posts, no need to doublepost after 3 minutes.

You're still forcing 512MB heapsize, no matter what. That's terrible with <=512MB RAM. Higher max heapsize and slightly higher min heapsize will stutter less than hammering the pagefile. If you want 196 (still weird, why not 192?) for <512MB then just set min heapsize to 192, because that's what it does. That's why it's named mem_min_heapsize. If you want more than 256MB to be available with >1GB then set higher mem_max_heapsize. It's not that complex.

It disabled things that shouldn't be disabled normally. That's why they can't be disabled via other methods.

You've had a year to document it. Why did you choose to randomly release it now if you weren't even close to being done?

So that's what you're trying to do. I thought the 5000 changed in 2013. Anyway now look at the code again.

float flFalloffFactor = 255.0f / (flMaxDist - flMinDist);
int nAlpha = flFalloffFactor * (flMaxDist - flCurrentDistanceSq);
return clamp( nAlpha, 0, 255 );

0 -> max and min the same avoids all alpha shenanigans. Rendering everything that you will have to render anyway fully opaque makes things easier.

gl_clear clears to the same colour every frame, randomcolor randomizes. You haven't explained explained why it would help at all and you haven't tested it at all. This isn't even an educated guess.

Maybe I'll list the rest of what's wrong in a few days.

It would really help if you could rename the config file to gfx and make an autoexec cfg with just "exec gfx" inside since many people execute multiple cfgs so those people would just have to copy and paste "gfx" then add "exec gfx" to their autoexec and people who have no idea how to install a config would just copy and paste the "mastercoms" folder as it is.

Even with a low resolution, it's very hard to get a stable framerate with that processor. Trying to get through a whole season with it was like hell. I wouldn't even bother upgrading that system, I'd suggest getting a whole new one all together.

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.

It doesn't have to be system specific.
It's easy. You want higher minimum heapsize you set higher min_heapsize.
You want higher maximum heapsize you set higher max_heapsize.
You wanted 196MB for <=512MB so set that as min.
>800MB you'll automatically have more.
If you want to allow more than 256MB max simply set the max higher.
There's no way async audio takes up 300MB so that you have to force 512MB heapsize. And if it did then why would you have it enabled while still trying to get the config to run with <512MB RAM and 196MB heapsize?

No, it won't fade any faster. With -5000 it fades, still being rendered until 5000 except with alpha involved, with 0 it'll be fully opaque and just disappear at 5000.

You didn't explain anything.
You didn't explain why otherwise the colour buffer would be read and why it would not be read when set to a solid colour.
You didn't explain how writing to the colour buffer instead of reading from it would speed things up.
You didn't explain why that would happen on TBIMR like Maxwell/Pascal but not on standard IMR.
glclear is most definitely not broken, glclear has always cleared the colour buffer to gl_color_clear_value.