BMS DirectX 8 Mod

The place is generally correct, but the height value reported by getpos seems to be a bit off. Here is more correct one to use:

setpos -701.474915 -1567.974365 -290; setang -0.292490 27.619244 0.000000

Yes, there’s nothing wrong with that place at a first glance but if you would try to unlock FPS limiter (set fps_max to something like 300) and then try looking at different direction there you’d find that when looking towards the direction setang sets you FPS drops down 1.5x-3x times compared to what it is when looking at other directions. This is due to technically invisible water on the floor located right behind the wall you’re looking at. Try executing mat_fillrate 1 in console and you’d get an idea. Disabling reflection rendering for water workarounds this FPS drop. It seems not to be a big problem with a GPU like 550 Ti when running whithout AA @1400x900, but as soon as you increase output resolution or enable 4xAA FPS starts to approach ~30 range which is uncomfortably low IMO.

It is a fillrate shortage due to overdraw caused by smoke cloud particle system. If you try to use any higher resolution like 1680x1050 there - FPS would be in the “uncomfortable zone” even without zooming.

Like in (B) here there are obvious problems with dynamic lighting calculation. I have no ideas what’s wrong with it in BM and why there are no similar problems with setting zombies on fire in HL2 (Ravenholm) or in HL2:EP1.

And these are not the worstest cases - in case you happen to be shot by the sentry guns in bm_c1a3b near this spot:

] getpos
setpos -1377.831665 -726.231445 -17.525650;setang 12.491111 -90.911560 0.000000

FPS could drop down to as low as ~20 making pretty hard to react properly on heavy fire and to run away or to snipe the turret.

Yeah, I also have this PoV on the problem: the game is Ok to play with GTX 550 Ti and any 3.0-3.5GHz dual-core CPU. But it does not run perfectly well though. And it also means that people with ~100 USD nowdays GPUs like GTX 540 or GTX 640 would suffer from these drops hardly. And you could guess yourself how would cards like Intel HD 2000/3000/4000 perform in problematic places :-D. Still IMO it’d be better (and more people would benefit from it) if devs would consider spending some time optimizing dlights and fillrate issues related to particle systems rather than spend way more time re-implementing shaders fallbacks for dxlevel 80/81 renderpaths (which - if it would be done - won’t necessary mean better performance when using legacy pipeline).

I see, thanks
the updated position and explanation made a lot of sense, yes there is clearly a problem, looking at that angle I will get around 45fps elsewhere is over 120,

and at the spot of the sentry guns as soon as they start firing… 20fps and dynamic light rendering goes crazy…

and I see your point, lower end hardware must be having a hard time with the game, I tried lowering details (with same res) to the minimum possible whiting the game and it didn’t really improve much the performance in these places…
and focusing in DX8 is probably not the way to go…

another thing, at the scene I posted the screen with the zombie on fire (https://i50.tinypic.com/dcznr6.jpg) when the framerate drops to the 20s I noticed that the reported “GPU usage” by “MSI afterburner” went down significantly, would this mean that the CPU performance here is the main factor with the problem with dynamic light rendering?

Sometimes it seems like the game freezes for a split second, whenever Xen portals are opened in the level.

If more are opened within a short period of time, the said freeze or stutter occurs for every single portal - making it impossible to react quick enough here and there.

As I said, it’s just a split-second, but still - a tiny moment of stutter could cost your life, easily (especially on higher difficulties).

Is there a particular reason for this?

You’re not the only one. I had the same thing.

It’s not that we can’t use DX9. Far from it. It just we have things set to DX8 so we don’t get epic freezes mid-game or crashes when trying to fight a bloody Apache.

It would be A+ to have DX8 support for the Steam release.

quoting myself with some evidence,
I don’t know if this is the right area/topic, but since the discussion about performance is going on…

here is the fill rate limited area
GPU usage at 99%
https://i49.tinypic.com/ev5fgp.jpg

dynamic lights
GPU usage 37%
https://i50.tinypic.com/2e2nkn5.jpg

and here an interesting test with many different GPUs, from what I understand they made the test on the area of the first screenshot
https://gamegpu.ru/action-/-fps-/-tps/black-mesa-test-gpu.html

so what I’m wondering really is, if with the same CPU I used a faster graphics card, would the framerate in the second area (with low GPU usage) improve significantly?

[COLOR=‘Silver’][offtop]Коллега из России детектед :-).[/offtop][/SIZE]
I bet there won’t be significant framerate improvement - it seems that dlight calculations are mostly CPU-bound so they either should be optimized by splitting up the work over multiple cores of multicore CPU (it is not the same as “milticore rendering” feature people tend to treat as a panacea for their FPS dropdows problems) which might or might not be possible with current and/or 2009 version of the Source engine (I’m not the biggest expert in the inside details of the Source engine so don’t know for sure; on the other hand I’ve pretty experienced with the internals of the DarkPlaces engine which is and open-source idTech1 engine modification which nowdays is pretty on par featurewise with Source or idTech4). And knowing that there are not THAT BAD problems with dlights usage in the HL2, EP1 and EP2 - I tend to think that something is wrong with the way BM use dlights. If latter is the case - it could be fixed/optimized in future BM patches.

SPBHM, could you please try testing the PoC FIX for test chamber FPS dropdown I’ve posted here: https://forums.blackmesasource.com/showthread.php?t=14361 .
I’m curious if it would work for anybody having old GPU. Thanks in advance.

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.