How to reduce/fix stuttering and performance!

Black Mesa Archive In-game Issues (Mod)
#1

Hello all,

I hope it’s ok to post this hehe :wink:
Some people are not able to play BMS without stuttering?
I was one of them haha. I do have a reasonable graphics card (2011)
but my system is kinda outdated (2006-2007) so have had stuttering problems which bothered me.
Some people might have the same problem so im here to post a
solution that might help reducing or fixing the stuttering completly (in my case almost completly).

In your BMS folder (in my case
C:\ProgramFiles\Steam\steamapps\sourcemods\BMS)
there is a map called “cfg” and in that map is a file.
The file is called “autoexec.cfg” which u can open with Windows notepad or Word.
In there i’ve made a few changes fixing most stuttering :slight_smile: .
When opening with notepad type the following commands, it should look like this:

exec config.cfg
//exec threading.cfg

cl_forcepreload 1
ai_expression_optimization 1
cl_detaildist 700
cl_detailfade 800
lod_TransitionDist 600
r_lod 0
cl_ragdoll_collide 1
cl_smooth 0
snd_mixahead 0.2

note: the “mem_max_heapsize” should be like 1/3 of your ram, i got 2GB so for me its like:
mem_max_heapsize 787288

when u have a multi-core processor this can help, otherwise do not use:
snd_mix_async 1

This option seem to give some people problems but it’s supposed to increase performance:
r_fastzreject 1

For more commands and more explanation of the commands and cfg. files
see source.
Source: https://www.tweakguides.com/HL2_7.html

There are some more tweaks which i used but these need to be inserted in Steam into the Black Mesa “game launch options” (right click game in libary and choose properties, as explained in the link above):
-heapsize 787288 -dxlevel 90 (the dxlevel is for Windows XP users)

Of course this won’t work for everyone but it worked for me.
If it doesn’t work or its making it worse then just edit again in notepad
and delete the commands.

I hope this will help some people out, Be free to post feedback here.
This mod is so great! Thanks again to the devs! They made this possible!
So far the mod has been AWESOME!
ps. chapter 4 reached so far

#2

Thank’s a lot! I’ll try this later.

#3

[COLOR=‘PaleGreen’]This should probably be moved to this forum.

#4

Cockroach, I just did your tweak and am going to see if it helps. Will get back to you on the results. I appreciate all help. But tell me, if I do the multi core processor I am assuming that I put the command in the same notepad as with the above commands.

Ok dude, so far so good! Got through the tram without stuttering and looks like things are smoothing out. So much better than it was. Thank you for your help here. Will keep you posted as to how this fix is going! No stutter yet! :slight_smile:

[COLOR=‘Red’]Mod note: Removed two posts needlessly quoting the entire OP, and merged double posts.

Cheers!

-Max

#5

There’s no general rule for engine max heap size to be 1/3 of the ram available on the system. First of all, BMS uses Source SDK 2007 as the engine and it’s 32bit. Yeah, hl2.exe for it had been linked with “large address aware” linker flag so it could allocate more than 2GB of RAM for its needs but going anywhere higher than 3GB could cause troubles with the engine crashing on malloc() call. Thus people with 64bit systems and 16Gb RAM shouldn’t blindly use 16/3~=5GB here as it would only cause troubles. General rule of thumb for max heap size is to use maximum possible amount but not more than 3GB. To get the value of the “maximum possible amount” for your system close all the programs running in the background (including web-browser with dozens of tabs open and apps hiding in your system tray), open up Task Manager by pressing CTRL+SHIFT+ESC and take a look onto Performance -> Physical Memory. There would be an “Available/Allocatable” and “Free” values there. It’s safe to use most of the “Available” pool as long as you leave about 512-1Gb of free memory for filesystem caching needs. Typical safe max heap size value for the system with 2Gb of RAM would be as low as ~512MB, for 4GB it’s OK to have it around 2GB and for systems with more memory 3GB would be the right choice.

This one enables and extra depth-only rendering pass before doing actual rendering. It could conserve GPU fillrate a bit in case your GPU supports so-called “early z-test” (most nowdays GPUs are) but it could also cause slight slowdown in fillrate-constrained situations caused by alpha-blended effects like smoke clouds. I.e. it would help to get a bit more performace when there are not so many transparent objects on the scene but would cause small slowdown when most costly to render objects on the scene are semi-transparent. Use with care, do some benchmarks.

Specifying heapsize here has the same effect as using max_heap_size cvar, there’s no need of extra duplication. Either specify it here (which is considered to be deprecated for the Source engine and had been removed in 2009 version used for Portal II) or use the cvar.

Concerning dxlevel - I had been posting this on steam forums and keep posting it on BMS forums: never ever leave “-dxlevel” switch in the command line parameters of the source engine for a permanent use. IT IS THE ONE-TIME-USE STICKY SWITCH. It tells the engine to switch into using different render path utilizing features offered by the given version of the Direct3D API and causes most of the render-related cvars and output resolution to be reset to defaults. This switch by no means is limited to WinXP - it works just the same on Vista, Seven, 8 and even under Linux/Wine. Before using this switch one should check if he or she needs to use it by going into in-game advanced gfx settings dialog and looking at the “Software DirectX version” field. BMS requires dxlevel to be 90+. Source engine as of version 2009 recognizes the following dxlevels: 80, 81, 90, 95, 98. 80/81 selects now-deprecated DirectX8 D3D api with SM1.0. BMS wouldn’t work properly with this dxlevel. 90 selects DirectX 9 D3D with SM 2.0, 95 selects SM 3.0 and 98 selects DirectX 10-capable hardware access through DirectX 9 API a.k.a. SM 4.0. More details here:
https://developer.valvesoftware.com/wiki/Command_Line_Options
https://developer.valvesoftware.com/wiki/Mat_dxlevel

Once again: do not leave “-dxlevel” sitting around in your commandline parameters. Use it once if you need it and then remove it as soon as you confirmed that the engine had switched into using proper dxlevel.

#6

worked for me!
GTX 560ti
quad core
8gb ram

smooth like butter now

#7

Hey glad it helped for some of u guys,
and lexa thanks for the information, very useful :slight_smile:
I have been experimenting with some tweaks and if that helps ill post them.

#8

I really really hope you’re aware that r_lod 0 will actually decrease performance, since that actually disables the entire model LOD system, while r_lod -1 is the default (lod enabled). Positive values for r_lod will pick an LOD that is <r_lod value> higher than the default (aka will decrease model polys and lower fidelity, but increase speed).

#9

When using Crossfire the game would stutter and micro-stutter like mad. When I disabled it it was much much smoother. There is the occasional jerk/stutter (both visual and audio), for example when getting to a new area or sometimes when firing a weapon. But mostly it’s very smooth now.

I seem to recall that same occasional stuttering in HL2 in the beginning. But then they fixed it.

By the way, I have a Radeon HD 5970.

#10

I tried this and it seems to help slightly.

About the r_lod 0, I saw no difference either way.

#11

I did this… caused me to lag out super bad so I reverted the changes but the lag persists

#12

next time read the whole thread not just the first post before applying a “fix”

#13

Possible to implement this to the official release?

Founded in 2004, Leakfree.org became one of the first online communities dedicated to Valve’s Source engine development. It is more famously known for the formation of Black Mesa: Source under the 'Leakfree Modification Team' handle in September 2004.