About current extension mechanism

I usually program in c# a lot… and I have a problem… ( the same that csGL )… In Windows, if I wanna access to the extension mechanish, I must call wglGetProcAdress , make a function to a pointer and call the funcion… This is ok in C/C++ … but in c# ( I think vs .net too ) I can’t call directly to a “function pointer”… so my advice is… why I must call wglGetProcAdress? why not better to “export” the OGL extension directly in the Opengl32.dll so I can use directly the DllImport attribute? Or said in other way(in w32asm)… why not to make directly the extensions functions EXPORTS like, for example, glVertex?

[This message has been edited by santyhammer (edited 01-26-2004).]

This is a polymorphism and versioning problem.

On Windows (and any other multitasking capable OS for that matter), there can be multiple OpenGL applications running, each in their separate windows, on different physical display devices (both graphics cards and monitors), with different pixel formats.

There absolutely needs to be a ‘glue’ to bind this to the operating system, so that the gl calls can be dispatched to the correct implementation, i.e. the one that drives the monitor where the context is visible.

Or to offer a more serious issue, what happens to a window that spans two monitors, each driven by a different graphics card (maybe even based on different chips from different manufacturers)?

So you see, there is no “the” GL implementation. As such there is no way around the glue that selects the correct one. Even if you use a single monitor and a single graphics card, there are still cases where a software fallback is necessary (when the pixel format can’t be accelerated, eg stencil buffering in 16 bpp on a Geforce 2MX or something).

This glue is Opengl32.dll, provided by Microsoft, and it’s been in hiatus for a hundred years or so. This is the cause of all our pain, because it’s stuck at a prehistoric GL version and as such can neither offer entry points for GL1.5 functions, nor can it act as a software rendering fallback for GL1.5.

However, replacing it isn’t as easy as it may seem, because it touches OS turf (window positions, screen modes, hardware enumeration).

Don’t get me wrong, it would be great if there was a major update to this DLL. But IMO - to keep it clean - it must be sanctioned by Microsoft if it happens, and this just isn’t going to happen. You’d better learn your way around this sooner rather than later.

Originally posted by santyhammer:
I usually program in c# a lot… and I have a problem…

start C# bashing rant
Well this isn’t a suprise since C# is weird.
C# sound’s like a pure M$ construct(like com, .net and DX).
D is much better(allthough i wouldn’t know im a c++ guy myself).
end C# bashing rant

What do you have against COM? I find the mecahnism nice…

Yes it’s nice, about as nice as teabagging a cactus.
Seriously, DX is based on COM, and once when i tried to do one little measly thing in direct sound, i allmost ended up in having to reformat my computer.
COM is decent in theory, but it’s still a twisted M$ construct.
Besides, COM is not that portable to other system’s.

SGI should do something about that prehistoric openGL32… they have knowledge about Windows DDK, architecture etc cuz they implemented Java on IE, worked with windows, graphics, WMQ, DirectX(for J3D)… come on SGI, renew the Opengl32.dll WITHOUT M$ consent!!! And if this is not possible, just think about other OpenGL mechanism ( for example, a static .LIB, an ActiveX/.NEt component for Windows or something ). I feel soo abandoned by M$ and SGI in Windows… 8( Pl notice we are talinking about a FUTURE ogl version, so all this considerations should be taken in mind… Listen us… IS NOT EASY ( for non-C++ programmers ) TO USE OGL EXTENSIONS!!!

[This message has been edited by santyhammer (edited 01-29-2004).]