Hehe, I will.
Certainly a lot of fun to play with.
Should be making a post in the personal projects section with a small game I'm working on with it soon. :o)
According to Ohloh code metrics, OpenTK currently comprises of 86176 lines of code, although between all contributed patches, samples and not-commited features, it is closer to 90000.
This site is running on Drupal, using a version of the Hunchbaque theme heavily modified by a miserably inept web programmer (that's me). Despite the lean looks, www.opentk.com consumed 1.9GB of bandwidth during February.
There has been some discussion in the #mono channel recently about whether we would create or endorse a gaming API developed by a third party. Like blessing Tao or OpenTK as the standard way of building games for Mono.
What are actually the options? Mono.XNA had more not-implemented-exceptions than working code last time I've taken a look. SDL.Net?
I think the download count sited above is artifically low, I switched to pulling from the SVN repository shortly after the last 0.3.x release.
I experimented with Tao.OpenGl and "C# Wrapper for OpenGL : Version 11" from http://colinfahey.com/csharp_wrapper_opengl_windows/csharp_wrapper_for_o..., both projects could have worked in our development, however OpenTK even in the early 0.3.x releases exhibited a more .Net kindly framework that really resonated with our development practises.
The 0.9.0 release and the helpful coaching plus a couple quick fixes provided by Fiddler and others on this forum continue to validate the decision to utilize OpenTK.
Agreed, Tao is solid but really low level. Not everyone's flavor. It's good to know though that Tao bindings work nicely together with OpenTK: e.g. you can use OpenTK for context&message handling and code graphics with Tao.OpenGL
There's a couple more OpenGL wrappers out there for .Net, but most appear to be abandoned due to the upcoming GL3.
OpenGL is a great cross platform low level API, but it takes a lot of work to make an efficient game or application with it.
There are some rendering engines out there that are either C# or have C# bindings.
Ogre3D seems to be a well thought out rendering engine written in C++. MORGE is a C# wrapper for Ogre3D. It seems pretty nice but I do not know it it would work under LINUX since I think they put special code in the C++ MOgre libraries.
AxiomEngine is a cross platform C# engine that is a port of the Ogre3D engine. I do not know how mature it is though.
The nice thing about these engines is that they optimize the loading of models and handle materials and shaders for you. There are a lot of tricks to fast rendering, from using the proper hardware buffers to sorting the rendering of objects by state and texture. They also support advanced materials, shaders, shadows, and scene culling. These engines do it for you.
I have been wondering of late if a pure C# rendering engine such as the axiom engine which has to call an unmanaged API like OpenGL or a managed wrapper like MOgre that calls the unmanaged orge3D API which can directly access the OpenGL API would be more efficient. Since calling from managed to unmanaged code requires a pInvoke which does have overhead, a question is which one would have fewer pInvokes?
My initial gut feeling is that the MOgre wrapper may be faster, but there are tricks both APIs could make.
I experimented with Ogre3d at my last job, at the time the C# wrapper was not available, I was trying to take a game engine and pound it into an engineering application. We successfully demonstrated a prototype that was abandond by management.
My son has followed the Axiom crowd and development around for several years, my impression is that there was a loss of focus awhile back and the new team is intent on taking Axiom to XBox. If I remember right my son did have a version of Axiom running on his Gentoo laptop using Mono, but it was a very difficult process.
There's no doubt that using a game engine is easier than using OpenGL directly (if it isn't, there's something terribly wrong with the engine). On the other hand, engines tend to restrict you to a specific set of features; move outside that set, and things start to get more difficult, ugly and/or hackish. From my experience, .Net bindings on top of a C++ application tend to be less usable than a fully managed solution (problems inheriting from objects, C++ conventions leaking into managed code etc).
OpenTK does not aim to be a 3d engine. It's not a game-development library either (how many gamedev libraries can handle multiple monitors and multiple contexts cleanly?) It could be classified as a low-level multimedia library with a focus on usability, which makes it suitable for a wide range of applications: from games to engines and 3d modelling/visualisation software. It does try to simplify OpenGL development in the managed world, to the extent that this is possible (OpenGL is a complex beast) - OpenGL 3 will hopefully take this a step further.
I have been wondering of late if a pure C# rendering engine such as the axiom engine which has to call an unmanaged API like OpenGL or a managed wrapper like MOgre that calls the unmanaged orge3D API which can directly access the OpenGL API would be more efficient. Since calling from managed to unmanaged code requires a pInvoke which does have overhead, a question is which one would have fewer pInvokes?
On my machine (Core 2 @2.66GHz), a straight function call consumes about 1.5ns. A simple pinvoke costs about 8.5ns on Mono/Linux x64. For non-trivial applications like MOgre and Axiom, the p/invoke overhead will be insignificant compared to memory management, state batching and other high-level optimizations.
The one place where pinvoke overhead *does* matter are math functions - depending on how complex the function is, it might make sense to pinvoke hand-optimized native code, rather than perform the calculations in managed code. For simpler functions however, pure managed code will be faster than a pinvoke, so even this is not a clear-cut case. A relatively recent benchmark:
Machine: Core 2 Duo E6600 clocked at 3.0GHz
Managed XNA - Matrix.Multiply(ref,ref,out): 557ms
Managed w/ P/Invoke to SSE2 function: 341ms
Native C++ - Full Compiler Optimizations: 300ms
Native C++ - hand-optimized SSE2: 138ms
I'm quite sure that for 2D applications the overhead is absolutely neglectible.
Regarding 3D: according to Microsoft's keynote the performance of Marble Blast's XNA version is "in striking distance" to it's C++ counterpart, and they built the whole engine in 3 weeks. (!) (<- Don't overlook the !)
Tom Miller's book "Beginning 3D Game Programming" claims the difference to be 7%, according to MSDN forums.
Imo it's also important to consider what sacrifices you're willing to make for performance. Without doubt, developing with .Net is by far more fun and productive than working with C. Importing optimized unmanaged functions to a managed environment is only a half-hearted solution, if you're a speed-junkie then you'll have to eat the sour apple and stick with C/Assembler, or use a stock engine.
It's also much about the level of programming you like to do. If you want quick results and scripting is most you want to do, take a look at a commercial engine (like Unreal 3, which runs on more platforms than you have fingers) which are usually very highly optimized and mature. None of the homebrew engines can compete with commercial solutions for game creation, and those packages usually also include alot of tools that help speeding up the development process aswell.
You can start developing your game as a Mod ontop of those engines, and acquire a license if you intend to go commercial with it at some point. Or use the previous iteration of their engines, which come with full source code and are - by far - cheaper.
Just trying to give an objective analysis of the Wrapper vs. Engine problem. (as objective as I can possibly be, with my choices made)
Edit: Forgot to comment on the 'benchmark'. C compilers have been under development for over 3 decades now and obviously had alot of smart people doing optimizations. Net is rather young and the mentioned 7% will more likely move towards 5% than 10% in the coming years. The overhead differences between Mono and Net already show that there's room for improvement.
OpenTK has been very useful for me. I've allways like the way .Net works and OpenTK does exactly what I need. The fact that this is still a growing community and there are still active updates on it makes me feel like I made a good choice with this.
Kudos to Fiddler, Inertia and any other people who helped make this happen. :)
I'll also be posting my game in the Personal Projects section quite soon, it's coming along nicely.
Comments
Feb 29
17:19:26Re: Hooray for OpenTK!
posted by MincusHehe, I will.
Certainly a lot of fun to play with.
Should be making a post in the personal projects section with a small game I'm working on with it soon. :o)
Feb 29
17:36:39Re: Hooray for OpenTK!
posted by InertiaIndeed, we should write a gregorian chant in order to worship Fiddler appropriately :)
Feb 29
20:53:51Re: Hooray for OpenTK!
posted by athiniarGreat job indeed master Fiddler!
Congrats to Inertia too for his work on openAL!
Feb 29
21:11:00Re: Hooray for OpenTK!
posted by the FiddlerThanks for your kind words, I guess... :)
Though when I hear about chants, I start to think about Oracle DBAs and their cabalistic ways. :P
Edit: Ok, since we are in the self, err, congratulation mode right now, a few interesting tidbits:
Feb 29
21:43:00Re: Hooray for OpenTK!
posted by InertiaThat explains the delay of 0.9.1, refreshing statistics every 5 minutes and enter the results into charts consumes quite some time 'we' guess.
2GB traffic is quite a bit, are you hosting a secret pr0n site on this server 'we' haven't found yet?
Feb 29
22:06:34Re: Hooray for OpenTK!
posted by the FiddlerYeah, that takes quite a bit of time. Not that I, err, do that or something...
Feb 29
22:59:40Re: Hooray for OpenTK!
posted by InertiaThere has been some discussion in the #mono channel recently about whether we would create or endorse a gaming API developed by a third party. Like blessing Tao or OpenTK as the standard way of building games for Mono.
What are actually the options? Mono.XNA had more not-implemented-exceptions than working code last time I've taken a look. SDL.Net?
Feb 29
23:12:52Re: Hooray for OpenTK!
posted by the FiddlerAs far as I know these are the cross-platform options: Tao, OpenTK, SDL.Net, and... that's it.
Feb 29
02:42:31Re: Hooray for OpenTK!
posted by djkI think the download count sited above is artifically low, I switched to pulling from the SVN repository shortly after the last 0.3.x release.
I experimented with Tao.OpenGl and "C# Wrapper for OpenGL : Version 11" from http://colinfahey.com/csharp_wrapper_opengl_windows/csharp_wrapper_for_o..., both projects could have worked in our development, however OpenTK even in the early 0.3.x releases exhibited a more .Net kindly framework that really resonated with our development practises.
The 0.9.0 release and the helpful coaching plus a couple quick fixes provided by Fiddler and others on this forum continue to validate the decision to utilize OpenTK.
Mar 01
15:52:22Re: Hooray for OpenTK!
posted by InertiaAgreed, Tao is solid but really low level. Not everyone's flavor. It's good to know though that Tao bindings work nicely together with OpenTK: e.g. you can use OpenTK for context&message handling and code graphics with Tao.OpenGL
There's a couple more OpenGL wrappers out there for .Net, but most appear to be abandoned due to the upcoming GL3.
Mar 01
19:39:29Re: Hooray for OpenTK!
posted by JTaltonOpenGL is a great cross platform low level API, but it takes a lot of work to make an efficient game or application with it.
There are some rendering engines out there that are either C# or have C# bindings.
Ogre3D seems to be a well thought out rendering engine written in C++.
MORGE is a C# wrapper for Ogre3D. It seems pretty nice but I do not know it it would work under LINUX since I think they put special code in the C++ MOgre libraries.
AxiomEngine is a cross platform C# engine that is a port of the Ogre3D engine. I do not know how mature it is though.
The nice thing about these engines is that they optimize the loading of models and handle materials and shaders for you. There are a lot of tricks to fast rendering, from using the proper hardware buffers to sorting the rendering of objects by state and texture. They also support advanced materials, shaders, shadows, and scene culling. These engines do it for you.
I have been wondering of late if a pure C# rendering engine such as the axiom engine which has to call an unmanaged API like OpenGL or a managed wrapper like MOgre that calls the unmanaged orge3D API which can directly access the OpenGL API would be more efficient. Since calling from managed to unmanaged code requires a pInvoke which does have overhead, a question is which one would have fewer pInvokes?
My initial gut feeling is that the MOgre wrapper may be faster, but there are tricks both APIs could make.
Mar 01
23:25:23Re: Hooray for OpenTK!
posted by djkI experimented with Ogre3d at my last job, at the time the C# wrapper was not available, I was trying to take a game engine and pound it into an engineering application. We successfully demonstrated a prototype that was abandond by management.
My son has followed the Axiom crowd and development around for several years, my impression is that there was a loss of focus awhile back and the new team is intent on taking Axiom to XBox. If I remember right my son did have a version of Axiom running on his Gentoo laptop using Mono, but it was a very difficult process.
Mar 01
02:19:36Re: Hooray for OpenTK!
posted by the FiddlerThere's no doubt that using a game engine is easier than using OpenGL directly (if it isn't, there's something terribly wrong with the engine). On the other hand, engines tend to restrict you to a specific set of features; move outside that set, and things start to get more difficult, ugly and/or hackish. From my experience, .Net bindings on top of a C++ application tend to be less usable than a fully managed solution (problems inheriting from objects, C++ conventions leaking into managed code etc).
OpenTK does not aim to be a 3d engine. It's not a game-development library either (how many gamedev libraries can handle multiple monitors and multiple contexts cleanly?) It could be classified as a low-level multimedia library with a focus on usability, which makes it suitable for a wide range of applications: from games to engines and 3d modelling/visualisation software. It does try to simplify OpenGL development in the managed world, to the extent that this is possible (OpenGL is a complex beast) - OpenGL 3 will hopefully take this a step further.
I have been wondering of late if a pure C# rendering engine such as the axiom engine which has to call an unmanaged API like OpenGL or a managed wrapper like MOgre that calls the unmanaged orge3D API which can directly access the OpenGL API would be more efficient. Since calling from managed to unmanaged code requires a pInvoke which does have overhead, a question is which one would have fewer pInvokes?
On my machine (Core 2 @2.66GHz), a straight function call consumes about 1.5ns. A simple pinvoke costs about 8.5ns on Mono/Linux x64. For non-trivial applications like MOgre and Axiom, the p/invoke overhead will be insignificant compared to memory management, state batching and other high-level optimizations.
The one place where pinvoke overhead *does* matter are math functions - depending on how complex the function is, it might make sense to pinvoke hand-optimized native code, rather than perform the calculations in managed code. For simpler functions however, pure managed code will be faster than a pinvoke, so even this is not a clear-cut case. A relatively recent benchmark:
Managed XNA - Matrix.Multiply(ref,ref,out): 557ms
Managed w/ P/Invoke to SSE2 function: 341ms
Native C++ - Full Compiler Optimizations: 300ms
Native C++ - hand-optimized SSE2: 138ms
Mar 02
13:24:00Re: Hooray for OpenTK!
posted by InertiaI'm quite sure that for 2D applications the overhead is absolutely neglectible.
Regarding 3D: according to Microsoft's keynote the performance of Marble Blast's XNA version is "in striking distance" to it's C++ counterpart, and they built the whole engine in 3 weeks. (!) (<- Don't overlook the !)
Tom Miller's book "Beginning 3D Game Programming" claims the difference to be 7%, according to MSDN forums.
Imo it's also important to consider what sacrifices you're willing to make for performance. Without doubt, developing with .Net is by far more fun and productive than working with C. Importing optimized unmanaged functions to a managed environment is only a half-hearted solution, if you're a speed-junkie then you'll have to eat the sour apple and stick with C/Assembler, or use a stock engine.
It's also much about the level of programming you like to do. If you want quick results and scripting is most you want to do, take a look at a commercial engine (like Unreal 3, which runs on more platforms than you have fingers) which are usually very highly optimized and mature. None of the homebrew engines can compete with commercial solutions for game creation, and those packages usually also include alot of tools that help speeding up the development process aswell.
You can start developing your game as a Mod ontop of those engines, and acquire a license if you intend to go commercial with it at some point. Or use the previous iteration of their engines, which come with full source code and are - by far - cheaper.
Just trying to give an objective analysis of the Wrapper vs. Engine problem. (as objective as I can possibly be, with my choices made)
Edit: Forgot to comment on the 'benchmark'. C compilers have been under development for over 3 decades now and obviously had alot of smart people doing optimizations. Net is rather young and the mentioned 7% will more likely move towards 5% than 10% in the coming years. The overhead differences between Mono and Net already show that there's room for improvement.
Mar 02
22:20:10Re: Hooray for OpenTK!
posted by DatriotOpenTK has been very useful for me. I've allways like the way .Net works and OpenTK does exactly what I need. The fact that this is still a growing community and there are still active updates on it makes me feel like I made a good choice with this.
Kudos to Fiddler, Inertia and any other people who helped make this happen. :)
I'll also be posting my game in the Personal Projects section quite soon, it's coming along nicely.
Mar 09
17:01:01Re: Hooray for OpenTK!
posted by InertiaThe discussions OpenGL vs. DirectX, unmanaged vs. managed and Wrapper vs. Engine are all obsolete now. Everyone was wrong.