How to debug?

Started by
10 comments, last by pascalosti 17 years, 10 months ago
Ok, I have some problems on how to debug a program. Recently, I was playing around with my pong game and tried to get the ball to bounce based on where it hits the paddle instead of just bouncing off the paddle. I figured out a formula and changed the code. When I tried to play it, it did not work at all. I finally copied and paste the section of code into a small program to output the values, and I found out my formula was wrong. (I forgot that the SDL screen coordinates are not the same as a cartesian coordinate system. duh!) Anyways, I changed it and it still isn't working like it should. I think it might have to do with the x,y position of the paddle or ball. That is an example. My question is how do I go about debugging? It is hard for me to get something working the way I want it. I don't really want to look at someone else's source code for the game and copy their ideas. I feel that I need to learn how to solve these kinds of problems on my own. Maybe I should look at how other people implement them? Or could it be I'm not cut out for programming? Sorry if this turned out into a mini rant. I'm mostly interested in how to debug a program or game.
Advertisement
I understand your frustration. Try not to get discouraged. Heck, by virtue of the fact that you can clearly state the problem indicates your more cut out for programming than some others. So with that out of the way. Debugging. Lots of ways to do it. Actually, you were already using a common, quick and easy method. That is, output what the program is doing at runtime. I think what you're looking for, however is what's called 'stepping through' the program. How to do that depends on which development environment you're using. I personally use Visual Studio 2005 which has an excellent debugger which allows you to set breakpoints at which the program execution will stop and you can examine the values of runtime variables and objects.

One thing, debugging is great, but try not to become too dependent on it. By that, I mean that it is a great skill to be able to trace through your programs in your head or on paper. For example, take a loop from your program (I'm sure there must be at least one), and trace it through keeping track of the variables either on paper or in your head if there's not too many of them.

Hope that's helpful. If not, post which IDE you're using and I'm sure others can help.

Good luck.
Quote:Original post by eektor
I don't really want to look at someone else's source code for the game and copy their ideas. I feel that I need to learn how to solve these kinds of problems on my own. Maybe I should look at how other people implement them?

Or could it be I'm not cut out for programming?


With that attitude, YES YOU ARE! We need more like you.

Don't be disheartened - I've encountered several professional programmers who have never learnt to use a debugger. Don't follow their example ;¬)

A good way to learn is just to set brerakpoints in interesting places in your code. You'll end up adding more, removing some, moving them around, etc.

Then start looking at the 'watch' window and see the changing values as you step through the program. This will demystify things for you a lot I'm betting. It was certainly an enlightening experience for me. I tend to use the debugger to work out the flow of code I'm unfamiliar with too, and that's (IMHO) the most useful thing a debugger can do for you.

[size="1"]
Sounds mostly like you just aren't using a debugger. It's very rare to get something working correctly the first time. In face, it's so rare that when it actually happens, you get really nervous and worried that there's a subtle bug that you just aren't seeing. =)

Just grab a nice debugger and do what was mentioned above: set breakpoints, "watch" variables, printing values out to a text file works well. I actually find myself using that last bit for problems like the one you describe. Sometimes just seeing numbers pour out over a large number of frames is the only way to home in on "wrong" patterns in your logic.

-me
Thanks for the encouragement. I use Dev C++. I'm going to check it out and see if I can figure out how to use the debugger on it. (I'm guessing it has one.) I guess the books I read never mentioned how to use a debugger, so I never used one.
Visual Studio also has a "Debug Output Window". You can write texts
to that with OutputDebugString().

Together with sprintf to format your strings, that's a really
valuable help.

And don't get discouraged - probably 25% of the entire development
process goes into debugging, so it's a really valuable skill to
have (being able to understand code in your mind together with
using breakpoints, watches and maybe even breakpoints on memory
adresses) to find bugs.
visit my website at www.kalmiya.com
Ok, I read the information about debugging with Dev C++. I kind of get the idea of using the breakpoints and watch variables, but I can't seem to get it to work. The game doesn't stop at the break point and I don't see where I get the values for the variables. Anybody know how you to use the debugger in Dev C++?
Do you start the game through the debugger?
Yes, and the game doesn't stop when it gets to the line I thought I put a breakpoint at. I put the breakpoint when the ball collides with the player's paddle. I wanted to know the values for the angle and speed. The game continues though even when I'm in debug mode.
Quote:Original post by Kitt3n
And don't get discouraged - probably 25% of the entire development
process goes into debugging


I believe the quote is "writing the code takes the first 90% of the time, and debugging it takes the other 90% of the time".
[ search: google ][ programming: msdn | boost | opengl ][ languages: nihongo ]

This topic is closed to new replies.

Advertisement