• Advertisement
Sign in to follow this  

project only works when launched within vis

This topic is 3232 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

so when i launch my project within vis using f5 (both release and debug) its fine, but when i run the executable by itself it loads part of the game then hangs after the first cutscene when level 1 begins i cant have a look myself now since im at work, but what are the main differences between just hitting the executable and launching within vis? there were no warnings but ill assume its to do with memory management or some undefined variable somewhere

Share this post


Link to post
Share on other sites
Advertisement
The current path is the difference. If you launch from visual studio it takes the exe from the path where the exe resides but the current path could be set (check project properties) to the path of the solution file.

If you launch by directly clicking on the exe in the Debug or Release folder then you have a different path. Hence you could fail loading resources for your level if you rely on hardcoded pathes to your level resources.

Share this post


Link to post
Share on other sites
oh yeah good point but i shouldve mentioned i normall copy and paste into the directory where it wants to be relative to assets, sorry for not being clear :)

Share this post


Link to post
Share on other sites
Then it might have to do with some invalid memory access and I would recommend inserting some couts to see where excatly it gets stuck. Uninitialized variables shouldn't be the problem since the debug compiled exe should take care of that.

Share this post


Link to post
Share on other sites
i've no console window attached so i think i'll have to have a billion asserts put into place.. it was all fine then i gutted what i had so far to add a fsm which worked ok, then i added an entire level in a coding frenzy and was only testing from within vis >_<

Share this post


Link to post
Share on other sites
1. Start the game from Windows Explorer
2. Start up VS
3. Load your solution
4. Let the game hang
5. Go to debug => attach to process => choose your game
6. Hit break all

Now you should be able to see where your game freezes.

Share this post


Link to post
Share on other sites
that sounds beautiful! i'll give it a go first thing when i get home and rate you at home (half this site doesn't load on my work computers)

Share this post


Link to post
Share on other sites
Ok without an attached console the debugger attach is the way to go unless you are using threading. Threading and timing delay caused by the debugger could also prevent the error from crashing you app.

Note that once you have attached the debugger you can add breakpoints by CTRL+B and specify a function to place a breakpoint by writing out its full namespace like so:

myenginenamespace::myclassname::myFunctionToBreak

Share this post


Link to post
Share on other sites
what the hell

i have a class with a member variable

CAnimation* Anims;

in the constructor i'm calling

Anims = new CAnimation[2];

i called it from somewhere else originally but i got access violation shouty boxes so moved it as close to the variable itself as possible and still i'm getting access violations trying to do that

I have no idea why, it's annoying that it works in vis but not outside

Share this post


Link to post
Share on other sites
Quote:
Original post by Mantrid
i called it from somewhere else originally but i got access violation shouty boxes so moved it ...

[grin]

Sorry but if you have an access violation then hunt down and terminate your bug but DO NOT JUST MOVE THE CODE somewhere else!

If you have an access violation then you are doing something really bad such as accessing memory that does not belong to you. If the construction of this CAnimation instance is really the problem then I would star looking at the class' constructor. But if the = operator storing the new instance in your member variable is the problem you might already be dealing with a memory override invalidating your this object of the instance with this member variable. This would then have been cause by another part of your code illegally writing outside its memory bounds thus using the this instance's memory.

Anyway, you are just lucky that VS keeps your app alive a little longer but that's just pure luck. Actually, in this case its rather bad because it made you believe you have "solved" your original problem by moving some code.

Share this post


Link to post
Share on other sites
it was being called from a derived class of it's original class pointed to as a member of another class, i thought the safest bet was to rule that out first as a cause ;)

i eventually found out it was just a corrupted heap and fixed it anyway

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement