project only works when launched within vis
Author
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
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.
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.
Author
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 :)
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.
Author
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 >_<
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.
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.
Author
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)
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:
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
Author
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
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
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.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
