[Driver issue]Can't switch to GL mode

[Graf Zahl]

There's also the fact that something like five dozen other 3D games (including GL Quake) worked and still work absolutely fine; it's only GZDoom which is refusing to work in GL mode.

I still don't see how that is even possible. All your console logs show that your system does not access your graphics card's GL driver but Microsoft's default instead. Even if there was a problem with some unsupported features it still would report the correct driver but it doesn't.

Can you post a current console log to verify that it is still the same problem?

It might also help if you posted the contents of

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\OpenGLDrivers

from the Windows Registry.

[Graf Zahl]

I see the problem has resolved itself and it is the one cause I would never have guessed because it is so painfully obvious that you should never do that!

[NiGHTMARE]

Well, technically it wasn't me who did that, but another port

I also had absolutely no idea GZDoom would try to use opengl32.dll if it were present, seeing as the file included with GZDoom is r_opengl32.dll. Even if had known that, I don't know enough about programming to understand why some other port would require opengl32.dll in order to work, but the same file causes GZDoom to not work .

[Graf Zahl]

Never, ever do that! There is no better method to screw up an application's behavior more thoroughly. The ATIOGLXX.DLL is the GL ICD which is not the same as OpenGL.DLL, OPenGL.DLL uses this DLL and they are not interchangeable.

Well, that's how it has worked in other OpenGL apps... but if it works that much differently in GZDoom.. go figure (it wasn't obvious to me)

It has nothing to do with GZDoom but with the DLL's export table. The default OpenGL.dll is never replaced. The graphics driver has to install its GL driver so that it can be used by OpenGL.dll. This old fossil is responsible for the GL 1.1 API Windows has been stuck with for ages. Anything more advanced has to be done by the extension mechanism.

If you are interested, this is the export table of NVidia's GL driver. Trying to run an application with that as OpenGL.dll won't work at all!

Code: Select all

	0011F610h     	   1     DllMain
	00203060h     	   2     DrvCopyContext
	00202650h     	   3     DrvCreateContext
	00202350h     	   4     DrvCreateLayerContext
	002014D0h     	   5     DrvDeleteContext
	00202260h     	   6     DrvDescribeLayerPlane
	00202DB0h     	   7     DrvDescribePixelFormat
	00202910h     	   8     DrvGetLayerPaletteEntries
	00202CB0h     	   9     DrvGetProcAddress
	00202B00h     	  10     DrvRealizeLayerPalette
	00201F20h     	  11     DrvReleaseContext
	00201EA0h     	  12     DrvSetCallbackProcs
	00202EE0h     	  13     DrvSetContext
	00202660h     	  14     DrvSetLayerPaletteEntries
	00202E20h     	  15     DrvSetPixelFormat
	00201FA0h     	  16     DrvShareLists
	002021D0h     	  17     DrvSwapBuffers
	00202180h     	  18     DrvSwapLayerBuffers
	00202CF0h     	  19     DrvValidateVersion
	002EF2F0h     	  20     GetIAtomString

[Graf Zahl]

Even if had known that, I don't know enough about programming to understand why some other port would require opengl32.dll to work, but the same file causes GZDoom to not work .

No port needs that DLL in its own directory and AFAIK none distributes it. ZDoomGL and Vavoom never did and AFAIK Doomsday doesn't either but I don't have a recent version to check. It is most likely some GLQuake relic which shipped a Voodoo GL driver and made some people think that it is necessary.

BTW, if you look at r_opengl.dll's import table you will see that it logically links to opengl32.dll to access GL. r_opengl.dll is merely a wrapper DLL so that I can replace it with a D3D version if the need ever arises.

[Graf Zahl]

I didn't notice during a new revision of GZDoom that there was a gzdoom.wad file and a gzdoom.pk3 file in the GZDoom directory... (I got rid of the .wad file and fortunately nothing screwy happened with GZDoom when both were in the GZDoom directory)

When I added ZIP support I got rid of the WAD. ZIPs are much easier to handle so it was a logical choice to make the default resource file one as well.

[NiGHTMARE]

No port needs that DLL in its own directory and AFAIK none distributes it.

I've discovered why that opengl32.dll was there, and you're right on the second part, but slightly wrong on the first .

A Google search reveals that there were apparently some issues with the old ZDoomGL and Voodoo cards (either it wouldn't work at all, or very slowly), and the way to fix it was to copy 3fdxogl.dll from the Windows\System directory to the ZDoomGL directory. The card I had prior to the Radeon 9700 was a Voodoo 3 2000, and I do vaguely remember having to do something like this to get ZDoomGL to work .

[Graf Zahl]

Don't mention 3dfx and OpenGL in the same sentence. That combination was a problem from start to finish. Maybe a result of a time when GL was more obscure...

[Deathlike2]

I just remembered what I had to say in this...

You are able to use whatever OpenGL client driver (well, the one for your own hardware) by putting that file in the same folder as the OpenGL app. This way, you can use an OpenGL client driver that worked best for that particular OpenGL app instead of using the driver installed in Windows's SYSTEM32 folder (which normally is used globally for all OpenGL apps).

[DaniJ]

AFAIK Doomsday doesn't either but I don't have a recent version to check

I can confirm Doomsday has NEVER used that dll, nor is it a part of the distros.