OGRE Wiki
Support and community documentation for Ogre3D
Ogre Forums
ogre3d.org
Log in
Username:
Password:
CapsLock is on.
Remember me (for 1 year)
Log in
Home
Tutorials
Tutorials Home
Basic Tutorials
Intermediate Tutorials
Mad Marx Tutorials
In Depth Tutorials
Older Tutorials
External Tutorials
Cookbook
Cookbook Home
CodeBank
Snippets
Experiences
Ogre Articles
Libraries
Libraries Home
Alternative Languages
Assembling A Toolset
Development Tools
OGRE Libraries
List of Libraries
Tools
Tools Home
DCC Tools
DCC Tutorials
DCC Articles
DCC Resources
Assembling a production pipeline
Development
Development Home
Roadmap
Building Ogre
Installing the Ogre SDK
Setting Up An Application
Ogre Wiki Tutorial Framework
Frequently Asked Questions
Google Summer Of Code
Help Requested
Ogre Core Articles
Community
Community Home
Projects Using Ogre
Recommended Reading
Contractors
Wiki
Immediate Wiki Tasklist
Wiki Ideas
Wiki Guidelines
Article Writing Guidelines
Wiki Styles
Wiki Page Tracker
Ogre Wiki Help
Ogre Wiki Help Overview
Help - Basic Syntax
Help - Images
Help - Pages and Structures
Help - Wiki Plugins
Toolbox
Freetags
Categories
List Pages
Structures
Trackers
Statistics
Rankings
List Galleries
Ogre Lexicon
Comments
History: Talk:Practical Application - Let's Get Started
View page
Source of version: 1
(current)
!!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 {(--((User:Psionprime|psionprime)) 23:15, 12 March 2007 (CST)) Okay, OIS (as of 2007-03-12), per it's [http://www.wreckedgames.com/forum/viewtopic.php?p=4214#4214|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. ~pp~ ~/pp~ 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 --((User:Psionprime|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. --((User:Psionprime|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...
Search by Tags
Search Wiki by Freetags
Latest Changes
IDE Eclipse
FMOD SoundManager
HDRlib
Building Ogre V2 with CMake
Ogre 2.1 FAQ
Minimal Ogre Collision
Artifex Terra
OpenMB
Advanced Mogre Framework
MogreSocks
...more
Search
Find
Advanced
Search Help
Online Users
51 online users