For the article source to build with VS 2005 Pro and Ogre3D 1.4RC1 SDK ...

... 5 items to be aware of

1) The project's additional include directories option originally reads:

"$(OGRE_HOME)\include";ois\includes

If you are experienced with VS change to your liking. In example, I changed mine to:

"$(OGRE_HOME)\include"

I then prefixed the OIS header references om the input.h file with "OIS\", e.g. "OIS\OISEvents.h". I did this for reasons two fold; 1) ois in the Ogre3D 1.4RC1 SDK does not have an "ois\includes" directory; 2) I personally prefer to have catagorized headers with their root directory names as prefixes.

2) VS 2005 does not allow implied return values so the line in main.cpp starting with "WINAPI WinMain" needs to be "int WINAPI WinMain"

3) In the Project Properties | Configuration Properties | General | Project Defaults

Set Common Language Runtime Support to use it (/clr) or you will get errors on application start as it tries to find MSVCP80D.dll. Microsoft knowledge-base has a convoluted method to build a manifest with dlls (as prompted by the VS2005 Express community) but this is much easier for just getting this sample to work in VS2005 Pro.

4) You may get a post build tool fault if you unzipped the source files somewhere with directory names with more than one "." or spaces. Just encase the $(TargetPath) with quotes, i.e. "$TargetPath" in the post build event command line option

5) Tips on avoiding problems with OIS input object creation with Ogre embedded in a MS MFC application
{(--psionprime 23:15, 12 March 2007 (CST)) Okay, OIS (as of 2007-03-12), per it's author and confirmed by me will not work with an embedded rendering window in MS XP. By embedded I mean if you create a boilerplate SDI application wizard app without doc/view option then attach the Ogre Window on creation to ChildView. I spent a few days researching it. I admit I haven't had to look at the messaging system in over a decade so it took a while to read up ;) pjcast, author of OIS, explained that the MS DirectX API requires a top level window.

 

I worked out what I need for the mouse and keyboard to be usable with an embedded renderer. I started off verifying that the Ogre rendering window does get messages. I used the VS tool Spy++. If Spy++ can get the messages, I knew I could too. The mouse messages reach the Ogre window but the keyboard ones do not. They do reach the ChildView to which the Ogre window is attached in my test app. Now, I just catch the messages at the top window and filter the ones for the mouse with the ogre window and another filter for the keyboard ones going to the ChildView window then forward them where they need to go. Very little code is involved. Put your filters in an overrode PreTranslateMessage at the application level or better spot to suit your needs. As I typed earlier, my knowledge is way rusty so something else may make more sense
}

If you get excited and try to run the resultant build from it's original directory you will get an error as it trys to locate the DeVIL.dll file ... which I *thought* was no longer part of Ogre3D. Interestingly enough, there is no problem starting the file from the Debug directory per the $(OGRE_HOME)\bin\ path which does not contain that .dll ;)

After tweaking up the configuration of the project in VS2005, by golly, you get an application with a blank window, which at the stage of the series, is exactly what you are supposed to get.

Happy Coding
--psionprime 17:57, 7 March 2007 (CST)

Bug in code!

Please not that is is actually necessary to create the window *before* you add resource groups. Otherwise the application crashes when loading shaders.

See this post: http://www.ogre3d.org/phpBB2/viewtopic.php?t=29659

Resource caveats I found RE: Bug in Code

I was focused on solving my input handling problem, and this is a tangent of the article as I made my test app use a resource config file anyway. What I forgot to mention that when I modified the sample resource.cfg to point to the sample media directory I had exceptions on initialization. I commented out the "BOOTSTRAP" section and no more problems. This was a minimal probelm I haven't look ed deeply into but I will say my test app does not create an ogre render window first.

I see I left in a resource declaration line just before initalizeAllResourceGroups that declared all the "General" group. That was just during my debug so I took it out rebuilt my test app before posting this. There are no problems and my sequence is practically the same as this article's with Ogre::Root->createRenderWindow definitely coming after the resource init code.

--psionprime 23:36, 12 March 2007 (CST)

Visual Studio 2005 SP1 + Localized (Italian) Windows Vista

I finally got the Practical Application up and running.

I went into problems with dxguid.lib... The linker didn't want to find it even if I have the DirectX SDK installed and any references in Visual Studio seem to be correct.

I worked out the problem changing the localized "C:\Programmi\Microsoft DirectX SDK (October 2006)\Lib\x86" to the "real" "C:\Program files\Microsoft DirectX SDK (October 2006)\Lib\x86" in the "Tools->Options->Project and Solutions->VC++ Directories->Library Files" setting of Visual Studio 2005. As far I can understand, It seems that the new implementation of localized folders in Vista it's not so compatible with Visual Studio...

Ok, that's all. I hope that this note will save somebody the time I spent on it.

Roberto

P.S. Thanks a lot for this tutorial/article. It's a good starting point for me...