The "best" OpenGL/.NET wrapper?

Started by
13 comments, last by Scourage 11 years, 6 months ago
Due to my limited experience with OpenGL, I'm still undecided on which .NET wrapper to use to implement OpenGL-specific portions of my engine. Basically, I'm looking for the SlimDX of the OpenGL world; if that makes any sense...

I'm wanting to know what could be considered the "best" OpenGL wrapper based on the following criteria:

  • Speed & memory efficiency
  • "Maturity"; insofar as mimimal bugs/errors and completion (exposes most OpenGL features)
  • Documentation, resources, help & samples/tutorials
  • Semantics, elegance, cleanliness and overall design
  • Interoperability
  • etc, etc...


I'm using SlimDX to implement DirectX support for the engine but need a worthy OpenGL counterpart for C#/.NET. Hopefully you guys can help me "see the light" and make an appropriate choice!

Regards,

ATC
_______________________________________________________________________________
CEO & Lead Developer at ATCWARE™
"Project X-1"; a 100% managed, platform-agnostic game & simulation engine

Please visit our new forums and help us test them and break the ice!
___________________________________________________________________________________
Advertisement
In my limited experience, I'd ditch the OpenGL and go for the library Terraria uses. Clearly it does something right.
As far as I know, there are only two viable choices, Tao and OpenTK. Recently I threw together a minimal 2D rendering backend using OpenTK, at the same time learning (modern-ish) OpenGL. Can't say I had any issues with the wrapper, although be aware there are newer nightly builds available.

I looked briefly at Tao, but it looked a bit too thin of wrapper for what I wanted, and doesn't look updated much anymore.

From the OpenTK homepage they claim it supports the latest versions of OpenGL, though I only used a small subset of OGL, and have so far only built/tested under Windows.
I've looked into OpenTK, but I dont think their SDK installer worked right for me, which doesn't bode well imho. :-/

Anyone know anything about SharpGL? It looks/sounds pretty good but as to how mature, complete, bugless and fast it is I dunno. And any other info/advice you can offer on the subject?
_______________________________________________________________________________
CEO & Lead Developer at ATCWARE™
"Project X-1"; a 100% managed, platform-agnostic game & simulation engine

Please visit our new forums and help us test them and break the ice!
___________________________________________________________________________________

I've looked into OpenTK, but I dont think their SDK installer worked right for me, which doesn't bode well imho. :-/


I never even knew there was an installer, I just downloaded the latest build zip here:http://sourceforge.n...opentk/nightly/ and referenced in OpenTK.dll.

I personally chose OTK since it was currently being used in production (e.g. Monogame), includes a fully featured math library, and had a relatively active community (compared to Tao).

I haven't looked into SharpGL, so I cannot compare to that.
Quick question about this. Probably a dumb question, because I've given it literally 3 seconds of thought:

Couldn't one just use p/Invoke to make calls directly into OpenGL32.dll? Seems like an ultra-thin wrapper of static methods could be made in this way, and you wouldn't need to wrap the whole thing -- just the gl functions that are needed, and one could add to it over time as the project progresses.

Quick question about this. Probably a dumb question, because I've given it literally 3 seconds of thought:

Couldn't one just use p/Invoke to make calls directly into OpenGL32.dll? Seems like an ultra-thin wrapper of static methods could be made in this way, and you wouldn't need to wrap the whole thing -- just the gl functions that are needed, and one could add to it over time as the project progresses.


Keep in mind that interop code can get a bit messy, needs to be done correctly to be performant, and you still do not have a math library (vectors, matrices), input & window management system for each native OS you want to support, and probably a multitude of other intricacies I don't know about. And, of course, you miss out on a system that has been tried and tested.

Not to say it wouldn't be an interesting excercise, or that such a system wouldn't fit the OP's purpose. I personally would not enjoy (i.e. probably would never finish) rolling my own wrapper.

Quick question about this. Probably a dumb question, because I've given it literally 3 seconds of thought:

Couldn't one just use p/Invoke to make calls directly into OpenGL32.dll? Seems like an ultra-thin wrapper of static methods could be made in this way, and you wouldn't need to wrap the whole thing -- just the gl functions that are needed, and one could add to it over time as the project progresses.


