History: Troubleshooting

Source of version: 19 (current)

{BOX(width="100%",class="Layout_box9")}
{SPLIT(colsize=10%|70%)}
{IMG(src="img/wiki_up/Libraries.png", imalign="left", link="Troubleshooting",title="Troubleshooting")}{IMG}
---
{DIV(class="bigBold")}((Troubleshooting)){DIV}
This section includes various troubleshooting information related to setting up an application.
{SPLIT}
{BOX}

!Setting the Working Directory
Ogre expects certain files to be in the same directory as the executable. If we do not set the working directory for our IDE to the location of these files, then it won't see that they exist because it expects them to be in the working directory. So we must make sure to get our working directory set up correctly.
!!Visual Studio
The exact solution will vary based on which version of Visual Studio you are using, but the basic steps should be similar. Right click on your project in the solution explorer (not the solution itself), and go to the properties. Somewhere in the configuration properties should be options for "Debugging". Then look for a field called "Working Directory". This should be set to the location of your executable file.

If you are having trouble figuring out what to put there, try to mimic the "Command" field, which should be in the debugging options. For example, in Visual C++ 2003, the "Command" field should be something like "..\..\bin\$(ConfigurationName)\$(TargetFileName)". For the Working Directory, we need to remove the TargetFileName part. In this case, the working directory would be "..\..\bin\$(ConfigurationName)". The exact string you have to put there ''may'' vary based on your version of Visual C++ and your build environment. Be sure to check what the Command field is before doing this. Make sure to change the Working Directory for both the Release and Debug configuration.

In Visual C++ 2005 it will probably be something different entirely. I've found the "..\..\bin\$(ConfigurationName)" directory a good thing to try first, if it still does not work you may have to play with it some, or get help on the Ogre forums.
!!Code::Blocks
Right click in your project and select "Properties...", now go to "Build Targets", then change the field "Execution working dir:" to the directory where your executable resides.
!!Eclipse
Right click on your project and select "Run as->Run Configurations...". Then select the Run configuration for your project, and go to the "Arguments" tab. You need to change the Working Directory here. I've found the "${workspace_loc:Minemonics/dist/bin}" directory works, but otherwise just play around with it a bit. The working directory should be the location of the binary and the configuration (*.cnf) files or, if kept separately, the location of the configuration files. The binary is already selected in the "Main" tab.
!MessageBox Unicode Error
If you are using Visual Studio with unicode support turned on, then you may encounter this error:
{CODE(wrap="1", colors="c++")}  
error C2664: 'MessageBoxW' : cannot convert parameter 2 from 'const char *' to 'LPCWSTR'
Types pointed to are unrelated; conversion requires reinterpret_cast, C-style cast or  function-style cast
{CODE}
The problem is that the MessageBox function is expecting unicode input, and we are giving it an ANSI string. To fix this, find the following line:
{CODE(wrap="1", colors="c++")}  
MessageBox(NULL, e.what(), "An exception has occurred!", MB_OK | MB_IConerror | MB_TASKMODAL);
{CODE}
And change it to this:
{CODE(wrap="1", colors="c++")}
MessageBoxA(NULL, e.what(), "An exception has occurred!", MB_OK | MB_IConerror | MB_TASKMODAL);
{CODE}
We are now calling MessageBoxA instead of MessageBox. The reason for this is that MessageBox is automatically either resolved to MessageBoxA (ANSI) or MessageBoxW (Wide/Unicode), depending on the project configuration. We fix the error by explicitly calling the ANSI function.
!Missing DLLs or Configuration Files
If your application has missings DLLs or .cfg files, then you probably need to copy them over from the OgreSDK folder.

In Visual Studio, when you build your application in release mode, it puts the release executable in the '\bin\release' folder and the debug executable in the '\bin\debug' folder. You must copy all of the DLL and .cfg files from the OgreSDK into the appropriate folders. You would copy the files from '[[OgreSDK]\bin\release' into '\bin\release' in your project. You will also need to edit the resources.cfg file to point to the correct paths. See the next section for more information on this.
!Problems With Resources Or Plugins
First, make sure you have 'plugins.cfg' and 'resources.cfg' in the same directory as your executable. The 'plugins.cfg' file tells Ogre which rendering libraries are available (Direct3D9, OpenGL, etc.). The 'resources.cfg' file is used to specify the locations of textures, meshes, scripts, and other resources. Both are simple text files. Open them up and make sure they contain the correct paths. Otherwise, you might get errors that look something like this:
{CODE(wrap="1", colors="c++")} 
Description: ../../Media/packs/OgreCore.zip - error whilst opening archive: Unable to read zip file
{CODE}
If this is the case, then open up 'resources.cfg' and correct the paths and make sure the resource actually exists. Note: You can't use environment variables such as ${OGRE_HOME} in these paths.
!Assertion About 'ms_singleton'
Quite often, the singleton assert caused by trying to run Debug DLLs with code linked against Release libs, or vice versa. It may not be your actual linkage either. In ''plugins.cfg'' (or the equivalent programmatic method) if you specify Debug plugins and you are running Release code (or vice versa) this will happen when the opposite DLL build type is loaded.

For example, your program links against ''OgreMain.lib'' (release) but you are referencing, say ''ParticleFX_d.dll'' (debug). When ''ParticleFX_d.dll'' is loaded, it will load in turn ''OgreMain_d.dll'' (which is what IT was linked against), and then you have a problem. This is one of the reasons it always happens in the Singleton code: Two of something exist for a class that should only have one instance. Instant assert.

The [http://www.dependencywalker.com|Dependency Walker] tool (Win32 only -- Linux users can use the ''ldd'' command) is an invaluable aid in determining which modules your libraries and executables are using, and can sometimes turn up unexpected dependencies. Note that running this with your program will not scan the plugins, since they are not compile-time linked to the program; you'll need to run it for each plugin as well.

Make sure you are referencing the correct plugins, either in ''plugins.cfg'' (when using that method) or in your code when loading plugins via code. In your project files in ((-VisualStudio)), make sure you are linking against the intended import libraries (.lib files), Ogre marks its Debug builds with a ''_D'' suffix on its DLL filenames.
---
Alias: (alias(TroubleshootingFAQ))
History: Troubleshooting

Source of version: 19 (current)

Search by Tags

Latest Changes

Search

Online Users
