PDA

View Full Version : c# wglGetProcAdress and OpenGL extensions



santyhamer
06-09-2003, 01:01 PM
How can I call an extension function ( like wglAllocateMemoryNV ) WITHOUT using an external C++ DLL or parser like CsGL?

I saw c# "delegates" to make function pointers... but I dont know if this is possible...

I know this is probably the MOST difficult ask you ever found...

SirKnight
06-09-2003, 01:18 PM
I'm pretty sure C# doesn't have direct support for OpenGL, it does Direct 3D though. http://www.opengl.org/discussion_boards/ubb/smile.gif So you will have to use a library some of kind. Or even mix languaged together like C# and managed c++. There is an article on codeproject.com that mixes C# with MFC with managed c++ for OpenGL rendering. It's found here: http://www.codeproject.com/csharp/csOpenGL.asp

Delegates are type-safe function pointers in C#.

-SirKnight

santyhamer
06-09-2003, 01:38 PM
"WITHOUT using an external C++ DLL or parser like CsGL", hehe

santyhamer
06-09-2003, 01:41 PM
btw, currently I have a full-funcitonal OpenGL class working in c#, but without the GL extensions like VAR, hp_occlusion_test ...

santyhamer
06-09-2003, 01:49 PM
Here is my idea... ( BUT doesnīt work, itīs only an "idea" ):

[CLSCompliantAttribute(false)]
unsafe protected delegate void* pwglAllocateMemoryNV(int size, float readFq, float writeFq, float priority);

[DllImport(OGLDLL),CLSCompliantAttribute(false)]protected static extern pwglAllocateMemoryNV wglGetProcAddress(string name);


pwglAllocateMemoryNV wglAllocateMemoryNV = new pwglAllocateMemoryNV(wglGetProcAddress("wglAllocateMemoryNV"));

this code is compiled, but generate a "Function pointer was not created by a Delegate" runtime exception.

Is there any chance to make a c# delegate with a (void*) pointer instead the void*(int,float,float,float). I tryed a simple cast, but cant compile...

santyhamer
06-09-2003, 03:47 PM
I really canīt explain why the extensions are called with a "call memorydirection obtained from wglGetProcAddress"... I think is better to export these functions directly from opengl32.dll... perhaps was a design error in the 199X years...

Hehe and why why why why why why have I to create BEFORE the RC to call wglGetProcAddress without fail????

DESIGN ERRORS!!

[This message has been edited by santyhammer (edited 06-10-2003).]

santyhamer
06-09-2003, 03:52 PM
Hey SGI, Java/c#/perl/VB users wanna make programs with OpenGL, so pls do something ... is it fair that we have to use a f..ing C++ DLL parser to use the openGL extensions? come on, thatīs not serious. 3th parties can die (look at lokiG), and then... what? SGI should move for ya! There are tons of other programming languages that arenīt C/C++ ... wrappers are evil, DLL hell is bad.

[This message has been edited by santyhammer (edited 06-10-2003).]

Korval
06-09-2003, 03:53 PM
That would have make extension writers beholden to Microsoft. Consider that they haven't upadted OpenGL32.dll, pretty much, since it came out. Would you like to still be stuck with GL 1.1?

This way, the interface to GL32.dll is constant, but extendable. Granted, it poses a problem for languages like C#, but you can get around this easily enough by building a Managed C++ project (maybe even an unmanaged one) that can get these function pointers for you.

Rog
06-09-2003, 10:59 PM
If it helps, there's a code snippet on the dotnet forums that shows how to use LoadLibrary and GetProcAddress from C# using a small piece of IL code. I haven't looked in much detail but you may be able to use a similar approach for wglGetProcAddress?

Here's the link -
http://groups.google.com/groups?hl=en&lr...SFTNGP10&rnum=4 (http://groups.google.com/groups?hl=en&lr=&ie=UTF-8&oe=UTF-8&selm=ueqNoUdtCHA.2540%40TK2MSFTNGP10&rnum=4)

http://www.opengl.org/discussion_boards/ubb/smile.gif

matt_weird
06-09-2003, 11:39 PM
Originally posted by santyhammer:
Hey SGI, Java/c#/perl/VB users wanna make programs with OpenGL, so pls do something ...

