+1 to frame rate issues. This fix helped a ton, but I still notice low framerates in the ‘icy’ areas (I’m about an hour into the game, at the most), and elsewhere. Especially when the bridge collapses after the puppy-alien-fellow-thing sent out his super-duper-sonar-attack. My frame rate sunk at that point, probably around 10 fps or less.
i7 quad core @ 2.3 GHz
Nvidia Geforce GTX 660m
I’ll have to try this.
So strange… I have nvidia gpu and quad core system and I’m not experiencing this. I will keep this in mind, though.
I have this issue alot, Zambezi @ 5Ghz and a 6870, I’ll try the suggested fix.
I’m not sure if it helps anyone, but I experienced huge framerate drops myself and what I changed seemed to work, but if someone wants to try the same, read below and try at your own risk.
I’m currently running 2 hard-drives in my system, my main one is a 128 GB SSD (Solid State Drive), the other is a Western Digital Green Drive (which only runs at 5400 RPM same as a lot of laptop hard-drives). All my steam apps are installed on the second hard-drive since it has more space. I haven’t had any issues with games in the past such as Portal 2 running on the 5400 RPM, but this one seemed to be running fine until I either interacted with a new resource on the screen or came into a frame where physics objects (barrels), etc were. When turning CL_SHOWFPS 1 on in console, it spiked to red FPS (8-10) when I would move my mouse and walk forward really quick into a new room and same if I did a 360 turn then it would act normal when everything was in view.
Long story short, I ended up moving my D-DRIVE\Steam\steamapps\sourcemods\BMS folder to my SSD at something like C-DRIVE\BMS (stopping/closing steam first obviously)
After doing this, I created a Symbolic link from my D Drive (Wester Digital Green Drive) to my SSD so that I could keep my current steam configuration and try hosting the resources on a more responsive hard-drive. This seemed to work very well, it loads a lot quicker this way anyways and I haven’t experienced the glitches at all anymore and I run on full settings.
Here’s a link talking about NTFS symbolic links: https://en.wikipedia.org/wiki/NTFS_symbolic_link
I ran a command like this:
mklink /D D:\Steam\steamapps\sourcemods\BMS C:\BMSIf you don’t know what a symbolic link is, you need to pretty much have Vista or Windows 7 for this to work. The above command creates a special type of shortcut that allows the one drive to point to the space on another drive (or even just the same drive). As long as they are both NTFS partitions, it should work fine. Steam loads it super well. It’s a handy trick to make games load faster as you’re playing them, then you can jump into command line (cmd) and run a RMDIR command on the D-DRIVE\Steam\steamapps\sourcemods\BMS command and move the C-DRIVE\BMS folder back there.
It’s almost like a tunnel to the information. So, if I click on the “shortcut” in the D-DRIVE\Steam\steamapps\sourcemods folder entitled “BMS” the filesystem thinks that the files in this directory are still on the D-Drive, so it keeps that path when you click on it, but they are really on the C-DRIVE\ in this case.
Does that help anyone? I would venture to guess if someone is running on a slow hard-drive they could be experiencing similar problems which isn’t necessarily Memory/CPU/GPU issues if it’s reading from ~7 GB of information for resources.
-Jonny
I noticed hl2.exe runs at below normal priority. It should be normal or above normal. It also runs with UAC virtualization.
This nearly double my fps in critical areas. Thanks!
I just noticed that I dont have installed PhysX after clean install of new nVidia drivers. When I installed last version from nVidia official website - lags are returned.
Problem in PhysX.
So, probably game uses core 1 of CPU for PhysX and its not enough = STUTTERING.
Is there a working fix for stuttering @ Multicore CPU’s ?
Im running bms with an i7 3770k@4.2ghz + ATI HD6870 GPU.
There is some stuttering at some places/events, the fps is fine all the time.
@
Possible fix:
Get into task manager.
Click the processes tab.
Find the hl2.exe process.
Right click > Set Affinity… > select all cores but one
Should it look like this ?
I’ve a Geforec GTX 570. And the processors are (old!) Intel® COre™2 Duo CPU E8500 3.16Ghz
Anyway, this fix from the first comment, seems to fix the lagspike at the end of Lambda Core for now.
Maybe it’s because Windows 8 is more smart about this kind of stuff or something but playing it on my trial copy of Windows 8 x64 Enterprise Edition, it automatically checks all 4 CPU core boxes and the all processors box as well. It’s also set to at least normal priority. I also have been running with the newest nVidia drivers since they came out, not sure if that matters.
My specs are Q9550 Core 2 Quad, 4GB of DDR2 and a GTX 260 216-core, all at standard clocks. I run the game maxed out with Vsync and everything is absolutely smooth as butter, everything. There’s the tiniest half-second pause when saving but that’s to be expected, I’d imagine if I had an SSD, that little pause would probably be gone too, lol.
I will say I noticed that when the game was at the menu, according my G15 keyboard’s performance display it was primarily using 100% of the first core and very little of the others but the performance is still buttery smooth even in the menu and I also noticed it seems to split the load up in 25% for each core at start-up loading. I have yet to look at the in-game CPU usage but this is just my experience at the menu.
Hi 
I’ve got the same problem with my Intel Q6600. The core “0” is always 100% in use, but the others are max. 10% in use. I noticed that, because after playing, the core “0” was a little bit hotter then the other cores, like 2- 5 °.
I’ve tested some stuff…
But thats not my main problem, cause i still get these short stuttering issues sometimes.
For example i get stuttering if i enable my flashlight first time (at new places) and with some other “firing events and hit events”.
Seems to be caused by (just full for a sec) “CViewRender::Render”.
I also get these in console:
Physics queue not empty, error!
Can anyone help me to fix this ?
Specs.
OS: Win 7 x64
CPU: Intel Core i7 3770k@4.2GHz / Hyperthreading Disabled (for test)
GPU: ATI HD6870(1gb)@stock.
Driver: 8.961-120405a-137813C-AT, Catalyst 12.8@Default
RAM: 8GB DDR3 1666
Harddrive: Samsung 830 SSD
autoexec:
cl_forcepreload “1”
snd_mix_async "1
snd_async_fullyasync “1”
mat_queue_mode “0”
AFAIK Source engine do not use PhysX. Thus your observation WRT PhysX being a stutter cause are most probably a simple coincidence.
It also should be noted that the game do not operate in “use CPU core” terms. It just creates a separate thread for some tasks it has do. Multicore rendering is when the game separate rendering-related jobs to multiple threads so OS CPU scheduled could place the execution of these threads on different CPU cores. In Source 2007 SDK multicore rendereing is broken and it should be disabled in-game (mat_queue_mode 0) to be able to render correctly - microstutter-free and without frequent crashes.
But the engine still could use separate threads to do some other tasks (particle simulation, sound effects, sound mixing, physics and so on), especially if you would ask it to do so (in console execute “find thread” and set to 1 various cvars looking like *_something_threaded; snd_mix_async and snd_async_fullyasync enable use of a separate thread for sound voices mixing duties) thus the game still take some advantage of the multicore CPUs, it’s just not that huge in terms of performance gains.
It is normal for single-threaded game to task only one core and do not use any other. OS scheduler could flip-flop the game from core to core in order to even the load on them but it would cause more lags than you’d want to - context switches is not a cheap thing. With properly configured Source 2007 SDK and a proper GPU driver core usage should look like one core being used 100% coupled with moderate load (in 10-75% range, depending on GPU and CPU speed) on a couple of other cores: that’s GPU driver doing its multithreaded optimizations and the game doing secondary tasks like particle system simulation and sound effects/mixing in a separate threads.
Thanks, I’ve added this fix to this PCGamingWiki page: https://pcgamingwiki.com/wiki/Black_Mesa#Lagspikes_And_Performance_Issues
Hmm can someone who experiences random hitches (brief stutters) try this, alt-tab out of Black mesa and in Steam click Store, then click the Demos tab, Now alt tab back into Black Mesa and see if this helps.
For some reason if steam is on the default “Featured Items” store page it causes a random CPU spike in steam.exe (noted in task manager on my 2nd monitor while playing) but if the Store is on another tab such as Demos the CPU spike stops completely which in turn reduces hitching in games like Black Mesa.
BTW it’s a well-known misbehavior caused by the Flash plugin Steam uses in its internal browser to display some parts of the store page. Best practice is to never open up a Store tab after you start up the Steam in order to play some game, or to browse to some dummy/mostly empty page in the Store web browser to make sure Flash won’t send a laggy “hello, there” just at the worst possible in-game moment :-).
Hey guys,
I mostly get pretty good fps except for a few areas here and there, that and some slight pausing as well. I tried all of the things in this thread and while a few were helpful, they didn’t quite get rid of it.
I found a thread over at ‘hardforum.com’ that seemed to have fixed my issues and now everything is buttery smooth.
https://hardforum.com/showthread.php?t=1717116
Quote from ‘zombiefly’
“I added +fps_max 66 to the additional start command line options in steam.
switched vsync ON, and developer console then in console typed snd_mixahead 0.4”
Will there be an update to fix all of this?
I think that is Source skd problem. Valve need to update this and add multicore support.
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.
