Have you tryed to use Ogl with c#/vb.net or Java? All is fine until you need an extension, because these languages CANT use the wglGetProcAdress EASY ( need an intermediate DLL or something strange, look csGL for example… ) to access the extensions…
I think there are enough ppl that uses these languages to consider it and pls, dont call c# microsofer or something cuz go-mono is c# and is Linux based…
thx.
[This message has been edited by santyhammer (edited 02-28-2004).]
Extensions have to be wrapped for these languages. Though the process is a little more involved than for C, Perl, Ruby, python or Tcl. (C the wrapping is done by creating a wrapper pointer function, and calling wgl/glX GetProcAddress). The other 4 have easy ways to transcribe the glext.h file into an appropriate source file.
In JAVA, create a method using the the native modifier, and writing a simple C program that acesses the extension. In C#, start a Managed C++ project and used managed extensions to access the extension.
VB is a little harder, since eveything has to be marshalled every which way, and arrays tend to be difficult.
Aye I know we need to create a wrapper for these lenguages… that I wanna propose is to skip these wrappers ( or SGI pls make wrappers, not us ) hehe. Look at Managed DirectX…
btw, look like Intel is making a C/C++ library to (FINALLY OMG) use the OpenGL>1.1 and to overwrite the Microsoft’s DLL. See http://oss.sgi.com/projects/ogl-sample/GLsdk.zip … the question is… why Intel and no SGI omg???
[This message has been edited by santyhammer (edited 03-03-2004).]
>>>why Intel and no SGI<<<
Intel is one of the main ARB members and are active on GL support.
They have previously released an ext loading lib.
And also, there is no DLL for overwriting the standard opengl32.dll
It’s code to avoid having to call wglGetProcAddress and having function pointers.
So you can code normally, except you must make sure the feature is present.
glprocs.h and glprocs.c
[QUOTE]
use the OpenGL>1.1 and to overwrite the Microsoft’s DLL
[\QUOTE]
[QUOTE]
And also, there is no DLL for overwriting the standard opengl32.dll
[\QUOTE]
Usually, your driver overwrites that file, “opengl.dll”, so getting a dll that supports recent opengl versions is easy. But without a corresponding “opengl32.lib”, you can’t access those functions without going through the extension mechanism.
If you want direct OpenGL 1.2+ support, you need to change that file, “opengl32.lib”. But once you have done that, you’ve violated the terms of your license agreement, and by that agreement you must remove Windows or reinstall it without the modification. All libs (see the IE fiasco, of a few years ago) are considered private and essential to the continuing working of Windows. Which makes it necessary to get approval of any changes. (in effect, impossible, since it in no way behoves or benefits the owners of a rival API to support newer versions.)
SGI and other companies have not created an updated “opengl32.lib” because it violates their vendor license agreement, or one of those agreements. I’d have to check as I have one of those agreements around here somewhere. In short, thou shalt not change the OS without approval. A few companies have created OpenGL compatible libs, but they either floundered or were bought outright before the projects could be completed.
So in short very possible, and probably very illegal. (Go to Hong Kong for a weekend, write the code, and distribute it. I think it’s Hong Kong. There’s about 10 countries where we don’t have treaties that enforce the software licenses. And then you might want to move someplace without an extradition treaty with the US.)
Just for clarification : Your driver install will NOT overwrite Opengl32.dll… the Windows model is that you call Opengl32.dll and that will forward the call to the appropriate dll (atioglxx.dll for ati, nvoglnt.dll for nvidia). thats why you cannot use another opengl.lib file since none of the new functionpointers actually exist in opengl32.dll until MS upgrades that.
That’s correct.
Opengl32.dll is a windows system file and noone can overwrite it. Plus there is the issue of the GL ICD, which MS owns and noone is allowed to reverse engineer it, nor implement it in any form.
opengl.dll? Probably the same issue apply there because it implements the ICD mechanism as well.
lib files are not related to the OS.
chemdog is confused.
(Many of the characters in this post are unrpintable, and probably filtered out).
The lib file contains the IMPORT_DESCRIPTOR for the dll. Without which, the program cannot access the dll except by direct address binding.
The lib contains “__NULL_IMPORT_DESCRIPTOR”, “OPENGL32.dll/ 991200382 0 281” which is both a description of the dll, and how to intialize it on loading. The lib contains a static function “__imp__glBegin@4”, which is where the application call to glBegin is bound. In the lib, the call is marshalled as “_glBegin@4”, “OPENGL32.dll”, “OPENGL32.dll/ 91200382 0 44”, which contains all the necessary information to find the correct dll and to find the bind address of the call.
If no-one can overwrite the opengl32.dll and associated properties, then no-one can change where the dll call will go. By default, the opengl32.dll with its mostly software renderer(which uses DDRAW.dll). I cannot find the exact mechanism that my NVIDIA driver uses to change the way opengl32.dll works; I suspect nv4_disp.sys loads it and overwrites the dll in memory(and if so, then the other version’s bind points are accessible if the lib is changed).
In short, if you don’t change the lib you cannot extend what the dll provides, and if you don’t change the dll then all calls go to the software renderer.
As far as reverse engineering, you can legally reverse engineer anything for compatibility purposes. The biggest case in memory was regarding a cartridge lock-out system, which the reverse-engineers won, but then gave up the rights to settle their trademark violation. (Though I’m sure MS has cleverly encoded trademarks into their ICD.)
Well… all I can say is that this is “Future ogl suggestions”… so let’s change the current -stupid- opengl32.dll method for other method and that’s all, isn’t it?
If you drop the dll, then you’d probably have to make the C-bindings into a real (and re-entrant) library. Real libraries are orthogonal(not coupled to other components(like the windowing system)) components that provide context creation (the ability to utilize multiple instances concurrently and across threads, and occasionally processes)).
Changes would be so drastic as to be a major version change.
Need to add the ability to manage a library context, which is passed (usually as the first parameter) to every method invocation. Windowing systems would need a way to bind a libcontext into what is currently a GLcontext. The change would eliminate the globals associated with the current context.
[ul][li] GL_LibraryContext* glCreateContext(/versioning?/)[] void glDeleteContext(GL_LibraryContext)[] boolean wglGLLibraryContextBindToControl(HANDLE control, GL_LibraryContext);[] same for agl, pgl, glX[/ul][/li]
All the regular glCalls would take an additional argument
[ul][li] void glBegin(GL_LibraryContext);[] void glEnd(GL_LibraryContext);[*] ecetera[/ul][/li]
The library would need to be made reentrant, which providing a library context facilitates the majority of that.
Returns from Error, and GetString, would need to point to unchanging memory locations.(Some implementations have glError returning the address of a global buffer, which is overwritten on every error. So if you were to call glError and get ErrorA and store the string pointer into a variable errstring, then if you continued and caused another error, the contents at errstring would be changed).
A few other changes and clean-up, but the cost is a little run-time efficiency. Since every function call now has a check for a valid context. Whereas before, all contexts were valid since they were controlled by the OS, (which would set a default context, so that all contextes were valid, eliminating the check). Among the benefits, is being able to use GL across threads, and signifigantly easier porting. As GL moves toward program-based rendering, the overhead of a few context checks will be mitigated.
The dll problem might also just be swept under the rug so to speak. Moving it to the OS’s problem instead of the application developers. The contexts used above, might still have to use the dlls, to find the functions and extensions.
So who’s with me, we can make a real library out of GL. Look at AL, it’s a real library(well it wasn’t completely re-entrant but that could have been fixed), just an abandoned one.
Real libraries are orthogonal(not coupled to other components(like the windowing system))
OpenGL implementations need to talk to windowing components, let alone the hardware itself.
What you’re talking about is some kind of wrapper around the library. Which we, effectively, have with the ICD mechanism. You set your context, and all GL commands go to that context. Set a different context, and GL commands go to that one instead.
I don’t really see the benifit in what you’re proposing, or anything that actually helps GL support non-C/C++ languages.
If you’re wanting to use extensions from a .NET language you should use Tao.OpenGl/Tao.Platform.Windows. You can use wglGetProcAddress similarly to how you might use it in C/C++ without any extraneous unmanaged dlls. I guess you missed the enormous yellow box on the CsGL page which mentions this.
http://www.randyridge.com/Tao/Default.aspx
I dont like 3rd party wrappers( why use a wrapper if I can do my own in Managed C++, bah )… err… I know i am very stupid, but cant download Tao’s source code… I am not good with Vault service(???) ( is that a thing like CVS? ) Cant program a serious thing with that really… Imagine it dissapears like csgl in the middle of a project… Imagine they change his license…
I think I should do my own OGL wrapper…
I use .NET 2.0 beta for whedbey…
I have CLS-compliant problems with other libraries…
I dont like to pay ( in general, not for Tao ) 3rd party solutions…
I dont like to use Cg because doesn’t support well ATI products…
I need ogl1.5 support…
But the question is… why openGL supports Java(look j3d or ARB meeting “java issues”)and not c#/vb/delphi/etc too? Not supporting these other highly-demanded languages directly makes ogl as fool as Microsoft not supporting ogl … why the hell should I do a wrapper omg? Come on SGI, Intel, etc etc… support DIRECTLY other languages pls… or I will pass to DirectX/XNA… It is a market thing… directx is EATING ogl… and supports his other languages ( ok I know are m’s languages and blah blah )… but if I program in , for example, c# … I will choose the 3D API that better fits this language… If i have to decide between a direct-support API like MDX … and other that requires 3rd party/build you own LAAAARGE wrapper … I, sincerely, prefer mdx…
so… resuming, come on OGL, WAKE UP!!!
ps: no, i am not a microsofer… just saying what millions of .NET programmers think about the current ogl implementation… ogl2 should DO anything at this respect… OGL arb or whatever, must do a high-performance ogl library for .NET … hit Microsoft in the point more can suffer… atk .NET with a SGI ogl library! :eek:
Originally posted by santyhammer:
But the question is… why openGL supports Java(look j3d or ARB meeting “java issues”)and not c#/vb/delphi/etc too?
OpenGL doesn’t have to “support a language”, the language just needs to be able to make calls to a C API. The community already provides headers/wrappers/bindings for pretty much every programming language that is capable of doing so. If you don’t want to use these bindings, it’s your loss.
The OpenGL API has to remain at the lowest common denominator level to ensure that it can be called from as many programming languages as possible. Hence, if a certain language has “features” that make it harder to interface with a C API (e.g. the absence of pointers in Java), then you need a wrapper.
I don’t see how you would propose to remedy this situation. By creating an “official” wrapper? Who would maintain it, then? I’m sure the ARB members have better things to do than maintaining code that could just as well be maintained by volunteers.
– Tom
Go ahead and try to roll your own wrapper, see how long it takes you. Vault is a source control solution similar to CVS. The source is freely available and licensed under the BSD license. I am the author/maintainer.
All of this is covered on my site in great detail, apparently you haven’t done your research. I suggest asking on my forums if you have .NET specific questions.
As other people have noted, this is not an issue for OpenGL 2. Language bindings aren’t something that needs to be maintained by the ARB.
Great work Ridge, Tao rocks. Now I want it for delphi/VB6 pls!
And btw Tom… I think Microsoft’s “ARB” members are not as lazy as OpenGL “ARB” members writing wrappers… That’s why ppl started to use DX… DX can be called by C/C++/Dephi/VB6/C#/VB.NET/j#/Python/Perl/COM without breaking ANY “denominator” premisae…
In the ogl official web there is a "what do you want for the ogl 2x blah blah release? " I will say “better wrappers and better opengl32.dll/crap dead-C thing” hehe… But well, if you dont think this is a ogl2 issue, well… I have very clrear that if ogl2 doesn’t include wrappers for the languages I am using, I will /kick ogl and /kiss dx ( hard to say, but as I said, is a MARKET-OFFER war )
Originally posted by santyhammer:
And btw Tom… I think Microsoft’s “ARB” members are not as lazy as OpenGL “ARB” members writing wrappers… That’s why ppl started to use DX… DX can be called by C/C++/Dephi/VB6/C#/VB.NET/j#/Python/Perl/COM without breaking ANY “denominator” premisae…
Whatever you say, buddy.
Last time I checked, interfacing with DirectX from any environment that wasn’t designed by Microsoft still required you to use non-official bindings. The bindings that ship with the SDK only work with (AFAIK) Microsoft Visual Studio products. And that’s without mentioning support for non-Windows operating systems.
DirectX works out of the box IF you run a Microsoft OS and use Microsoft development tools. If you don’t, you’re still in the same boat as you would be when using OpenGL.
– Tom
/quote
DirectX works out of the box IF you run a Microsoft OS and use Microsoft development tools. If you don’t, you’re still in the same boat as you would be when using OpenGL
/quote
No way. Have you heard about Managed DirectX and .NET, older COM dx8 lib or even J3D dx version ( this is a very interesting case, cuz Sun developed an “official” OGL/dx wrapper for Java… as you can see OGL is the [ONLY] lazy writing “official wrappers…” ).
Sorry but I use Borland .NET ( including delphi.NET ) and go-mono compiler under Linux and WinE SDK and with WinXP… Have you seen Everquest’s client running in Linux? It works perfectly
Portability is [NOT] only the capacity to transport your code to other OS… is [TOO] the facility to port your code into other languages… OGL “just” achieves the first premise… And that’s why the evil Microsoft designed the CLS-compliant .NET. In fact, you can port any .NET language to other .NET CLS-compatible language just pressing the reverse enginering button in Visio or VS… or use a .NET component… then shutdown Windows and use your component in go-mono under Linux ( look csVorbis for example if you dont trust me ).
The [OLD] C-portability paradign was broken with Java and .NET…
This thread is too full of misinformation , but let’s assume your .NET code can be use out of the box on other platforms, compilers, and OSs.
If .NET becomes popular, it’s probably best to have these wrappers ready to use.
In fact, better have them ready now.
[B} That’s why ppl started to use DX… DX can be called by C/C++/Dephi/VB6/C#/VB.NET/j#/Python/Perl/COM without breaking ANY “denominator” premisae…[/b]
Many games are still done in C/C++.
IMO, people use DX cause it’s a full package for making games. Of course, I have seen commercial games using GL, AL and beeing DXless, but the industry is focused on MS products.
And as for Java, it’s getting attention on mobile phones.
dont call c# microsofer or something
Just to comment on that, the C# language was and is being developed by Microsoft along with the .NET Framework regardless of if mono, or dotGNU supports C# to an extent.