Introduction to Xcode's Debugger

Most of you are familiar with the material in this article, but I read a lot of programming questions on message boards that could have been answered by running the code in a debugger. I hope new programmers will be able to find this article and use it to learn how to debug their programs.

What is a Debugger?

Computers run programs fast, which is normally a good thing. But if you have a problem in your code, the code runs too fast for you to figure out what is wrong. It's like trying to watch a DVD in fast forward mode.

A debugger lets you slow things down so you can see what is happening when your program runs. By using a debugger you can pause your program at any line of code, step through your code line by line, and examine the values of your program's variables. A debugger helps immensely when you're trying to find out what's wrong with your code. If you're serious about being a software developer, one of the best things you can do is learn to use a debugger.

Running the Debugger

Xcode is set up so you don't have to do much work to run the debugger. Every Xcode project you create has a Debug (older versions of Xcode call it Development instead of Debug) build configuration that is set for debugging. The Debug build configuration is the default configuration so all you have to do is choose Build > Build and Debug to open the debugger window and start debugging.

The debugger window has four areas. At the top is the toolbar, which has buttons for performing the most common debugging tasks. You can also find these debugging commands in Xcode's Debug menu.

Below the toolbar on the left is the call stack viewer. At the top of the call stack is the function where your program current is. Below that is the function that called the current function. Below that is the function that called the second function and so on. The call stack viewer is the least interesting part of the debugging window for those of you who are new to debuggers.

Next to the call stack viewer is the variable viewer. The variable viewer lets you see the values of the current function's local variables and arguments as well as any constant variables that are in the current function's source code file.

At the bottom of the debugger window is the editor, which lets you see what line of code the program is currently at.

Setting Breakpoints

Launching the debugger initially doesn't do anything because you haven't told the debugger when to pause. Breakpoints tell the debugger to pause your program when it reaches a certain line of code. What you have to do is set breakpoints where you want your program to pause.

Click the gutter next to a line of source code in the editor window to set a breakpoint at that line of code. The gutter runs along the left edge of the window. When you set a breakpoint, a gray arrow appears next to the line of code. Dragging the arrow off the gutter removes the breakpoint.

Now when you run your program in the debugger, it will pause when it reaches any of the breakpoints you set.

Stepping Through Your Code

Stepping is one of the most important functions a debugger performs. It lets you walk through one line of code at a time and see the effects of executing that line of code. If you look at Xcode's debugger window toolbar, you will see three buttons: Step Over, Step Into, and Step Out. If the current line of code does not call a function, the Step Over and Step Into buttons do the same thing. They execute the current line of code and move to the next line.

The Step Over and Step Into buttons perform different tasks when making a function call. Clicking the Step Over button tells the debugger to execute all the code in the function you're calling and move to the line of code after the function call. It steps over the function you're calling.

Clicking the Step Into button takes you inside the function you're calling, which lets you step through the code inside the called function. It steps into the function you're calling. When you step into a function, the Step Out button becomes relevant. Clicking the Step Out buttons takes you out of the called function and moves to the line of code after the function call. Clicking the Step Into and Step Out buttons is the equivalent of clicking the Step Over button.

Conclusion

For more information on Xcode's debugger, read the Xcode's User Guide, which you can open in Xcode by choosing Help > Xcode Help. There is an entire section on debugging.

Waiting for the New Zelda Game

The latest Zelda game came out for Gamecube today at 5:00 PM, and I got to wait in line for it. My mother heard there were shortages so she asked my father to go to Target to get a copy. She needed two copies as Christmas presents, and purchases were limited to one per person so I ended up going to be the second person.

We got to Target a little after 4:30 PM. Fortunately, there were only two people in line when we got there. A couple in their 60's got in line behind us a few minutes later to buy a copy for their grandson, and another person got in line a few minutes before 5. Seven people in line. I felt a little foolish waiting in such a short line.

Then 5:00 came, and I saw the store had only 6 copies of the game. Those of us in line were the only people to get a copy of the game. I was shocked at how few copies were available. I figured at least 20 would be available, but I felt a lot less foolish waiting in line. It's going to be hard to find a copy of Zelda by Christmas.

Setting Up SDL for Eclipse on Mac OS X

I got an email from someone who was having trouble setting up SDL on Eclipse. I have never used Eclipse so I could not provide him much help. He eventually found a solution and emailed it to me so I could share it with you.

