Executing in VS2005 verses the .exe directly?

edited January 2011 in General discussions
This is an odd question, I know, but is there any difference at all between executing a project in VS2005 verses running the .exe directly in the /bin folder?

I would have said no myself, but I notice tonight if I run my project within VS, all orxOBJECT elements are fine.

If I run the .exe directly, I notice some of my minor elements lose their position values and stick to 0,0,0.

It's not a big deal, I can fix this stuff up probably but I'd like to know why it would be different. I can't see how it could be. A pathing thing? The initial positions being picked up in the config perhaps?

The debug logs generated between the two execution methods were identical.

Comments

  • edited January 2011
    I can only think of two differences: the working directory which is enforced by Visual Studio and the fact that the debugger is likely to set to some value all the uninitialized variables.

    If it's none of these, I'm all for some printf (or orxLOG, in this case! ;)) debugging!
  • edited January 2011
    HA! Debugging? -REAL- men -GUESS! :D
  • edited January 2011
    orxLOG always cops a fair flogging. Executing from VS in either DEBUG or RELEASE, positions are correct. Executing the resulting .exe alone in either mode, positions are not correct.

    I'll do some orxLOG outputs and pinpoint the difference. I'll report back when I have something.
  • edited January 2011
    It appears to be uninitialised variables. Oops.

    I'll have to find out how to enable that as a warning in VS.

    You know, in my day, we used truckloads of uninitialised variables and it didn't hurt us a bit. We carried them to school, uphill, both ways. :)
  • edited January 2011
    Hehe, world would be so [strike]deterministic[/strike] boring without uninitialized variables! ;)

    There's probably a warning to enable in VS, but you need to check MSDN to find its number. If it were me, I'd go with CppCheck which is a great static code analysis tool which will find much more issues than VS's compiler. :D
  • edited January 2011
    LLVM and Clang... now -there- is a way to do code analysis... such -delicious- error messages *drools*

    *cough* erm... sorry, vs2008 and vs2010 also have considerably better error/warning/whatnot handling, just curious, is there any particular reason you're sticking with 2005?
  • edited January 2011
    I have all three on my system (work requires every version), but I choose vs2005 because it's an old friend and because it's the only one that can drop 0 - 100kms an hour in 3 seconds (fast startup speed :)).

    vs2010 spends too much time contemplating it's own navel, and vs2008... I don't like it's startup image. Kidding of course. I'll eventually use vs2008 more, but not vs2010 though.
  • edited January 2011
    hmm, never had any real lag on start-up with 2010, but I'm a bit of a pedant when it comes to keeping my drives... 'efficient'. Which is probably a good thing considering my system is on an -old- 120gb IDE drive *shame*

    (*edit* dang I used the word "drive" a lot :p)

    Still, to each their own I suppose :) I'd love to have vs2010's interface (not sure why, just like it... go figure) with LLVM and Clang's compiler&errors, and N-brain's collaborative ide tools... -that- would be bliss ... too bad n-brain's now dead, and Microsoft are infested with the 'not invented here' syndrome :(... ahh, dreams and their crushing defeats :(
Sign In or Register to comment.