I have no idea why, but it seems like it's impossible for plsm2 to run in debug mode without problems as soon you go farther than just using getOption
while no problem in release, lots of stuff cause problems in debug mode.
-OpenGL doesn't work
-the Options object contains only garbage
-plsmSceneManager->getPageManager() results in a assertation failure. it seems in the debugger, that mPageManager is invalid
it is the same with plsm2 demo app, so i guess it's not because of my debug configuration.
I do not expect replies, this is intended as kinda warning for other users who might find this via search function: if you use debug mode, and plsm2 doesn't work, it is most probably not your fault. Try debugging in release, logging variables can help :/
I run in debug mode (and use the debugger) all the time without issues. This sounds like a confusion about object sizes between DLLs. The main Ogre library doesn't know what PLSM is, and treats it as a SceneManager (which it is).
yay! finally something what sounds like it could help^^
do you know what I can do about it? I use Ogre from SDK, should I compile it myself with some special options?
There is no need to rebuild everything, although it helps if one wants source-level debugging of library code.
Start with the unmodified demo program and set breakpoints / examine variables in that. Once you have convinced yourself that the debugger works correctly you can start to track down real bugs.
well, I tried to cast the scenemanager to paginglandscapescenemanager in the demo, and then do ->getPageManager, same result.
I also noticed this: if I put a breakpoint in plsm2 code, it will be hit while debugging in release mode, but not in debug mode.
I put it in plsmSceneManager's InitScene, it should be called on construction.
It sounds like you are using a modified demo, not the stock demo, which makes it hard to judge the breakpoint situation. It sounds like the pdb files don't match the source, in this case I think a complete debug rebuild would be a good place to start. Before trying to modify the demo, you need to get past this belief that breakpoints don't work in PLSM. I can write about my setting/hitting breakpoints all day long, but it doesn't do you any good until you can do it.
It is a little annoying when people jump to the conclusion that Ogre/PLSM doesn't work when they are the only one to experience a problem. Please try to frame your questions with that in mind.
As for the pointer casting problem, all I can say is that I have cast the FrameListener's mScnMgr member to an OctreeSceneManager and was able to use the pointer. Where one does this casting is probably more important than how. So for my part, in FrameStarted() I had added the
code:
PagingLandScapeOctreeSceneManager *osm = (PagingLandScapeOctreeSceneManager *) mScnMgr;
...
bool is_done = false;
osm -> getOption ("dumpDone", &is_done);
Things I would watch out for are using a pointer before it has been initialized, and casting to the wrong types.
sorry
i was a litte upset after I couldn't make it work. I'll try not to behave like a n00b now^^
well, my demo is from CVS, and rebuilding it has no effect...
I casted the pointer in my pageLoaded function, and there was an error if I did plsmSceneManager->getPageManager. I looked in the code, and it was some part saying assert(mPageManager). I thought plsm2 needs this page manager to actually work and what it's constructed on the scenemanager's creation.
maybe I have to rebuild plsm2 itself, too?
Off the top of my head it sounds like plsmSceneManager is a bad pointer. Unfortunately I'm not likely to have time to look into this for a bit, but I think that pageLoaded() is enough information to try to reproduce.
The problem is involved, but Visual Studio must be confused about pointer types.
Rant: it is a BAD BAD BAD practice to put executable code in .h files. Now there are times when (due to templates) this needs to be done. And I don't mind short inline code being in a .h file, but huge chunks of code are in these headers and don't need to be. This isn't the first time I've come up against this sort of problem in PLSM unfortunately. But changing the code with PLSM3 hopefully around the corner seems a waste of time.
So, when an issue like this comes up it becomes easy to point the finger. Looking at this in the debugger:
As you can see, the breakpoint is in pageLoaded, and mPageManager has a correct value. What isn't shown is the address of the scene manager 0x00caf498, which is pointing to a valid PagingLandScapeSceneManager.
I was able to drill-down the tree-control and browse data just fine. The type of mSceneMgr is SceneMgr*, but the debugger knows the true type.
If, in code, one casts mSceneMgr (0x00caf498) to a PagingLandScapeSceneManager via dynamic_cast<>, the cast completes successfully but the debugger shows bogus values in the tree control. **this is the same address at the same time**. I was able to switch back and forth between the cast pointer and the base pointer and could see no difference other than how the pointer was interpreted. The typecast structure seems to be ignoring the vtable, even though it is the same chunk of memory, and memory is shifted into the wrong members.
Maybe someone else can see how to correctly access those members.
Unfortunately I cannot/will not spend hours dealing with this nonsense
The kludgy work-around I suggest is to add an a section to PLSM's getOption and pull the pointer that way. Thankfully a call to getOption gets routed to the correct code.
And the debugger works just fine with PLSM, as seen by the screenshot.
I do not understand most of it, but i think i got the idea...
I also wanted to add a getOption, should I submit a patch?