Jump to content

  • Log In with Google      Sign In   
  • Create Account


#ActualStakFallT

Posted 27 September 2013 - 07:51 PM

Well I have D3D's debug settings cranked to full on everything I could find in the DirectX control pane; I have the runtime set to debug in the project settings, l think there's even a preprocessor I have set for d3d debugging and most things that do error, do display in the output window, so while I'm not completely sure every d3d call is having the returning HRESULT checked, I'm very confident that anything that does error will be displayed. So far the only things I really see are redundant states being set, and that's just a matter of finalizing my render state manager to check for previously set state values so it doesn't set them again. And none of the states should cause something like a texture splatted right up against the camera lens like that. As far as PIX goes, yeah I tried that at a couple of points when I was implementing my shader managers. Apparently, at least I think it might be, VMware (I know... I know... don't say it wink.png    -- I don't have easy access to a pure windows machine; at least not one I trust a unreleased engine app on) doesn't behave well with it or something; everytime I tried PIX I ran into a problem. I think, trying to recall the problem from memory, it would hang the app and yield no results and then keep it open and then at that point when I would give up on PIX and go back to just static analysis, I would try some stuff and then go to run it again in MSVC and that would then error since the app executable was still open from a PIX hangup, and trying to close it in task manager didn't close it.

 

I'm using MSVC 2008, and running on an ATI card, so built-in vs2012 stuff and NSight unfortunately aren't possible options... I'm thinking the answer is some high level answer, like "Oh you didn't set the projection (Or the view) matrix equal to <blah>" or something as I think if there was something seriously wrong, I wouldn't even get a texture, or worse yet, the thing would just crash. Just I'm not seeing it in the code... and too many days, accumulated time, of looking over the code causes one to get tunnel vision as far as scrutiny over the logic in each of the routines.


#1StakFallT

Posted 27 September 2013 - 07:46 PM

Well I have D3D's debug settings cranked to full on everything I could find in the DirectX control panel, and most things that do error, do display in the output window, so while I'm not completely sure ever d3d call is having the returning hresult checked, I'm very confident that anything that does error will be displayed. So far the only things I really see are redundant states being set, and that's just a matter of finalizing my render state manager to check for previously set state values so it doesn't set them again. And none of the states should cause something like a texture splatted right up against the camera lens like that. As far as PIX goes, yeah I tried that at a couple of points when I was implementing my shader managers, apparently, at least I think it might be, VMware (I know... I know... don't say it wink.png    -- I don't have easy access to a pure windows machine; at least not one I trust a unreleased engine app on) doesn't behave well with it or something; everytime I tried PIX I ran into a problem. I think, trying to recall the problem from memory, it would hang the app and yield no results and then keep it open and then giving up on PIX and going back to just static analysis, I would go to run it again in MSVC and that would then error since the app executable was still open, and trying to close it in task manager didn't close it.

 

I'm using MSVC 2008, and running on an ATI card, so 2012 and NSight unfortunately aren't possible options... I'm thinking the answer is some high level answer, like "Oh you didn't set the projection matrix equal to <blah>" or something as I think if there were something seriously wrong, I wouldn't even get a texture, or worse yet, the thing would crash. Just I'm not seeing it in the code... and too many days, accumulated time, of looking over the code causes one to get tunnel vision as far as scrutiny over the logic in each of the routines.


PARTNERS