Laztrezort is pretty much spot on. Doing that is essentially proposing that you write an entirely NEW OpenGL wrapper, instead of using a tried and true one and working on your engine. You'd get so caught up developing a good OpenGL wrapper that you'd never have time for the engine, must less a game (SlimDX, for example, is a full-time affair for it's extremely talented and genius founders and developers)... Interop can be a very sophisticated subject, especially dealing with low-level graphics APIs, hardware and drivers, etc. I've written a few successful/working wrappers, the largest of which is a semi-complete wrapper for the Win32 APIs most important and low-level functions, and includes a customizable and extensible memory management system more conducive to game development than standard memory management by the Standard C Library and C++ runtime. It handles large amounts of frequent memory allocations and deallocations, unlike the standard malloc function and C++ constructors; it provides a new smart pointer system, customizable garbage collection, defragmentation (and compression), multi-threaded streaming and quite a few other things. It's nowhere near a commercial-grade product, but doing all of that took freakin forever... Speaking from experience you must be a very competent C, C++ and C# programmer to write a good wrapper; that's why those are the main three languages I know (excluding x86/64 [Intel Syntax] assembly language). I wanted to learn how to do that stuff and understand it, and it took considerable effort in learning those three languages to even begin. Even when you know what to do and know you can work it out, it's a long road and a monumental amount of labor to consider taking on. At some point I've gotta finish an engine and develop games with it. That's why I just wanna find a very nice, complete and stable OpenGL wrapper (as SlimDX is to DirectX) and get on with the show! smile.png


Keep in mind that interop code can get a bit messy, needs to be done correctly to be performant, and you still do not have a math library (vectors, matrices), input & window management system for each native OS you want to support, and probably a multitude of other intricacies I don't know about. And, of course, you miss out on a system that has been tried and tested.

Not to say it wouldn't be an interesting excercise, or that such a system wouldn't fit the OP's purpose. I personally would not enjoy (i.e. probably would never finish) rolling my own wrapper.


Correct. To remain platform-agnostic, I've implemented all of my own math, and vectors, matrices and everything else. My types are implicitly convertible with their SlimDX counterparts, and will be likewise with their OpenGL counterparts when I choose a wrapper to stick with. So that wouldn't be a huge problem. What would be a massive problem is all the performance testing and diagnostics, debugging, design, etc. I must admit I'd probably end up giving up and wishing I'd spent the time on something else.

It would certainly be interesting to just try wrapping the basic parts of OpenGL and rendering a small scene or "mini-tri" example. Would indeed let you learn a lot about OpenGL and interop, and become a better all-around programmer. I think writing a basic operating system is another such exercise all programmers can benefit from.
_______________________________________________________________________________
CEO & Lead Developer at ATCWARE™
"Project X-1"; a 100% managed, platform-agnostic game & simulation engine

Please visit our new forums and help us test them and break the ice!
___________________________________________________________________________________
Does anyone have any more information about this? I still haven't been satisfied enough to permanently select an OpenGL wrapper for my engine to support...

So far I'm getting that OpenTK and Tao both work well, but neither is especially good (perhaps I'm mistaken, but that's how it's sounded to me)... I really need something up-to-par with SlimDX, which is also up-to-date. If the developers aren't supporting a wrapper anymore it will leave a big, unwanted burden on me. So hopefully some more folks with experience with some OpenGL wrappers can give me further info/input???
_______________________________________________________________________________
CEO & Lead Developer at ATCWARE™
"Project X-1"; a 100% managed, platform-agnostic game & simulation engine

Please visit our new forums and help us test them and break the ice!
___________________________________________________________________________________
I'm using SlimDX and Tao in my engine. The reason I chose Tao is because it closely resembles the original syntax so I could easily port parts of my C++ engine over without too much grief. The good news is the OpenTK engine is backwards compatible with Tao so you can swap over to OpenTK later on and if you like change the syntax to be more .NET centric.

This topic is closed to new replies.

Advertisement