OPENGL

[whiplash]

With my other cards all I had to do was make sure the relevant opengl32.dll was in the game folder.

Is this the case with the G400MAX, or is the driver hidden somewhere like in the windows\system folder under another name. I want to make sure the game uses the correct opengl as I still have opengl for my VoodooII.

[Maggi]

Depending on your card, there should be either a G200icd.dll or g400icd.dll.

In your case of course the g400icd.dll

OpenGL32.dll should be there as well.

------------------
CU,
Maggi
________________________
Asus P2B-DS @ 112MHz FSB
2x P3-450 @ 504MHz
512MB CAS2 SDRAM
Millenium G400 32MB DH



[This message has been edited by Maggi (edited 09-06-1999).]

[Kruzin]

OoenGL32.dll SHOULD NOT be in your game's directory. It is part of windows, and should be in windows\system.

The only time you should see opengl32.dll in a game dir is if you are using some kind of wrapper (like we used to for the G200). If there is an opengl32.dll in your game dir, it will try to use that instead of g400icd.dll/opengl32.dll from windows, and it probably won't work like that...

[absalom]

The g400 ICD is named g400icd.dll and actually requires the opengl32.dll that comes with windows to operate correctly in opengl games (correct me if I'm wrong here.. but this is what I have observed so far). I have no idea why this is so, but it is the only way it seems to work. They both must reside in /windows/system also (and will if you installed PD and didn't delete the windows default opengl32.dll). For 3dfx cards you could slap any old opengl32.dll in your game directory and the game would use that one (i.e. quake2 or half life). If you try to copy the g400icd.dll and rename it to opengl32.dll and try to make a game us it, it just won't work. The best way to go about getting you game to work is just leave the opengl32.dll that comes with windows alone, install PD, and then remove any opengl32.dll files you may or may not have in your game(s) directory.

[whiplash]

Hmmm,

Thanks for the helpful info. I wonder why Matrox 'hook' into the standard windows opengl32, I would have thought this must be a restriction on the maximum speed or efficiency they could obtain.

[Snake-Eyes]

Just for everyone's info- this is the same way nVidia's ICD works. Prior to receiving my Max, I was using an STB V4400 TNT AGP, and there's still an entry in the registry for it's ICD and the corresponding .DLL file. Right above this entry, there is also an entry for the Matrox ICD's DLL file.

If you're curious about this, it appears that this may be the way that the Windows OpenGL (ICD) mechanism is meant to work- ie.: OpenGL32.DLL is always the MS supplied file, with an entry in the registry indicating whether or not the calls should be passed on for a graphics card's ICD, including the name of the DLL implementing the ICD.

------------------
Ace

[Kalzus]

According to Microsoft coding standards, the correct way to write your ICD is to leave the MS-supplied OpenGL32.DLL alone. Your ICD is supposed to "hook in" to the calls supplied by the DLL. The DLL acts as sort of a "traffic cop" for in case you have an MCD installed instead, so that a call your MCD doesn't support gets routed back to software emulation without the IHV writing the software emulation routines himself (something that must be done if you wish to write an ICD).

It's kind of nice to have this setup to make it easy on people who decide to change their video hardware later, and it makes it easier for Microsoft to release system updates that work when drivers follow the rules.

It kind of works to place a copy of "Opengl32.dll" in your program's directory since Windows library loader is designed to pick the library out of the program's executing folder before looking in the system default places to aid debugging or in case you ship with a specific copy of, say, CTL32V2.DLL in case you are worried your code does thing that won't work with another version. But it's discouraged.

[McRhea]

Sorry for bringing this back up guys, but let me get something clear...
I should have the opengl32.dll and the g400icd.dll in the Windows\System folder, right? Even for Unreal? What about the G400 and OpenGL files in my Unreal\System folder? I'm confused.

[cjolley]

Turbo GL drivers change things a little. It is a driver that you only want to use for specific programs, so it must reside in the exec directory of the game so that the loader will find it first when sending calls.
chuck



------------------
ABit BH6 w/ Celery 333@500, 128mb gh@cas2, 10gb IBM@7200, SB Live Value@3.0, noname CDRom@40x, Mitsumi CDRW@2x2x8, Acatel 1000 ADSL@1.5mb/sec, Princeton EO75@1024x768x32x85hz, USB mouse,Matrox G400 MAX!!!!

[paulcs]

McRhea, I think you really should be using D3D for Unreal and not OpenGL. The implementation of OpenGL in Unreal and UT is dodgy at best (I think the games's manufacturer describes it as "experimental").

I just don't think it's worth it.

Paul
paulcs@flashcom.net

[paulcs]

Unless, of course, some miracle patch has been released recently that fixes all of this.

However, these are Glide games, and I've only played the first game with Glide. I've found the D3D implementation for Unreal Tournament to be quite good on my G400.

If I were you, I'd take the path of least resistance.

Paul
paulcs@flashcom.net

[This message has been edited by paulcs (edited 16 December 1999).]

[McRhea]

Funny thing is, OGL seems to work better then D3D!!! Isn't that whacky?? With OGL I can get 80-120 FPS average, but with D3d it only goes to about 50 FPS MAX... I can't get D3D to go above that for some strange reason. And in D3D the game isn't smooth... meaning that as i'm running around and turning corners, the hard drive "thrashes" around until i stop moving. And once it calms down, then it's fine. It's hard to explain, but I'll try. In a new map, if I go to a place that i haven't been yet in that current game, it makes the HD start to "grind"... you know, like it's searching for something. Once it's done, I can go back to a different part of the map and come back, and it won't do it again. I suspect that the game is being set in the HD memory... I don't know why else it would do that. When I had my Voodoo it didn't do that. With the OpenGl option, it's not nearly as bad, and the colors are more viberant. Weird huh?

Anyway, above, Kruzin says that there should NOT be a opengl32.dll driver in the Unreal/System. But when I install the new TurboGL drivers, it installs it into the Unreal/System folder. What's going on? Is that normal?

[MotherDawg]

WO WO WO!

Kruzin, in my system which wouldn't run any OpenGL games (Q3AD - UT) for a month until the new TurboGL V1 arrived. I clicked on it, it identified my games perfectly and did what it had to do. Now everything run just fine.

TurboGL did instaled a file named "OpenGL.dll" in the games directories.

It is not the same than the MS in the Windowz/sytem directory. That one is V. 4.0 and it's 737k, the one in the games is Matrox V. 5.41.006.001 and it's only 578k. BTW, check the the "Special Build Description" in that one.

Cya


------------------
Celery 366 OCed @ 458(83), Soyo 6BA+III, 64MB SDRAM, Millennium G400 DualHead (486 cpu fan), SB Live! Value, FBall KA 13.1Gig (7200rpm), Mitsumi CR-4804TE CD-RW, Intel based 21140 10/100 NIC, Nortel Networks HSA1300 1-meg ADSL modem and also a ModemBlaster DI5630... enough!


[This message has been edited by MotherDawg (edited 17 December 1999).]

[This message has been edited by MotherDawg (edited 17 December 1999).]

[Kruzin]

Yes, things have changes since I made that post. Now that there is a P2/K6 TurboGL, there will be an OpenGL32.dll file in supported game's folders.

The one in the sindows\system folder needs to remain the default windows one (which your's is), for the full ICD to wirk.

[McRhea]

Uh... ok. Then I have a problem... Windows did NOT come with the opengl32.dll file in the Windows/System! Where is it on the Win98 CD so I can stick it back in?