That Miserable Thief on 5/7/2018 at 23:43
Thank you. That worked. Do you recommend using the patch, anyway?
baeuchlein on 6/7/2018 at 09:17
I had the same problem with Win7 x64 and an Intel HD 3000, and "r_useGLSL 0" helped with that as well. Could be a common issue with these Intel graphics.
Updating the driver never worked for me. All Intel drivers I tried did not recognize this graphics chip. Maybe it's branded in some way.
nbohr1more on 7/7/2018 at 12:30
Quote Posted by baeuchlein
I had the same problem with Win7 x64 and an Intel HD 3000, and "r_useGLSL 0" helped with that as well. Could be a common issue with these Intel graphics.
Updating the driver never worked for me. All Intel drivers I tried did not recognize this graphics chip. Maybe it's branded in some way.
Coincidentally, Intel's site says that this is also the latest driver for your graphics:
(
https://downloadcenter.intel.com/download/24971/Intel-HD-Graphics-Driver-for-Windows-7-8-64-bit?product=81502)
What does GPU-Z say about your graphics chip? Maybe it's some custom variant of HD 3000?
baeuchlein on 9/7/2018 at 11:19
Quote Posted by nbohr1more
Coincidentally, Intel's site says that this is also the latest driver for your graphics [...]
Not so coincidentally.;) The Intel HD Graphics 3000 is very similar to the HD 2000. AFAIK, it just has some more parallel graphics processing units than its predecessor. Same applies to HD 4000 and other HD xxxx variants, if I remember that right.
Anyway, the driver there is exactly the one I tried some years ago without success. The driver there has the same date as the one I tried years ago wihout success, but the version number differs, and there are other differences as well. You can read what happened when I installed it somewhat below in this post.
Quote Posted by nbohr1more
What does GPU-Z say about your graphics chip? Maybe it's some custom variant of HD 3000?
GPU-Z and Linux' lspci basically say the same about the chip. Nothing suspicious, but both say that the "sub-vendor" of this particular chip is ASUS. That is the manufacturer of the laptop I use. lspci also says that almost all PCI hardware in this laptop has an ASUS subsystem ID, although most parts are Intel designs. I guess this is the culprit here, and that's what I meant by "branded": There's something like an electronic stamp or label on the device marking it as an ASUS device, and some Intel drivers won't install then.
I doubt that my HD 3000 really differs from others because it is not a single chip soldered on the motherboard, but integrated into the Core i3 CPU. That would mean that Intel had to change something in their CPU just for ASUS. I'm not in the CPU manufacturing business, but that just sounds too expensive to accomplish just for another manufacturer's wishes.
Concerning drivers: A few months ago, there were no new graphics drivers on the ASUS website for this laptop. I will check that again, but if I still find nothing new there, there's another option. The Intel site now has instructions for installing the Intel drivers even if the device is meant to use only drivers by the (other) manufacturer. This was not there when I last checked that site out. I will try the Intel driver again and use these instructions if it still does not want to install.
What exactly does "r_useGLSL 0" do anyway? I read in the (
http://wiki.thedarkmod.com/index.php?title=What%27s_new_in_TDM_2.06#Old_TDM_Look) TDM wiki that it disables this GLSL thing, but there's no explanation about what GLSL actually is or does.
EDIT: I did now try out that newer Intel driver you mentioned. It did not change the problem with TDM 2.06, I still need "r_useGLSL 0" for proper display of many light sources. But the driver introduces long delays at random stages of the boot process, and messed around with some desktop icons as well. I am going back to a former backup of Windows since the former driver did not give me all that trouble.
No new driver versions from the laptop manufacturer, btw.. Maybe there's a reason for that.
-shrugs-
nbohr1more on 9/7/2018 at 17:32
Quote:
What exactly does "r_useGLSL 0" do anyway? I read in the TDM wiki that it disables this GLSL thing, but there's no explanation about what GLSL actually is or does.
EDIT: I did now try out that newer Intel driver you mentioned. It did not change the problem with TDM 2.06, I still need "r_useGLSL 0" for proper display of many light sources. But the driver introduces long delays at random stages of the boot process, and messed around with some desktop icons as well. I am going back to a former backup of Windows since the former driver did not give me all that trouble.
No new driver versions from the laptop manufacturer, btw.. Maybe there's a reason for that.-shrugs-
Sorry to hear about the driver issue.
GLSL is short for OpenGL Shader Language.
It's a high-level language that your OpenGL driver converts to binary when shaders are executed.
Doom 3 originally shipped with ARB shader language which is like Assembly (ASM) and is very low level.
Advanced graphics techniques are very difficult with ARB assembly (as with any low level assembly language)
so adding GLSL to the project opens things up to make it easier to design new graphic effects.
Also, ARB assembly is pretty much deprecated in modern OpenGL. It is risky to continue using it as drivers may eventually
drop support for it altogether. Most graphic card vendors stopped adding ARB assembly features around OpenGL 2.1. (DX9c )
The problem is that the current GLSL shader has some advanced features that most cards with hardware below GL 4.3 don't support.
We are planning on making TDM GL 3.x compliant after 2.07 so that some older hardware may be able to run soft shadows
or at the very least all hardware will use the same backend and nobody will need to use the old ARB backend. There may even
be some fixes in 2.07 to reduce the issues around older hardware (use different extensions, change the way some things are implemented, etc).
baeuchlein on 10/7/2018 at 08:57
Quote Posted by nbohr1more
Sorry to hear about the driver issue.
So much for software quality and driver support these days.:ebil:
Quote Posted by nbohr1more
[...]The problem is that the current GLSL shader has some advanced features that most cards with hardware below GL 4.3 don't support.
We are planning on making TDM GL 3.x compliant after 2.07 so that some older hardware may be able to run soft shadows or at the very least all hardware will use the same backend and nobody will need to use the old ARB backend. There may even be some fixes in 2.07 to reduce the issues around older hardware (use different extensions, change the way some things are implemented, etc).
Maybe one should first check whether old hardware will offer reasonable performance with these approaches. It could be a waste of time if you programmed something to let TDM run on older cards, and end up with something that technically works, but runs (or rather sneaks:p) very slowly then.
And although I liked the fact that TDM was finally playable on my ISG (
Intel
Shitty
Graphics:ebil:) hardware this year (in contrast to what I experienced last year), I must admit that Intel graphics are usually too weak for many games. And that won't get better while these integrated graphics grow older.
I also don't think that TDM's major problems are found around graphical effects. I have severe problems with combat. And in several city missions, TDM apparently needs more RAM than the 4 GByte found in my laptop. At least that's what an analysis with HWINFO suggests - TDM does not complain, it prefers to just crash without giving the player a clue about what's wrong. Those things give me far more trouble than graphic effects.
Csimbi on 10/7/2018 at 12:34
Quote Posted by baeuchlein
ISG (
Intel
Shitty
Graphics:ebil:)
I have not heard that one before, it's a good one ;-)
nbohr1more on 10/7/2018 at 20:07
Quote Posted by baeuchlein
So much for software quality and driver support these days.:ebil:
Maybe one should first check whether old hardware will offer reasonable performance with these approaches. It could be a waste of time if you programmed something to let TDM run on older cards, and end up with something that technically works, but runs (or rather sneaks:p) very slowly then.
And although I liked the fact that TDM was finally playable on my ISG (
Intel
Shitty
Graphics:ebil:) hardware this year (in contrast to what I experienced last year), I must admit that Intel graphics are usually too weak for many games. And that won't get better while these integrated graphics grow older.
I also don't think that TDM's major problems are found around graphical effects. I have severe problems with combat. And in several city missions, TDM apparently needs more RAM than the 4 GByte found in my laptop. At least that's what an analysis with HWINFO suggests - TDM does not complain, it prefers to just crash without giving the player a clue about what's wrong. Those things give me far more trouble than graphic effects.
In the VBO beta patch, there is already some initial support for compressed Normal Maps so whenever we complete that work VRAM usage
should be significantly lower. The current implementation compresses to RGTC on-the-fly but has some broken graphical effects on glass and particles
because the ARB shaders don't know how to read RGTC normal format. You could test it by setting image_useNormalCompression 2 on
hardware that supports our current GLSL.
That said, after v1.07 the Standalone project brought in lots of textures at 1024x1024 resolution (as compared to the 128, 256, or 512 versions that we were using
with Doom 3). You may consider using the image_downSize cvars to force textures back to lower resolutions:
image_downSize 1
image_downSizeLimit 256
image_downSizeBump 1
image_downSizeBumpLimit 256
image_downSizeSpecular 1
image_downSizeSpecularLimit 64
This is especially useful now that these no longer make menus blurry and the now work with Bloom (Post processing).
nbohr1more on 14/7/2018 at 03:01
I can't speak to the issues with the default configuration keys that much.
We've historically had a bias towards players who play with Keyboard and Mouse so it's probably
just a situation that has grown out of that orientation.
As for the resolution and "squishing"?
We did recently move to a GUI that is more oriented to 16x9 resolution ratios but we probably need to make more
GUI assets and some heuristic to toggle between them depending on setting.