hello
i’m wondering is it the better aproach to “glue” OpenGL rendering code to .NET Framework instead MFC Framework. i ask that question because i have introductory knowledge in MFC and i’ve found that .NET is really OO Framework…does anyone know how rendering context is applied to device context or some sort of that…
thanx
OpenGL in the .Net framework is ugly. There’s a third party library that is usually used, but just with my initial inspection of that library, it wasn’t readily apparent how to use it like I wanted to.
From what I’ve seen, OpenGL mind-bending under .net is a good excuse to avoid .net altogether and flee to an environment less hostile and/or locked-in.
Even Linux and especially Mac OS X are looking like a better place to invest in based simply on this ‘openness’ question.
.Net isn’t good for OpenGL, but that doesn’t mean it’s not good for other things. It’s just like anything else. You should use what’s appropriate for what you want.
is there no possibility to integrate opengl to .net like any other language
Ok, .NET for OpenGL is “ugly”, “mind-bending”, and “not good for OpenGL”…
Anyone care to elaborate why?
Does that mean it is impossible to use OpenGL in the .NET architecture or does it mean that the IDE sux and is difficult to work with related to OpenGL?
There are a couple of guys out there that can give you a dll to help you write OpenGL but good luck understanding it. My company has decided to wait on .Net until it is easier to use OpenGL (if ever)
Oh one more thing. In .Net you can write in any language and the pieces will work together. This is true, however I have studied all of the .Net languages and they are almost identical. There is no difference in C# J and VB. They look exactly alike. There is a slight difference in syntax. I like C# and being able to manually move controls on a form, I wish they supported OpenGL. I hate direct X and we will never go back to it.
[This message has been edited by John Jenkins (edited 10-18-2002).]
This topic has been discussed before, but here are my experiences trying to get OpenGL working with C#.
First thing I did was to figure out how to use the Win32 API functions in C#. It was easy enough, but you have to basically import every function you use, similar to the way you would in VB.
So I started out importing the Set/Describe/ChoosePixelFormat functions as well as the wgl functions wglCreateContext and wglMakeCurrent.
Then I tried to use them. I basically took some existing C++ code to initialize an OpenGL window, plopped it in, and modified a few lines of code so that it was calling my C# functions.
Everything worked fine right up until wglCreateContext. That would always fail. I tried pulling up the memory window, and compared the memory my PIXELFORMATDESCRIPTOR struct to make sure the C# struct wasn’t adding any sort of extra padding, but it was identical to my C++ PIXELFORMATDESCRIPTOR struct.
I tried doing a GetPixelFormat call right after the SetPixelFormat only to find out that the Get was NOT what I had just Set! I tried that in my C++ app just to make sure it wasn’t an API thing, but the C++ app returned what was expected. So, it appeared that SetPixelFormat was failing, but reporting back that it was succesful.
By now I was frustrated so I took a look at the source code for a .Net OpenGL library someone else had done. What I found out was that that library was actually calling out to a separate C++ DLL that did all the Pixelformat work!
My only conclusion is that there are some problems caused in the marshalling of the managed to unmanaged code.
So in conclusion, the best way to use OpenGL in .Net is to use a third party library. I believe it was called csgl on Sourceforge.net. And now when I go to look at that, it appears that it’s not quite what I was hoping for. All the example code seems to attempt to use something like a Document/View architecture. If there are nice simple classes to be used outside of that, I haven’t had the time to figure them out yet. 
[This message has been edited by Deiussum (edited 10-18-2002).]
I don’t remember the specifics, but DirectX 8 also has issues with .Net. The upcoming release of DirectX 9 will be more .Net friendly, however.
I haven’t tried .NET, so excuse my ignorance.
Deiussum wrote some weird story there but anyway, isnt it possible to do standard c++ coding in .NET
There is a packgage available called Visual C++ .NET
It should still be possible to compile your version 5 or 6 project under that, after it imports it.
I will continue using MFC for the time being until something seriously better comes up.
V-man
Originally posted by V-man:
[b]
I will continue using MFC for the time being until something seriously better comes up.
V-man[/b]
An API worth checking out is Qt by Trolltech (www.trolltech.com). OpenGL support is integrated. Also, the API is much cleaner than MFC (IMO) and it works on virtually any operating system.
Originally posted by josip:
An API worth checking out is Qt by Trolltech (www.trolltech.com). OpenGL support is integrated. Also, the API is much cleaner than MFC (IMO) and it works on virtually any operating system.
The linux version is freebut you have to license the windows version. There was one called wx something that seemed good (lost the link).
Anyway, Visual C++ .NET should work fine since it supports MFC.
V-man
Originally posted by V-man:
The linux version is freebut you have to license the windows version.
V-man
The linux version is only free for non-commercial purposes. There is a non-commercial binary version included for windows, just isn’t as up-to-date. But yeah, the commercial version isn’t free.
The wxWindows link is http://www.wxwindows.org/ Haven’t used it myself, but hear it’s pretty nice (and free all around).
Yes, VC++ .Net works fine with OpenGL, but generally when I think of the .Net framework I think of “managed code” in languges like C#. VC++ .Net has Managed code extensions for C++, but really I see little point in them.
Just using VC++ .Net doesn’t necessarily mean you are using the .Net framework itself. The same way using VC++ doesn’t mean you are using MFC. The .Net framework is more of a library of classes. I haven’t actually tried using these classes in C++, but I imagine it’s probably kind of ugly.
But then thinking of “managed C++” tends to make me shiver a bit. Maybe it’s just me, but I don’t generally like the idea of managed code. Managed C++ just seems to me that it would be taking my favorite language and adding on some of the things I don’t like about managed code.
Ok. Enough rambling…