And how do you debug movement code that is dependant on real-time keypresses with a debugger, remote or otherwise? The debugger is an incredibly useful tool but sometimes it doesnt fit the job.
Dan
New Debugging idea
You may debug a program that depends upon key presses quite easily... just put a breakpoint in the key handling code :-p
I do these things every day with my debugger in MSVC++ 6.
Cheers, and learn to use your debuggers, ~SPH
I put that badly, I am not talking about just a normal keypress. I use the debugger for that as well. My problem was (about 2 years ago) that my collision detection routine wasn't working occasionally. Most the time it was fine, but sometimes when you hit a wall (in a 3d environment) the character would move backwards or upwards. I tried the debugger and found that the code was working again. The problem eventually turned out to be a cumulative error that would build up while the forward key was held down. The debugger couldn't catch it because after I had run through my collision loop and went back to the game, the key wan't pressed down anymore and the error didn't build up. So when the breakpoint fired and I started debugging the next frame, my movement vector was nothing and I had nothing to debug. I also only got to see the game screen for a 70th of a second every minute or so which didn't make it to easy to know how far away from a wall I was. My options were -
a. Make the character always go forwards regardless of key state. This didn't work because the error was only occasional and I had to have control of the character to get in a position for it to happen.
b. dump all the movement information and times to a file and write a replay routine to step through it in non-real time. This could have worked, but I thought it would take to long to do as I would have to skip though several hundred useless frames every time I wanted to check it to get to where to problems started.
c. Use remote debugging and leave a brick on my keyboard. I didn't have 2 PC's
d. add some form of visual feedback so that I could get an idea of which bit of code was causing the problem. This was what I did and wrote about above. It took me less than an hour and I found and fixed the problem quickly.
There is probably a better solution involving debugging, but at the time I fixed it quickly and easily my way, and that is the important bit as far as I am concerned.
Dan
[edited by - danbrown on March 27, 2004 7:51:21 PM]
[edited by - danbrown on March 27, 2004 7:51:57 PM]
a. Make the character always go forwards regardless of key state. This didn't work because the error was only occasional and I had to have control of the character to get in a position for it to happen.
b. dump all the movement information and times to a file and write a replay routine to step through it in non-real time. This could have worked, but I thought it would take to long to do as I would have to skip though several hundred useless frames every time I wanted to check it to get to where to problems started.
c. Use remote debugging and leave a brick on my keyboard. I didn't have 2 PC's
d. add some form of visual feedback so that I could get an idea of which bit of code was causing the problem. This was what I did and wrote about above. It took me less than an hour and I found and fixed the problem quickly.
There is probably a better solution involving debugging, but at the time I fixed it quickly and easily my way, and that is the important bit as far as I am concerned.
Dan
[edited by - danbrown on March 27, 2004 7:51:21 PM]
[edited by - danbrown on March 27, 2004 7:51:57 PM]
hlivingstone and ShmeeBegek, of course "learn to use the debugger" is what one should do. But many of the answers in this tread took into account the questions people had about debugging a full-screen app without using remote debugging (i.e. no network, or no second computer). "Use the debugger" doesn't work in these cases, as you can't see your debugger if your app is running full screen - hitting a breakpoint appears as if the computer's hung, but even if you manage to accomplish switching back to your debugger in this case, it causes your app to lose focus (i.e. making debugging stuff like WM_PAINT, WM_SETFOCUS, etc. handler functions a nightmare), etc. Screen savers have their own extra problems, as loosing focus triggers the app to shutdown. 
Dan, that VarList thing is a cool idea. A little bit more work, but way cooler.
The BEST solution I've found so far: spend $10 and pick up a second video card off of EBay, scrounge an old monitor from somewhere, and run your debugger in the second monitor and your full-screen app on your primary monitor. But then when you want to debug your multimonitor screen saver code, you're sort of back to the original problem.
[edited by - BriTeg on March 27, 2004 7:33:58 PM]
Dan, that VarList thing is a cool idea. A little bit more work, but way cooler.
The BEST solution I've found so far: spend $10 and pick up a second video card off of EBay, scrounge an old monitor from somewhere, and run your debugger in the second monitor and your full-screen app on your primary monitor. But then when you want to debug your multimonitor screen saver code, you're sort of back to the original problem.
[edited by - BriTeg on March 27, 2004 7:33:58 PM]
quote:Original post by danbrown
int myvar = 23;VarList->AddInt(&myvar, "myvar");
Dan
Of course with C++ you can always use polymorphism so that you call the same function name irrespective of the type & let the compiler figure it out, then given this you could use the preprocessor with the stringify operator ( # ) so that you only need to write the variable once...
class VarList { // ... static void Add(int *a, char *name); static void Add(char **, char *name);};#define MONITOR_VAR(var) VarList->>Add(&var, #var); Another way to deal with local vars might be to have some kind of object to monitor them at the level of scope that the local variable exists that will register and unregister it with the VarList object as required & when the monitor object gets killed, so it cleans up the live reference in the VarList object (sort of like an auto_ptr type of concept really), the var list could then maintain a list of variable that it should display, but not monitor directly....
hmm, hope someone can make sense of what I''m trying to get at - of course I agree that using a standard debugger is often better, but not always - I wrote some diff code that was slightly buggy, unfortunatelly the bug only reared its head when the number of different items exceeded about 100000 and weren''t roughly evenly distributed ... stepping through that by hand wasn''t too practicle or fun....even with conditional breakpoints
By far the easiest way of using a debugger to debug games is to make them so that they run windowed.
I know that running windowed restricts your renderer options, but hopefully, you will have some kind of renderer which can work in a window, and thus allow you to debug the logic of the game (even if the renderer performance decreases dramatically)
The other options are:
- Remote debugging (i.e. run a debugger on another box, and connect to some kind of local debug service which attaches (or starts) the program)
- Local debugging with remote login - i.e. via Linux / X or Windows / Terminal server (or something else)
Neither of them are particularly straightforward.
Mark
I know that running windowed restricts your renderer options, but hopefully, you will have some kind of renderer which can work in a window, and thus allow you to debug the logic of the game (even if the renderer performance decreases dramatically)
The other options are:
- Remote debugging (i.e. run a debugger on another box, and connect to some kind of local debug service which attaches (or starts) the program)
- Local debugging with remote login - i.e. via Linux / X or Windows / Terminal server (or something else)
Neither of them are particularly straightforward.
Mark
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
