AMD K2-2 550 w/ 128MB RAM and 2 Voodoo 2’s in SLI.
I’ve written some sample programs using HeNe’s samples. My stuff and his seems real slow. I’m getting about 2-5 frames/sec on most demos, other demos are even slower such as the partical shower. This is all done in C with MS vis Studio 6.
I’m using the standard header and lib files that came with VC98 and latest platform SDK. Is that my problem? Also, I know OpenGL is fast since I play Quake 3 and that games rocks on my system. I have noticed that the OpenGL screensavers also have the same performance problem.
Could all the floating point be the cause of this? Was a majority of the Quake engine done in assembler?
Please help to find the reason why things are so slow over here.
Yep, that did the trick. To make it global, I just copied 3dfxvgl.dll right over opengl32.dll in the \windows\system directory. I wonder why 3Dfx didn’t do that for us.
lucky for you, you can replace the opengl32.dll, I can’t everytime I do, Win2000 rewrites it with it’s own friggin dll
Now that sucks !!! I know microsoft dosn’t like OpenGL that much, but to change the opengl dll’s to the way they like it, is getting beyond a joke ( there’s noway im getting windows 2000 )…
Most 3D venders are shipping OpengL 1.2 with their drivers… Becuase Microsoft refuses to update OpenGL to 1.2 on their O/S’s… Now they make it so you can’t have opengl 1.2 on windows 2000… that pisses me off !!!
That’s a little unfair… Win2k protects ALL system DLLs, not just the ones Microsoft doesn’t like. This is to stop applications breaking other applications by installing incompatible DLL versions - what used to be known as “DLL hell”. On balance it’s probably a step forward.
If you look at the ARB minutes, MS plan to release a FULL OpenGL 1.2 implementation (including the optional imaging subset) with Win2k SP2. I know the team in question has some unfilled vacancies - for some strange reason OpenGL programmers don’t seem too keen on working for Microsoft - which may be slowing them down.
As for why 3Dfx didn’t ship their OpenGL driver as “opengl32.dll”, they couldn’t. As a 3D-only, fullscreen-only solution they couldn’t meet the requirements for an ICD.
Exactly, which is why you should dynamically load the 3dfxgl.dll at run time, rather than having your executable linked to the opengl32.dll. However, I have still noticed that for this to work, I still have to copy the 3dfxgl.dll to a temporary directory, and rename it opengl32.dll, as gdi seems to want the dll named as opengl32.dll. But at least this way, I’m not trouncing over the users dlls, and I can also support multiple vendors cards within the same computer. I currently have a Voodoo2 and a TNT, and I can run my app on either one, just by choosing which opengl implementation to load. Just like many OpenGL games I’ve played can.