Microsoft's .NET (pronounced "dot net") language suite is a group of different languages that have syntax and structure differences, but whose executable code is essentially the same regardless of the language you are using.
.NET languages include the primary two: C# (C Sharp), and Visual Basic .NET (VB.NET). Other .NET languages include Delphi, Boo, ASP.NET, and more. For the most part, OgreDotNet is geared towards use with C# and VB.NET, however if you are wanting to use another language, there should be very few barriers to doing so. The only caveat is that the OgreDotNet team has likely not tested OgreDotNet with any other languages.
Table of contents
C# is an awesome language that builds on the lessons learned from C++ and Java. It builds and runs very quickly. It is perfectly adapted for OO development, providing a very concise, easy-to-maintain syntax. As a strongly typed language it is well suited for large projects where it is important to catch as many issues at compile time as possible.
VB.NET has a long and storied (and stained) history. VB.NET has a bad reputation because of its ancestors VB6, VB5, VB4, VBA (Visual Basic for Applications, used as a back-end for MS Access applications), etc. It's important to note that VB.NET is a major upgrade from the previous versions, so much so, there really is no comparison. VB is fully OO capable, while keeping the ease of programming, along with simple syntax and structure, that allows the user to program quickly and effectively with a much easier learning curve. Unfortunately, this shallow learning curve allows many people to try programming when they really don't know what they're doing, which has earned Visual Basic a reputation as being a "noobie" language. While it's true there are a lot of inexperienced (and even dreadfully BAD) VB programmers, that doesn't lessen the capabilities and power behind the language.
It's important to keep in mind that the "Common Language Runtime" engineered by Microsoft means that code written in C#, and identical code written in VB, both compile down to almost identical executable code! It's merely a matter of preference for syntax and style.
OgreDotNet is a "wrapper" for .NET languages to access the Ogre DLLs, which were written and compiled with C++. It does this using special "PINVOKE" calls that reach in to the Ogre DLLs to execute the various functions within Ogre. These PINVOKE calls take a miniscule (read: almost unnoticable) amount of program time to execute, but overall they DO cause a small (read: almost unnoticable) degradation in performance.
If you'd rather use another language, there are other wrappers available:
If you want to stick with C# or VB.NET and don't want to use a wrapper, there is another option available to you: The C# Port of Ogre (Axiom), which is now a part of the RealmForge project. Be warned, though, that ports have inherent pitfalls.
- Because a port requires the manual re-writing of code,
- There is an increased chance of bugs being introduced to what started as already-stable.
- It takes a long time to complete anything.
- If the original project (in this case: OGRE) releases an upgrade, the port project (Axiom) has to pick through the entire original project, look for changes, and update the port project. This means new updates take a long time to be released. Quite often, updates from the last release aren't complete before the next release is out, making a "perpetual update" situation, instead of continued work on finishing the project as a whole.
- Because of changes made to the methods and structure by the porting team, your support community is reduced to only those who are also using the port.
- OGRE makes extensive use of plugins. Plugins like the Paging Landscape Scene Manager also need to be ported for use with the ported version of OGRE.
Truthfully, the only reason for using a port is to avoid the very slight performance hit caused by a wrapper.
Using a wrapper for Ogre instead of a port has a few major benefits:
- A complete port from C++ to C# is a huge project requiring a complete rewrite of the code. A wrapper merely exposes the existing C++ code to C# and VB.NET.
- This means less chance of bugs being introduced
- We use a program called SWIG, which automatically does the code generation and wrapping, meaning changes and new OGRE functionality is almost immediately available, rather than having to wait for it to be ported over.
- The OGRE community is much larger and more capable of offering support.
- OGRE itself is more fully-featured than the Axiom port.
- Plugins don't care that the OGRE DLLs are wrapped, because they are loaded by the OgreDLLs themselves. Thus, there is no need to bother with porting, converting, or wrapping any of the plugins.
A good way to think of it is that instead of reinventing the wheel, we're taking an existing wheel and making an adapter for it to work with a different vehicle.
One disadvantage is that the wrapper introduces a layer between your application and the rendering engine that effects execution speed. The degree of performance degradation, however, is minimal to the point of being not even noticeable.
Another disadvantage is Swig's lack of director support with C# (Swig being the application used to generate the wrapper). Effectively this means that you cannot inherit classes from wrapped Ogre classes. You can do this if you want, but the OGRE class won't be able to call back into any functions overridden in the child class. For a select few classes, the intention is to manually code directors, but this is a long term goal.
If you are interested in participating in OgreDotNet discussions, would like to make suggestions, or otherwise help with the addon, please join the OgreDotNet Forum, which is a part of the Ogre Addons Forums.