DirectX8 Graphical Errors

[Trigger_Proximity]

So there’s a bunch of graphical errors caused by running the game in dx80. I know a lot of people won’t actually run it in dx80, but bugs are bugs so w/e.

All settings are at minimum.

#1 With HUD post processing on while in DX80, a wireframe is drawn across the screen:

#2 Pink/Black error texture drawn over most toxic waste:

#3 Pink/Black error texture drawn over some viewmodels:

#4 All non-unique NPCs have the pink/black error texture drawn over their eyes:

#5 When underwater, the pink/black error texture is drawn over the entire screen making it impossible to see and impossible to progress. I’ve only noticed this in two areas so far, both with cheap water instead of expensive, so I believe it has something to do with that.

[Trigger_Proximity]

Well that explains everything.

[Tikuf]

Okay i had the same problem for solve it, you must go into the start option and then put
-dxlevel 100 if it’s still don’t work try 110 or 120 or 80
or like Raminator said direct9

[sersoft]

Mat_dxlevel 95

[lexa2]

Correct way to switch Source-based games to specific renderpath (a.k.a. dxlevel) is to use one-time command line parameter supplied to hl2.exe, namely “-dxlevel XX”, where XX should be one of: 70, 80, 81, 90, 95, 100. Future engine versions might be modified to recognize some other dxlevels, say 110 and so on.

This switch is a ONE TIME USE because it essentially sets mat_dxlevel to the specified XX level, caches its value in system registry and then causes the game to reset all renderer configuration cvars into sane defaults for that renderpath. As the end-user one won’t want the game to reset all settings to defaults each time he or she launches the game thus after using -dxlevel switch once it should be removed from the game binary command line parameters.

Changing mat_dxlevel from the in-game console isn’t a good way to head: this change won’t persist after the game restarts and it isn’t a safe operation per se (i.e. mod should be programmed in a way it [a] supports various dxlevels and provides fallback for them and [b] is capable of gracefully clean up and then re-initialize its internal renderstate on renderpath change. It is not the case for BMS - it doesn’t support dxlevels other than 90+ and it can’t always safely handle even simplier renderstates changes like mat_reloadallmaterials or mat_bumpmap hanging after calling/changing thiese one two times out of four.