Mogre FAQ
From Ogre Wiki
Contents
|
Using
Why do some classes have the '_NativePtr' postfix ?
These are not classes but structs; they offer better performance and put no pressure on the managed heap. They are mainly used for simple Ogre classes that are like C structs (they don't form inheritance chains and they mostly contain data). .NET structs are fundamentally different than classes and are used differently, so '_NativePtr' is appended so you can clearly distinguish them.
_NativePtr structs contain and pass around only the native pointer to the Ogre object. The guidelines for using them are:
- Instantiation - When you 'new' a struct it's members get their default values, thus when you new a _NativePtr struct you get a null native pointer. In order to create an Ogre object you have to call the static Create method:
LayerBlendModeEx_NativePtr lbm_null = new LayerBlendModeEx_NativePtr(); // This returns a null native pointer LayerBlendModeEx_NativePtr lbm_obj = LayerBlendModeEx_NativePtr.Create(); // This creates the Ogre object and returns a pointer to it
- Comparing - If you want to compare whether two _NativePtr objects refer to the same Ogre object use the Equals method. Note that _NativePtr structs override the Equals method and the '==' operator if the Ogre class overrides the '==' operator:
LayerBlendModeEx_NativePtr lbm1 = LayerBlendModeEx_NativePtr.Create(); LayerBlendModeEx_NativePtr lbm2 = LayerBlendModeEx_NativePtr.Create(); bool areEqual1 = lbm1.NativePtr == lbm2.NativePtr; // They point to different objects, returns false bool areEqual2 = lbm1.Equals(lbm2); // Ogre::LayerBlendModeEx overrides '==' to compare the values, returns true bool areEqual3 = lbm1 == lbm2; // You can use '==' instead of Equals, returns true
- Destroying - If you create a _NativePtr object, you must call the DestroyNativePtr when you are finished with it, in order to delete the native Ogre object, otherwise there will be a memory leak (you can track memory leaks by using the debug Mogre.dll and checking 'OgreLeaks.log')
lbm1.DestroyNativePtr(); // Delete the Ogre object
Why do some classes have the 'Const_' prefix ?
This is only for classes that wrap STL containers (vector, list etc.). C++ uses the 'const' keyword to indicate that a parameter will not be modified by the method, or that the returned value should not be modified by the calling code. C# and VB.NET doesn't have a similar mechanism so, to avoid breaking the method 'contract', when a Ogre method accepts/returns a const STL container, the equivelant Mogre method accepts/returns a read-only 'Const_' STL wrapper class. The conversion from the normal STL wrapper to the Const_ one is implicit:
NameValuePairList list = new NameValuePairList(); Const_NameValuePairList const_list = list; // Implicit conversion
Note: This implicit conversion doesn't work for VB.NET (probably a VB.NET bug). Use the ReadOnlyInstance property instead:
Dim const_list As Const_NameValuePairList = list.ReadOnlyInstance
I see a Renderable class and a IRenderable interface, isn't only one of them enough ?
Classes that are used with multiple inheritance by Ogre are converted to interfaces. For example, if there is an Ogre method that accepts/returns a Ogre::Renderable object, it will accept/return a Mogre.IRenderable when converted for Mogre. So when dealing with Ogre objects/methods you will use the interface.
But if you want to create a custom class that implements the interface, you can't just add it to the class definition; you will implement it on the .NET side but it won't be usable by Ogre. For these cases there is a class that you should derive from if you want to implement the interface. For example, in order to implement IRenderable, you should subclass the Renderable class.
Troubleshooting
I'm getting a FileLoadException when I try to run a Mogre app on another machine
MOGRE is built using Visual Studio 8 SP1, so it requires the VC SP1 libraries. You need to install the SP1 vcredist_x86 on the target machine. (Note: vcredist_x86 installs only the release libraries, so only the release binaries of Mogre will work.) Also, take a look at this post.
Why do I get a crash when I dispose Root ?
- If you are getting a crash only when using the OpenGL renderer and not with the Direct3D renderer, make sure that you are not disposing Root inside a finalizer. GL requires that it gets disposed by the same thread that created it, and finalizers run in a different thread than the main one.
- All SharedPtr objects (MaterialPtr, TexturePtr, GpuProgramPtr etc.) must be out of scope before disposing Root, so make sure that you clear all references of SharedPtr objects before the call (i.e. set your SharedPtr variables to null).
I get a crash, how can I see the line and the call stack ?
- Copy the 'OgreMain_d.pdb' file from 'C:\OgreSDK\lib' to your executable's debug directory (i.e. 'C:\OgreSDK\bin\debug')
- Go to your project's properties -> Debug and under 'Debug' Configuration check 'Enable unmanaged code debugging'.
- Debug your project and when the crash happens you should be able to see the call stack. If you download Mogre's source code you'll be able to select the source file to see what line is causing it.
- Note that to get the full stack trace, you must be linked to Mogre_d.dll in your .NET project (and the _d versions of any Mogre DLLs you link to), and in turn for that to work you must make sure your plugins.cfg refers to the _d versions of all the plugin DLLs. If you have done all of the above, you should be able to get a stack trace all the way into Ogre C++ code.
I get a System.BadImageFormatException within a 64-bit enviroment, what's wrong ?
The MOGRE assemblies are platform-specific and therefore generate some strange errors if you build them with standard Visual Studio settings within an 64-bit enviroment. You can force your application (eg. the samples) to run in WOW64 by going to the project properties in VS, select the "build" tab, and set the "platform target" to x86. (Info provided by Lightbringer)
Set your system so that it uses the 32bit CLR by-default (use this if the previous tip is not working)
If running in a 64bits Windows system, you can try to set your system so that it uses the 32bit CLR by-default. You can do this by calling:
- Open a Command Prompt window with Administration rights
- "C:\WINDOWS\Microsoft.NET\Framework64\v2.0.50727\Ldr64.exe setwow"
- try to run your MOGRE app
Working in Windows 7 64bits RTM.