Not sure about extensions, but you can use OpenGL with VB through this typelibrary or either OCX:
http://is6.pacific.net.hk/~edx/contents.htm

I tried it some time ago, and... it doesn't seem to work better than C/C++ though... http://www.opengl.org/discussion_boards/ubb/rolleyes.gif



[This message has been edited by matt_weird (edited 06-10-2003).]

santyhamer
06-10-2003, 04:27 AM
I think the VB OCX doesnīt support advanced ogl1.4 extensions like NV_vertex_program2, NV_vertex_array_range2...

Rog, Iīll try the MSIL code. Looks like a good idea, thx.

[This message has been edited by santyhammer (edited 06-10-2003).]

knackered
06-10-2003, 05:13 AM
What's C# ? http://www.opengl.org/discussion_boards/ubb/smile.gif

santyhamer
06-10-2003, 06:32 AM
got it partially! I can call any method by using IL language. The question is.... how can I to call MSIL code inside c# without compiling a DLL outside my class? Can I do

public class myClass
{
protected bool Init()
{
DoSomething();
}

[useMSIL]
.method public static int32 wglAllocateMemoryNV ( native int pfn, int size, float rprio, float wprio, float prio )
{
ldarg.0 // push pfn
ldarg.1 // push size
ldarg.2 // push rprio
ldarg.3 // push wprio
ldarg.4 // push prio
calli unmanaged stdcall int32(int,float,float,float)
ret
}
}

???

How can I do a C++-style __asm in C# without invoking dynamically Reflection?


[This message has been edited by santyhammer (edited 06-10-2003).]

santyhamer
06-10-2003, 07:43 AM
Originally posted by knackered:
What's C# ? http://www.opengl.org/discussion_boards/ubb/smile.gif

C# is a VEEERY powerful programming language ( from Microsoft ). Looks like java, but itīs more powerful.

But pls, tell me how can I do a __asm(msil) in c#!!!!

[This message has been edited by santyhammer (edited 06-10-2003).]

matt_weird
06-10-2003, 08:11 AM
Originally posted by santyhammer:
I think the VB OCX doesnīt support advanced ogl1.4 extensions like NV_vertex_program2, NV_vertex_array_range2...


well, have you tried to email EDX, maybe he has some useful tips on it:

"Please send suggestions, bug reports, and such to: edx@pacific.net.hk"

santyhamer
06-10-2003, 09:23 AM
Well, I'll email him, but really dont wanna use an external DLL/OCX wrapper and enter the DLL hell, OCX registration, VB/MSV7 dll copy to system32... i waaaaaant a PURE c# solution ( if exists, hehe ).

[This message has been edited by santyhammer (edited 06-10-2003).]

[This message has been edited by santyhammer (edited 06-10-2003).]

matt_weird
06-10-2003, 08:39 PM
isn't this what are you looking for:

public string AssemblerListingLocation {get; set;}

santyhamer
06-11-2003, 05:10 AM
I think the AssemblerListingLocation is only for C/C++ tool... and not sure what is for, but looks like other thing than __asm(msil)...

matt_weird
06-11-2003, 07:16 AM
Originally posted by santyhammer:
I think the AssemblerListingLocation is only for C/C++ tool... and not sure what is for, but looks like other thing than __asm(msil)...

heh, this seems to be for creating the asm listing file during the code compiling, so now i see it's really not what you was looking for http://www.opengl.org/discussion_boards/ubb/smile.gif

so it seems the only way to use asm in C# -- is to write a DLL(or whatever else you can connect to C# written in C/C++) wrapper incapsulating the inline assembler inside of it =) http://www.opengl.org/discussion_boards/ubb/rolleyes.gif (The same goes to OpenGL http://www.opengl.org/discussion_boards/ubb/wink.gif )

Korval
06-11-2003, 09:13 AM
C# is a VEEERY powerful programming language ( from Microsoft ). Looks like java, but itīs more powerful.

Or, put in a less enthusiastic, but more accurate, way, C# is a Java-like language that compiles to the .NET interpreter. As such, it has full access to all of the services provided by various .NET objects. The language itself is very similar to Java; what makes it a nice (Windows-specific) alternative is that it can be extended much easier than Java. Writing a .NET object is trivial compared to writing C/C++ extensions to Java.


