PDA

View Full Version : 3D Textures & Windows 2000



philippe
03-14-2001, 03:20 AM
I just got the book 'OpenGL Superbible' (2nd ed.) and tried to run the 3D texture sample
on my PIII, with a TNT board (NVidia driver 650), running W2K, SP1.
The prog. crashes immediately. I've tried to recompile it, but the 3D texture stuff is missing in the MS header files (Visual Studio 6.0 SP5), I could only find the GL_TEXTURE_3D #define in the Mesa lib, but that's not what I'm looking for.
Is the W2K implementation of OpenGL really 1.2 compliant ??
Furthermore, in the flight simulator sample from the same book (all versions of the fs), there's a serious problem with the scissor buffer (first diagnostic...), the sky part of the screen is never refreshed, and always overwritten by the movements of the terrain part.

Any help appreciated.
Phil

Michail Bespalov
03-14-2001, 03:35 AM
Hi.
Microsoft provides library and header for opengl 1.1
use wglGetProcAddress to access all 1.2 functions and glext.h for definitions.
Michail.

philippe
03-14-2001, 04:53 AM
Hmmm...this sounds really poor from MS (as usual), does somebody know if there's a real 1.2 implementation for win32 somewhere ? (NVidia ?)
At least the includes and libraries would be a great help. I'll try to rebuild the import-lib to avoid wglGetProcAddress(), and check for glext.h in the book's CD.

Thx
Phil

Michail Bespalov
03-14-2001, 05:32 AM
Originally posted by philippe:

I'll try to rebuild the import-lib to avoid wglGetProcAddress(), and check for glext.h in the book's CD.
Phil

Where are no 1.2 functions in the export table of opengl32.dll. Windows image loader will not be able to load your exe.You have to use wglGetProcAddress with MS opengl32.dll

[This message has been edited by Michail Bespalov (edited 03-14-2001).]

Nutty
03-14-2001, 05:54 AM
I really dont understand this limitation thing with the version of Opengl32.dll.

If this is only 1.1, does that mean any functions from 1.2 (or higher) must be done via extensions until MS release a new version of this file??

Isn't there a Opengl.dll which is SGI's?
As some people have said, MS control OpenGL wheather we like it or not. This is a very poor state of affairs, considering MS is hardly likely to pursue developements in OpenGL when they want their own API to be the be-all and end-all 3D api.

Why doesn't someone sort them out.. and make them update it to 1.2 or something..

philippe
03-14-2001, 06:07 AM
You're damn right, how the hell can these suckers at MS pretend they're 1.2 compliant ???
Just to simplify their life they could have exported one function (like GL()) and require developers to get the address of everything else dynamically!

Bastards!!!!

Thx
Phil

Bob
03-14-2001, 06:14 AM
opengl32.dll contains a mechanism for redirecting your OpenGL-calls to the driver instead of executing them itself. Now, if you want to call a function that opengl32.dll does not know about, like any extension or 1.2 functions, opengl32.dll cannot redirect them for you. A workaround for this is to manually load them from the driver by using wglGetProcAddress.

This is why we cannot use 1.2 functions natively even though the driver supports 1.2. opengl32.dll must know how to redirect the function before we can use it like any other function.

And SGI's opengl.dll is not supported anymore, and is most likely not going to be supporting 1.2.

On the other hand, what's so difficult with using wglGetProcAddress? You just do the work yourself instead of letting opengl32.dll do it for you. And the extra work is hardly noticable, it just takes a minute or two to implement the code needed.

philippe
03-14-2001, 06:29 AM
You're basically right, it's not much an effort, but why I'm fed-up, is
1) because MS pretends to be 1.2 compliant
(with wlgGetProcAddress(), they could even pretend to be 5.4 compliant, since everything new could be loaded dynamically)
2) because OpenGL is supposed to be as portable as possible, and wglGetProcAddress is a(nother) way to make people stick to Windows.

Nutty
03-15-2001, 01:28 AM
Why can't companies like Nvidia, Matrox or ATI, get hold of OpenGL32.dll, and update it, and bundle it with their drivers? Surely this wouldn't be too hard to do?

Deiussum
03-15-2001, 06:37 AM
Originally posted by philippe:
You're basically right, it's not much an effort, but why I'm fed-up, is
1) because MS pretends to be 1.2 compliant
(with wlgGetProcAddress(), they could even pretend to be 5.4 compliant, since everything new could be loaded dynamically)


Where does MS claim that their default OpenGL32.dll is 1.2 compliant? When you get the default software renderer, it reports it's version as 1.1.



2) because OpenGL is supposed to be as portable as possible, and wglGetProcAddress is a(nother) way to make people stick to Windows.

Maybe I'm wrong, but isn't there a glXGetProcAddress? Are the Linux people trying to find a way to make people stick to Linux? wglGetProcAddress is not a way to make people stick with Windows. It is a way to allow people to get access to OpenGL extensions. Without it, you wouldn't be able to get extensions that aren't included in the 1.2 specs even. This type of function needs to be system specific, which is why it's a wgl function.

Don't get me wrong, I would love for MS to update their OpenGL32.dll to be 1.2 compliant, but seeing people spread this type of mis-information really annoys me.

mcraighead
03-15-2001, 08:09 AM
Originally posted by Nutty:
Why can't companies like Nvidia, Matrox or ATI, get hold of OpenGL32.dll, and update it, and bundle it with their drivers? Surely this wouldn't be too hard to do?


No, it would be impossible, because we don't have the source code. It would also enrage Microsoft beyond your wildest imaginations (modifying a system file that doesn't belong to us) and prevent us from getting WHQL. Finally, it would break features like Win2K OpenGL multimon for us to provide our own.

opengl32.dll is _supposed_ to be a Microsoft file.

- Matt

Nutty
03-15-2001, 09:59 AM
But there is an SGI version of that file, that seems to work just as well as microsofts. Is there not??

Perhaps SGI might make the source to that file available to hardware vendors??

Just a thought anyway...

Deiussum
03-15-2001, 10:09 AM
Isn't the SGI version opengl.dll, not opengl32.dll? And wouldn't you have to rename it to opengl32.dll in order for apps that are linked against opengl32.dll to use it? And wouldn't that then basically be replacing a system file, which would in turn piss off MS? http://www.opengl.org/discussion_boards/ubb/smile.gif

As much as we'd all like MS to update their opengl32.dll to 1.2, I think for now we are stuck with what we have and should just be glad that card manufacturers like Nvidia offer a way to get the 1.2 functions. Until MS does update it (and I feel confident that they will, eventually) we will just have to live with the minor inconvenience of using wglGetProcAddress.

mcraighead
03-15-2001, 02:45 PM
No, opengl.dll has absolutely nothing to do with opengl32.dll. opengl.dll was an aberration, something that really shouldn't have been done in the first place. If SGI wanted to ship a "faster" SW renderer they should have just implemented it as an ICD.

- Matt

pleopard
03-15-2001, 03:34 PM
Originally posted by Michail Bespalov:
use ... glext.h for definitions
So where the heck is glext.h?

I have Visual C++ Enterprise Edition and can't find that header anywhere in the VC++ file hierarchy.


[This message has been edited by pleopard (edited 03-15-2001).]

Michail Bespalov
03-16-2001, 12:09 AM
glext.h isn't distributed with MS VC.One of the places where you can find it is nvidia developer site.The newest glext.h is in the recently released SDK.