There are four things you have to do to get SDL working with Eclipse on Mac OS X in addition to what I outlined in my SDL tutorial. First, you must copy the files SDLMain.h and SDLMain.m to the same directory as your SDL program. My interpretation of this statement is if you create an Eclipse project and add your source code files to the project folder, you must also add SDLMain.h and SDLMain.m to the project folder.

Second, you must add the directory where your SDL headers reside to the Directories setting for the GCC C++ compiler. Your headers most likely reside in the following directory:

/Library/Frameworks/SDL.framework/Headers

Third, you must add linker flags for the Cocoa and SDL frameworks as well as the path to the SDLMain.m file.

-framework Cocoa
-framework SDL
/Path/To/YourProject/SDLMain.m

Fourth, you must change the following line of code in SDLMain.m:

#import "SDL.h"

to the following:

#include SDL/SDL.h

Put less than and greater than signs around the SDL/SDL.h. For some reason I can't get those characters to show up in the blog.

OpenGL Book Pushed Back to 2007

I've come to the conclusion there is no way I'm going to be able to finish the OpenGL book by the end of the year, as I had hoped. I would like to have the book finished in the first quarter of 2007.

Writing has progressed slower than I thought. I have my facts correct, but I'm having a hard time making the material interesting to read and making clear explanations. I'm frustrated by the slow progress I'm making, but I prefer taking the time to write a good book that helps people instead of rushing a crappy book that doesn't help anyone.

Game Design Tip: Don't Make the Player Play the Same Stuff Repeatedly

By play the same stuff I mean play the same part of a level repeatedly. This problem occurs more with console games than computer games because console games have less flexibility in game saving.

Example: Metroid Prime

I'm going to use the game Metroid Prime to describe the problem of playing the same part of a level repeatedly for two reasons. One, it's the game I'm currently playing so it is fresh in my mind. Two, it's a really good game. I want to show that even good games can have minor problems.

If you're wondering why I'm playing a 4 year old game, I'll explain it now. I got Metroid Prime about 3 years ago and I got stuck early and quit playing it. I started playing it recently because my brother needed my Playstation 2 to play DVDs because his DVD player broke and I finished my other GameCube games.

Repetition Can Turn Something Fun Into a Chore

Metroid Prime features a lot of boss enemies to fight, and they can be very difficult to defeat. To reach a boss involves fighting lesser enemies, running, jumping, maneuvering the morph ball through tight areas, and problem solving. Sometimes it can take 5-10 minutes of gameplay to reach the boss, and when you die, you have to go back to the last save point and play those 5-10 minutes again.

Because some of the boss enemies are tough to defeat, you can die dozens of times, and replaying the same 5-10 minutes of gameplay to reach the boss gets old fast. Playing those 5-10 minutes to reach the boss is fun the first time. You're making progress in the game and exploring new areas. Playing to reach the boss a few more times lets you perfect your technique. But after dying 25-50 times, playing the same sequence to reach the boss becomes a chore instead of being fun.

Solutions

One solution to the problem of having to play the same area of a level repeatedly is to provide more save points. In the case of Metroid Prime, having a save point before reaching a boss would prevent the player from having to play the same sequence over and over again. But more save points could make the game too easy. Metroid Prime replenishes your energy (health) to 100% when you save the game.

Another solution would be to continue the game where you died. In the case of Metroid Prime, being able to fight the boss right away after dying would eliminate a lot of frustration. The time spent getting to the boss could be spent on the real challenge, defeating the boss.

The good news for most of the game developers reading this is you're developing computer games, not console games. Computer games can let the player save the game whenever they want so you can keep the player from playing the same sequence over and over again.

Sometimes it Takes a While to Respond

I got an email last night from a customer. He tried to download the updated version of Xcode Tools Sensei and got an error message saying the file was not found on the server. The error message is not surprising because I pulled the file from the server two months ago.

I wanted people who had bought the electronic version of the book to be able to download the new version. For obvious business reasons I didn't want the new version to be on the site permanently. My solution was to post the updated version on my site for a week and send an email to every customer who wanted to be contacted about updates. I figured a week was enough time for the customers I emailed to download the new version. I apparently was wrong.

I did send the customer the new version. If any of you bought an old electronic version (before September 2006) and want the new version, send me an email and I'll send you the new version.

Switched to Blogger

I switched the blog from Lulu to Blogger. The old blog did not handle large posts (over a page) well, eliminating text in the middle of the post. I did a test post of a 7 page article, and there were no problems so I decided to switch. Blogger's spell checking is an added bonus. I included a link to the old blog entries to ease the transition.