[Fixed]Using VC++ 2008 Debug
by CSMP · in Torque Game Engine · 10/11/2009 (3:28 am) · 18 replies
OK, It's been brought to my attention that running a Debug Build would increase productivity in (obviously) Debugging efforts so I'm gonna start here with some questions that I'm having.
Until this point I've been running a Release Build to avoid dealing with c++ (due too prior inexperience) and... and well thats basically it... oh ya the performance gain as well!! lol
So here it goes, my problems with running a Debug Build:
1. If I try and run a Debug Run through MS VC++ I get a "Failed to Load main.cs" error, Most likely because I'm compiling the .exe to another projects example folder(where the scripts are), However its not linking something else (???) to the other folder and giving me that error.
For example:
E:/MPGE Archive 2/Zombie_Event Advanced/example/ Is the Target Directory(W/ Scripts)
E:/MPGE Archive 2/Zombie_Event Basic/engine/ Is the Source Directory
2. If I run the Debug Build straight from the .exe itself after the scripts are done loading I get a
"GBitmap::GBitmap: in order to extrude miplevels, bitmap w/h must be pow2" error.
(This one can be fixed pretty quick given Question3 is correct)
3. I saw in another post that Pow2 would still work if the texture dimensions were 128x256... is this true?
Until this point I've been running a Release Build to avoid dealing with c++ (due too prior inexperience) and... and well thats basically it... oh ya the performance gain as well!! lol
So here it goes, my problems with running a Debug Build:
1. If I try and run a Debug Run through MS VC++ I get a "Failed to Load main.cs" error, Most likely because I'm compiling the .exe to another projects example folder(where the scripts are), However its not linking something else (???) to the other folder and giving me that error.
For example:
E:/MPGE Archive 2/Zombie_Event Advanced/example/ Is the Target Directory(W/ Scripts)
E:/MPGE Archive 2/Zombie_Event Basic/engine/ Is the Source Directory
2. If I run the Debug Build straight from the .exe itself after the scripts are done loading I get a
"GBitmap::GBitmap: in order to extrude miplevels, bitmap w/h must be pow2" error.
(This one can be fixed pretty quick given Question3 is correct)
3. I saw in another post that Pow2 would still work if the texture dimensions were 128x256... is this true?
#2
10/11/2009 (2:09 pm)
yes, like Daniel say changing the working directory to the directory of your game, should works for debug from vs. 
#3
Good idea to develop in Debug mode, it will save you lots of time hunting down bugs! Good luck!
10/11/2009 (2:38 pm)
The error's cause is that the engine is trying to create mipmaps for one of your textures after it has been loaded. It does that mostly automatically unless explicitly asked not to, or the texture has mips built in (ie. dds). As long as each dimensions of your textures are powers of two (ie. 128x256) this will not assert. You'll need to double-check your textures' dimensions, that's all.Good idea to develop in Debug mode, it will save you lots of time hunting down bugs! Good luck!
#4
Yeah I also like to keep the Dimensions 256x258, 512x512 and etc., but some of the textures from the content packs I've purchased are uneven and I'd rather add as little whitespace as possible when trying to make the textures compatible for the debugger.
@Konrad: Thanks for the confirmation!
Thanks Everyone, Problem 1. fixed and I'm gonna start working on Problem 2. right now, I'll return with any problems or observations.
:)
10/11/2009 (4:15 pm)
@Daniel: Ah, The Working Directory Fix worked!Yeah I also like to keep the Dimensions 256x258, 512x512 and etc., but some of the textures from the content packs I've purchased are uneven and I'd rather add as little whitespace as possible when trying to make the textures compatible for the debugger.
@Konrad: Thanks for the confirmation!
Thanks Everyone, Problem 1. fixed and I'm gonna start working on Problem 2. right now, I'll return with any problems or observations.
:)
#5
However I now have a new error I'm gonna post here while I search the forums for the solution:
Edit: I've noticed this before and ignored it due to no visible problems... but in the console.log right before the error there is this:
Also, it seems I can use the Debugger to "Continue" through the errors and run the game, and I don't notice anything wrong!?
10/11/2009 (4:48 pm)
OK, Problem 2. fixed one of my "Color" textures was incorrectly sized and was giving me that error...However I now have a new error I'm gonna post here while I search the forums for the solution:
engine/gui/containers/gui/scrollctrl.cc @ 108 "Failed to create bitmap array"
Edit: I've noticed this before and ignored it due to no visible problems... but in the console.log right before the error there is this:
GuiMessageVectorCtrl: double detach
Also, it seems I can use the Debugger to "Continue" through the errors and run the game, and I don't notice anything wrong!?
#6
The second error is not really an error, it's just a message. You can either ignore it, remove it or add a function to check if the message vector control is already detached. I opted for option three myself.
Oh, and welcome to the murky world of compiler debugging. Just try to remember one thing, debugging can be very convoluted. Just because a piece of code fails does not mean that is the cause of the failure. Always hop back a few steps to see how it got to that point.
I cannot give you any tips on how to work with VS2008, I'm an old skool VC7.1'er. Smaller binaries and less VC Redist dependencies FTW!
10/11/2009 (5:31 pm)
That first error usually comes up if the GUI control profile has an invalid bitmap. Check the debugger to see which profile is the culprit.The second error is not really an error, it's just a message. You can either ignore it, remove it or add a function to check if the message vector control is already detached. I opted for option three myself.
Oh, and welcome to the murky world of compiler debugging. Just try to remember one thing, debugging can be very convoluted. Just because a piece of code fails does not mean that is the cause of the failure. Always hop back a few steps to see how it got to that point.
I cannot give you any tips on how to work with VS2008, I'm an old skool VC7.1'er. Smaller binaries and less VC Redist dependencies FTW!
#7
csmp.angelfire.com/log.txt
Btw thanks I'll try and remember that.
10/11/2009 (5:51 pm)
The debugger isnt giving me any info about a profile.csmp.angelfire.com/log.txt
Btw thanks I'll try and remember that.
#8
10/11/2009 (6:21 pm)
It will not be in the log. You need to check the call stack. Not sure where you will find it in VS2008 though. 
#9
10/11/2009 (6:27 pm)
Bottom right corner usually pops up a list of the functions that have been called to get to your current location.Quote:Also, it seems I can use the Debugger to "Continue" through the errors and run the game, and I don't notice anything wrong!?This is the case for trivial errors - in a release build, I'd assume the same errors are happening, but it's just not giving you a message, and trying to deal with it as best it can. In a debug build, the engine prefers to tell you about the problems instead of just letting them slide.
#10
Edit: Actually when the error message pops up theres nothing in the CallStack, afterward when the BreakPoint/Continue option dialog pops up those are the three lines.
10/11/2009 (6:47 pm)
Only 3 lines are showing up in the CallStack when this happens:ntdll.dll!7c90120e() // Yellow arrow pointing to this [Frames below may be incorrect and/or missing, no symbols loaded for ntdll.dll] MPGE.exe!Platform::debugBreak() Line 15 + 0x8 bytes // Green arrow pointing to this
Edit: Actually when the error message pops up theres nothing in the CallStack, afterward when the BreakPoint/Continue option dialog pops up those are the three lines.
#11
You still have the message itself, however - it told you the problem was happening at line 108 of guiScrollCtrl.cc. Do you have many scroll controls in the game? If not, it might be feasible to put a break point right on that line (click on the grey space to the left of the code and a little red circle will appear, then run the debug exe - when that line executes, the engine will break and you'll be able to access some useful debug info).
10/12/2009 (2:11 am)
Arg. That's the worst kind of break, because if you double-clicked on that last line, it would take you to the debugBreak method... which was, AFAIK, the reason the program broke. But for some reason, when breaking this way, it doesn't actually load anything useful in the call stack :P. I don't know why, but it's a pain.You still have the message itself, however - it told you the problem was happening at line 108 of guiScrollCtrl.cc. Do you have many scroll controls in the game? If not, it might be feasible to put a break point right on that line (click on the grey space to the left of the code and a little red circle will appear, then run the debug exe - when that line executes, the engine will break and you'll be able to access some useful debug info).
#12
There goes the information... Tons of it, I'll have to look through this for awhile(lol) because I'm not sure what to make of all this new info.
Thanks again Daniel, your a lifesaver.
10/12/2009 (7:01 pm)
Holy Cow!There goes the information... Tons of it, I'll have to look through this for awhile(lol) because I'm not sure what to make of all this new info.
Thanks again Daniel, your a lifesaver.
#13
10/12/2009 (8:45 pm)
When it breaks with Platform::debugBreak and you have no call stack try immediately doing a step out(shift+f11). That usually gets the call stack back.
#14
I've narrowed it down to the MG Starter Kit 'MainChatHUD', still trying to make something from all the info the auto and callstack windows are giving me.
10/12/2009 (8:51 pm)
Thanks for the info!I've narrowed it down to the MG Starter Kit 'MainChatHUD', still trying to make something from all the info the auto and callstack windows are giving me.
#15
10/13/2009 (1:22 am)
Hey, thanks Wes! I never even thought of that ;P. Good to know it's helping, CSMP - let us know what you find!
#16
My Project/MG Starter Kit has a scrollbar in the StartMissionGui, LoadingGui and ChatHud(aka MainChatHud) the two menu GUI's return a
However the ChatHud is returning(and this is the piece that crashes the program unless its in the VC Debug IDE in which case I can Break or Continue through it)
result = False
Whatever the 'result' bool is, ChatHud has broken it somehow... now this makes a little bit of sense if it is a Script problem because the MG Starter Kit was probably made without the intention of the actual source being edited and debugged, but everything looks fine in the scripts... more or less.
I'm still at a loss for whats really going wrong here though.
10/13/2009 (2:16 am)
OK this is what I've got so far...My Project/MG Starter Kit has a scrollbar in the StartMissionGui, LoadingGui and ChatHud(aka MainChatHud) the two menu GUI's return a
AssertFatal(result, "Failed to create the bitmap array");result = True
However the ChatHud is returning(and this is the piece that crashes the program unless its in the VC Debug IDE in which case I can Break or Continue through it)
result = False
Whatever the 'result' bool is, ChatHud has broken it somehow... now this makes a little bit of sense if it is a Script problem because the MG Starter Kit was probably made without the intention of the actual source being edited and debugged, but everything looks fine in the scripts... more or less.
I'm still at a loss for whats really going wrong here though.
#17
It looks like cloned Gui's in one, and it may be breaking the Debug version?
10/13/2009 (2:21 am)
Woa, hold on...//--- OBJECT WRITE BEGIN --- // removed, un-needed //--- OBJECT WRITE END ---
It looks like cloned Gui's in one, and it may be breaking the Debug version?
#18
Ok, check this out...
Notice anything strange with 'ChatScrollHud' above???
well, its profile "should" be 'GuiScrollProfile' but instead to make the ScrollHud transparent they switched it over to 'GuiDefaultProfile'... (which has BitmapArray = "false")
So now I've set the GuiDefaultProfile 'BitmapArray' variable to "True" in hopes that it doesnt break anything in the process and stops my Debug errors.
Thanks guys, my first "true" Debugging Session... and it sucked, lol.
Anyways hopefully I'll get used to it, having more options to find a problem really helped me out on this one and probably many more to come.
10/13/2009 (2:39 am)
YES!!!Ok, check this out...
Notice anything strange with 'ChatScrollHud' above???
well, its profile "should" be 'GuiScrollProfile' but instead to make the ScrollHud transparent they switched it over to 'GuiDefaultProfile'... (which has BitmapArray = "false")
So now I've set the GuiDefaultProfile 'BitmapArray' variable to "True" in hopes that it doesnt break anything in the process and stops my Debug errors.
Thanks guys, my first "true" Debugging Session... and it sucked, lol.
Anyways hopefully I'll get used to it, having more options to find a problem really helped me out on this one and probably many more to come.
Torque Owner Daniel Buckmaster
T3D Steering Committee
I've never seen your Pow2 error before, I guess it's something to do with your assets. Strange that you don't get the error in release version. I think point 3 is correct, though, and it's generally good practise to make textures pow2/pow2.