@Budman
I appreciate you taking the time to post the code sample, and again, your mention of TestCooperativeLevel() allowed me to simplify my surface lose logic, Thanks. :)
Unfortunately, even using your logic and after an hour+ more of debugging, using slight logic tweaks and command orderings, I am still able to get RenderWorld to MAV.
The issue is this: Even though a check is being performed JUST before RenderWorld is called, it is still possible from the time the check ends, until the time that RenderWorld completes, for B3D to lose focus, and during focus loss, lose surface memory, and thus cause RenderWorld to go boom.
I've tested this not only with my in-progress app, which consists of a few thousand lines of code, but also with sample apps that come with B3D. As @rthr mentioned, with smaller apps the MAV does not happen as often (probably because B3D is spending less time inside RenderWorld), but it still occurs.
RenderWorld has to be made sensitive to the fact that it can lose the Texture/Surface memory it is working with and respond accordingly. The only way to do that is to have internal access to RenderWorld. Thankfully, Mark seems keen to get this issue solved ...
David
I appreciate you taking the time to post the code sample, and again, your mention of TestCooperativeLevel() allowed me to simplify my surface lose logic, Thanks. :)
Unfortunately, even using your logic and after an hour+ more of debugging, using slight logic tweaks and command orderings, I am still able to get RenderWorld to MAV.
The issue is this: Even though a check is being performed JUST before RenderWorld is called, it is still possible from the time the check ends, until the time that RenderWorld completes, for B3D to lose focus, and during focus loss, lose surface memory, and thus cause RenderWorld to go boom.
I've tested this not only with my in-progress app, which consists of a few thousand lines of code, but also with sample apps that come with B3D. As @rthr mentioned, with smaller apps the MAV does not happen as often (probably because B3D is spending less time inside RenderWorld), but it still occurs.
RenderWorld has to be made sensitive to the fact that it can lose the Texture/Surface memory it is working with and respond accordingly. The only way to do that is to have internal access to RenderWorld. Thankfully, Mark seems keen to get this issue solved ...
David