i waaaaaant a PURE c# solution ( if exists, hehe ).

You do realize that, by now, you could have written a .NET object that provides access to all the extension functions you need? This is not a difficult undertaking.

And no, there is no pure C# solution; the language isn't designed to handle this kind of thing.

SirKnight
06-11-2003, 04:19 PM
Actually it's not windows specific anymore. There exists C# compilers for linux and even a .NET linux framework. I forget what it's called and even how they did it http://www.opengl.org/discussion_boards/ubb/biggrin.gif, but it's nice to see that a .NET application can run on more than just windows now.

-SirKnight

santyhamer
06-11-2003, 04:28 PM
Well finally, decided to make a DLL with C to load the NVidia extensions like NV_vertex_array_range2, wglWllocateMemory... perhaps c# is not prepared to manage correctly wglGetProcAddress.

Ridge
06-12-2003, 08:42 PM
You were fairly close...

First of all, I'm highly suspect of anyone who goes off and starts yet another .NET binding. There's already way too many and none of them offer anything that hasn't already been done before. CsGL, while it has some oddities is much further along than the others... The latest instance of CsGL, which is called Tao and is produced and hosted by me corrects the issues that've plagued CsGL for a number of versions... It'd be much more productive if people contributed rather than starting anew, but to each his own...

The most simple solution to extensions and the one I'm using is to define a custom attribute that contains the IL to invoke the extension. On the post-process compilation event it's trivial to have a utility parse out the IL and inject it into your assembly. No need for external assemblies, no need for unmanaged code. I'm already doing the post-processing step to inject cdecl delegate calls as that too is something not supported by c#, but is supported by IL, so to me, this is the most trivial solution. Other options would be to use Reflection.Emit to inject the IL at runtime, but to me that's extraneous... Obviously you could also use an unmanaged or managed component to do the work.

Anywho, stay tuned for the next release of Tao.

Ridge
06-12-2003, 09:11 PM
I guess I should reply to the rest of the thread as well... The solution I mentioned is of course IL and not C# and would require a post-processing step to inject the IL into your assembly. I agree it'd be nice if you could do it in C# or using inline IL, but neither is available. This doesn't mean that it can't be done in a managed fashion as it is supported by IL. So it's somewhat of an extraneous step, but it can be completely automated and it won't affect your deployment (e.g. you can just modify your own assembly). I guess I should give a little example:

[CustomIL IL="
ldarg.1 // push foo
ldarg.0 // push extensionPointer
calli unmanaged stdcall void(float32)
ret
"]
public static void glFogCoordfEXT(IntPtr extensionPointer, Single foo) {}

So your application call would look something like:
glFogCoordfEXT(wglGetProcAddress("glFogCoordfEXT"), 1.0f);

You'd likely want to cache the extension's pointer however...

That's off the top of my head, so please excuse... So, the CustomIL attribute is parsed post-build, the IL is injected into the appropriate method for me automagically using an external utility. It's the closest thing we've got to inline IL with the exception of Reflection.Emit...

I've yet to find any need to rely on unmanaged components outside of what's being wrapped. In CsGL there is an unmanaged component that does a number of things, including invoking extensions. If I recall correctly, Lloyd's parser parsed the extension headers to write the c# that invoked the unmanaged component. In the case of Tao there are no extraneous unmanaged components, everything's either in C# using P/Invoke, or in the cases of extensions and cdecl delegates injected IL that's put in by a post-build utility.

In the Whidbey release, IL will be able to be compiled into your assembly, making this 'hack' a non-issue. I don't believe it'll be inline IL, but you will be able to combine IL compiled with ILASM into your assembly. Hopefully they'll add cdecl delegates too and that would completely get rid of my post-build event.

Mono is the main alternative .NET platform. Tao has been reported to run under linux (mono), freebsd (mono), and windows (microsoft and mono) using the same code. In these cases the programs were GLUT based, it would be fairly trivial to add GLX support, but I don't run either linux or freebsd, so it's not real high on my priority list.

I think that covers about everything...


[This message has been edited by Ridge (edited 06-12-2003).]

[This message has been edited by Ridge (edited 06-12-2003).]

santyhamer
06-15-2003, 10:27 AM
Oh, thx! iīll try that.