Debugging ODN

This may not be the right place to post, but it seemed like a good place to start.

I am new to C# and VS 2005 Express, and the answer is probally more related to that than directly to ODN.

I have tried to debug the Particle FX Demo, just to start to get a feel for ODN and debugging in this IDE. And I can get it to start the debugger and step through some code. But at a certain point it dies with the following:

System.TypeInitializationException was unhandled
Message="The type initializer for 'OgreDotNet.OgreBindingsPINVOKE' threw an exception."
Source="OgreDotNet"
TypeName="OgreDotNet.OgreBindingsPINVOKE"
StackTrace:
at OgreDotNet.OgreBindingsPINVOKE.new_Root__SWIG_3()
at OgreDotNet.Root..ctor() in C:\SourceControl\ogreaddons\ogreaddons\ogredotnet\OgreNet\Root.cs:line 136
at OgreDotNet.ExampleApplication.Setup() in C:\SourceControl\ogreaddons\ogreaddons\ogredotnet\OgreNet\Custom\ExampleApplication.cs:line 69
at OgreDotNet.ExampleApplication.Start() in C:\SourceControl\ogreaddons\ogreaddons\ogredotnet\OgreNet\Custom\ExampleApplication.cs:line 56
at DemoParticleFX.ParticleFXApplication.Main(String[] args) in C:\SourceControl\ogreaddons\ogreaddons\ogredotnet\DemoParticleFX\ParticleFX.cs:line 89
at System.AppDomain.nExecuteAssembly(Assembly assembly, String[] args)
at System.AppDomain.ExecuteAssembly(String assemblyFile, Evidence assemblySecurity, String[] args)
at Microsoft.VisualStudio.HostingProcess.HostProc.RunUsersAssembly()
at System.Threading.ThreadHelper.ThreadStart_Context(Object state)
at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state)
at System.Threading.ThreadHelper.ThreadStart()

I think this is because the copy that is being used is the one that is built in the ...ogreaddons\ogredotnet... path. At least that is my guess. The wiki said to copy the files to the OGRE SDK path, which I have and it runs fine there outside of debugging. But I guess I don't see how it can know to run the one I copied. Is there a setting somewhere or am I completely off track?

here is what i do.
copy from ogresdk/bin/debug all the *.dll *.cfg to ogredotnet/bin/debug.
edit the resources.cfg and put in the full path for the media folder.
then in ODN projects properties/configureation properties/debuggin set the working directory to ogredotnet/bin/debug

Thanks for all the help. I really feel like I am making good progress.


However, I have another basic question. I tried debugging the Particle application by putting a break point into he Frame started method. Hitting it is not a problem. I expected I could step through it an the an would not see my updates until somewhere after returning from the method. But I pressed continue and came back around and hit the method again...as expected. But No updates in the OGRE rendering window. Even after removing the breakpoint and continuing I receive no updates in the rendering window. It is not until I actually switch back to the window that redraw takes place. I tried switching back to the window in between frames while debugging and nothing happens. While I would think it possible to debug code without seeing the results, it hardly seems optimal. I must be missing something.

I don't think you will be able to see update unless the render window has fucus while it is rendering inbetween FrameStart and FrameEnd.

What I mean is. I don’t think debugging this way is feasible. Just be glad you not using windows 2000, I do at work and the dx input system locks up my whole system if there is an error. I have to cut the power off because VS will not close when windows tell it to shut down. I don't remember all these problems working with c++, don’t remember actually trying to step though the render in c++ ether. But they may both be related to the .Net debugger and the fact that we are wrapping unmanaged code.

Just be glad you not using windows 2000, I do at work and the dx input system locks up my whole system if there is an error.
I use windows 2000 and I can't step into the application because of this issue. Are there any ideas how I can avoid this?

If you look at DemoCustomObjects, I left some of the test code there. I override ExampleApplication.CreateEventHandler and when I want to turn off the input system pass false as the last argument in the EventHandler constructor. The false will tell EventHandler not to create the input system and you still get the frame events

Then farther down (its commented out) I just had an Int that I increment to 500, and then return false to quit the demo. If you have a good GFX card and get more than 40 fps you should increase that 500 to let it run longer.