Me and Mark Publishing's Blog

Blog Moved

2008-06-02T18:45:00.001-05:00

I moved the blog. Here's the new blog location.

I have also moved all of the blog post from here and all the comments to the new blog location. If you want to comment on a post, go to the new blog location.

Xcode 3 Book in the Works

2008-04-26T14:05:00.000-05:00

You may have noticed I have not updated my site or this blog much recently. I've hinted at the reason in the past, but a bunch of people emailed me with questions about it so I figured I should write about it here. I am working on a new edition of Xcode Tools Sensei, specifically written for Xcode 3. Two questions come to mind.

What's Going to be in the New Edition?

There will be a lot of new material in the new edition, and I don't want to drone on and on about the new material. Some of the highlights include the following:

Xcode 3's new features, including refactoring tools, code folding, and the Research Assistant.
Interface Builder 3.
A new chapter on Instruments.
The version control chapter will use Subversion instead of CVS.

When Will the New Edition be Released?

I don't know the exact date, but I hope to have it finished this summer (winter for those of you in the Southern Hemisphere). I do know it will not be released before Apple's Worldwide Developer Conference (WWDC), which runs from June 9 to June 13. Apple is expected to release Xcode 3.1 and the iPhone SDK at WWDC. Because WWDC is less than two months away, it would be a waste of time to rush to release an Xcode 3 book, then put out a big update covering Xcode 3.1 and iPhone development. Doing so would also be a disservice to people buying the print version of the book.

SDL File Loading When Running from Visual C++'s Debugger

2008-02-07T01:55:00.000-05:00

I was testing some texture loading code on Visual C++ 2005 and 2008. The code compiled fine, but when I ran it from Visual C++'s debugger, it crashed every time. The code crashed because the program could not find my image file so it could not read the file and load the image. But the code ran file when I ran it from Windows Explorer. Why could my image file be found when I ran my program from Windows Explorer, but not from Visual C++'s debugger?

The reason was that Visual C++'s debugger uses a different working directory. Windows normally sets the working directory to the same directory as the executable file, which is where I had my image file. But Visual C++'s debugger sets the working directory to the directory containing the project file. Where is the project file? When you create a Visual C++ project, Visual C++ creates a folder that has the same name as the project name. Inside this folder is a second folder that has the same name as the project name. The project file resides in the second folder. The second folder is where the image file needed to be to debug my program. Moving my image file to the second folder fixed the crashing problem inside the Visual C++ debugger.

If you're using Visual C++ to write a game and you want to run the game inside the debugger, make sure your game's files are in the same directory as the project file.

XcodeTemplateFactory

2008-02-04T15:30:00.000-05:00

Hog Bay Software recently released XcodeTemplateFactory, a utility that converts an Xcode project to a project template. I tried XcodeTemplateFactory, and it is an easy way to create Xcode project templates.

Building XcodeTemplateFactory

When you download XcodeTemplateFactory, you get an Xcode project file called XcodeTemplateFactory. Open the project in Xcode and build it to create the XcodeTemplateFactory app.

Creating a Project Template with XcodeTemplateFactory

To convert a project to a project template, run the XcodeTemplateFactory app that you built. Click the Choose button to open an Open File dialog box. Navigate to the folder containing your project and click the Open button. Enter a description of your project in the Project Description field. Make the description a good one. When you create a new Xcode project and select your template from the template list, your description is going to appear underneath the template list. Click the Generate Template button, and you've created an Xcode project template.

Xcode 3 Template Location Clarification

2008-01-23T00:00:00.000-05:00

In a previous post on Xcode 3's new locations for project and file templates, I said project and file templates needed to be in the following locations:

Developer/Library/Xcode/Project Templates

Developer/Library/Xcode/File Templates

Those locations are for Apple's templates. While it is technically possible to place your templates with Apple's (I placed some of my SDL and OpenGL project templates with Apple's project templates and had no problems), the Xcode 3 release notes say you're supposed to place your templates in a different location. Project templates belong in the following location:

Library/Application Support/Developer/Shared/Xcode/Project Templates

File templates belong in the following location:

Library/Application Support/Developer/Shared/Xcode/File Templates

You're going to have manually create all the folders after Application Support in the path.

If you use the paths I just mentioned, your project and file templates will be available for all users on your Mac and be available for use in both Xcode 3 and Xcode 2.5. If you want to restrict your templates to a specific version of Xcode, replace Shared with the Xcode version number. If you want only a single user to be able to use your templates, start the path with Username/Library.

Xcode 3 Addition: Python and Ruby Cocoa Project Templates

2008-01-18T00:45:00.000-05:00

Xcode 3 includes project templates for writing Cocoa applications in Python and Ruby. Those of you who were turned off of Cocoa by Objective C's syntax can now give Cocoa development a try.

If you installed the developer examples when you installed Xcode 3, you will find on your hard drive many examples of Cocoa programs written in Python and Ruby. You can find the Python examples at the following location:

Developer/Examples/Python/PyObjC

You can find the Ruby examples at the following location:

Developer/Examples/Ruby/RubyCocoa

Interface Builder 3 Change: No Subclass Creation

2008-01-16T15:25:00.000-05:00

Older versions of Interface Builder let you create subclasses for Cocoa applications and generate source code files for the subclasses you created. As an example, you could drag an OpenGL view to a window, subclass the OpenGL view, and have Interface Builder create .h and .m files for the subclass. But Interface Builder 3 no longer lets you create subclasses. How do you create the subclasses?

You create the subclasses the old-fashioned way: with source code. Create your subclasses in Xcode. Interface Builder and Xcode are synchronized so the subclasses you create in Xcode appear in Interface Builder as well.

Choose File > New File to create a new file. A window will open containing many file types for you to choose from. For a Cocoa program you would want one of the Cocoa files unless you're writing a Cocoa program in Ruby, in which case you would use one of the Ruby files. Name your file and click the Finish button. You've created a subclass file.

Instantiating Your Class

After creating your class in Xcode, you may need to add an instance of your class to the nib file so you can make connections in Interface Builder. If Interface Builder's library window is not open, open it by choosing Tools > Library. The library window contains Interface Builder's user interface elements.

Select an NSObject from the library window. NSObject is a blue cube. Drag NSObject to the nib file window. An NSObject named Object should now appear in the nib file window. Choose Tools >Identity Inspector to open the identity inspector. Select the NSObject in the nib file window.

The top of identity inspector should have a combo box labeled Class. Choose your class from the list of classes in the combo box. The name of the NSObject instance in the nib file window will change from Object to the name of your class. Any outlets and actions in your class should appear in the identity inspector.

If your classes are not appearing in Interface Builder, choose File > Synchronize With Xcode in Interface Builder.

Xcode 3 Change: Run Log

2008-01-14T14:20:00.000-05:00

Older versions of Xcode had a run log window that let you view the output of command-line programs. Where did it go in Xcode 3?

In Xcode 3 the run log's name has changed to Console and has become part of the debugger window. The console is initially invisible, which makes locating it difficult. There are two ways to reveal the console. First, you can choose Run > Console to show the console, and you will see the console at the bottom of the debugger window. Second, you can drag the splitter bar at the bottom of the debugger window to reveal the console.

Update (January 16, 2008)

Xcode's debugger window has a splitter bar for the console only if you're using Xcode's All-In-One layout. If you're using the Default or Condensed layouts, the console is a separate window. Clicking the Console button on the debugger window toolbar opens the console for the Default and Condensed layouts.

Xcode 3 Change: Universal Binaries

2008-01-11T13:40:00.000-05:00

The Release build configuration for Xcode 3 is set to create 32-bit universal binaries for Cocoa and Carbon application projects. All you have to do is create a Cocoa or Carbon application project, and you're set to build a universal binary. You'll have to modify the Architectures build setting if you want to build a 64-bit version of your application.

Xcode 3 Change: Release is the Default Build Configuration

2008-01-10T15:20:00.000-05:00

In Xcode 3 Apple changed the default build configuration from Debug to Release. This decision does not make much sense. Unless you're writing a simple program, you're going to want to debug your program when you start writing it. Wanting to debug your program means that you want the Debug build configuration, not the Release configuration.

When you create a project with Xcode 3, the first thing you will want to do is change the active build configuration from Release to Debug.

Xcode 3 Feature: Version Control Repository Access

2008-01-08T16:10:00.000-05:00

Xcode 3 adds support for configuring and viewing version control repositories. With Xcode 3 you can import projects and checkout files inside Xcode. All you have to do from the command line is create the repository. This article will show you how to take advantage of Xcode 3's enhanced version control capabilities. One word of caution. If you hated Xcode's version control support in earlier versions of Xcode, you'll want to stick with the command line. Xcode 3 repository features are a little flaky.

Xcode supports Subversion, Perforce, and CVS. I'm going to focus on Subversion because Mac OS X 10.5 ships with Subversion, and CVS seems to be losing popularity with developers.

Step 1: Create the Repository

If you haven't done so already, open the Terminal application and create a repository by running the svnadmin create command. I have detailed instructions you can read (PDF) on creating a repository if you need them. One thing to note is that because Mac OS X 10.5 ships with Subversion, you don't have to install it, and in Mac OS X 10.5 Subversion is in /usr/bin instead of /usr/local/bin.

Step 2: Configure Your Repository

Before you can take advantage of Xcode's repository features, you must configure your repository in Xcode. Launch Xcode and choose SCM > Configure SCM Repositories. A window similar to the following figure will open:

Click the + button to add a repository. You will be asked to name the repository and specify what version control system you're using.

Now you must specify the URL for the repostiory. A local repository's URL starts with file:// and follows with the path to the repository on your hard drive. If the path you specify does not show up in the Path field, you'll have to enter the path to your repository in the Path field.

I have not tried configuring a remote repository, but Xcode's repository configuration window has Host, Port, User, and Password fields. I assume you would fill these fields to configure a remote repository. If you're going to connect to a remote repository using SSH, click the SSH tab in the window.

Click the OK button, and you've configured the repository.

Step 3: Open the Repositories Window

Choose SCM > Repositories to open Xcode's repositories window, which you can see in the figure below. The repositories window lets you examine the directories inside your version control repositories. Select a repository from the list on the left to examine that repository's directories. Some things you can do from the repositories window is import projects, check files out of the repository, create directories, move directories, and delete directories.

If you've created a fresh repository, I strongly recommend creating a directory inside the repository and storing your projects inside that directory. In my experience using Xcode's repository features on a fresh repository, I noticed Xcode let me add only one directory to the root of the repository. Any additional directories I tried to create were created inside the first directory I created. This is why I recommend creating a directory, naming it something like Projects, and import your individual Xcode projects into the Projects directory.

If you have a repository that you've been using for some time, you'll see directories inside the repository root for the projects you have in your repository. If you try to add or import a directory to the repository root, the directory will get added to one of the subdirectories inside the root. There are two solutions.

First, you can fire up Terminal and create a directory from the command line using the svn mkdir command. I had difficulty getting my created directory to appear in the repositories window, but after a few attempts I did get the directory to appear. Second, you can create a fresh repository for your new projects, add a Projects directory to the new repository, and use the new repository for any new projects you want to place under version control.

Step 4: Import the Project

Before importing a project, you must create an Xcode project and move the project's files to a folder. If you follow Subversion conventions, you'll go to your project folder in the Finder and add three folders named branches, tags, and trunk. Move your project files to the trunk folder.

To import a project, select the directory in the repositories window where you want to import the project (If you're following along, this will be the Projects directory you created in Xcode's repositories window) and click the Import button. An Open File dialog opens. Navigate to your project folder, type a comment, and click the Import button.

There should be a directory inside the Projects directory with the name of your project. Inside the project name directory should be the branches, tags, and trunk folders. The trunk folder should contain your project's files. If these folders don't show up, click the Reload button to refresh the repositories window.

Step 5: Check Out Files

After importing a project, you want to check out the source code files in your project. Select your trunk folder in the repositories window and click the Checkout button. A dialog box opens asking you where you want to store the checked out files on your hard drive. Navigate to where you want to store the checked out files. Normally you will store the checked out files in a folder inside your Xcode project's folder. Click the Checkout button. You'll be asked if you want to open the Xcode project. Open it if you want.

Step 6: Turn on Version Control

Although you've imported a project and checked out files, you still have to tell Xcode to use version control for the project you imported. Open the Xcode project (the project file you checked out in Step 5, not the original one you created in Xcode). Select the name of the project from the Groups and Files list and click the Info button on the project window toolbar. An information panel will open. Click the General button in the information panel. Choose your repository from the SCM Repository pop-up menu, and you're ready to use version control with Xcode in Mac OS X 10.5.

Xcode 3 Change: New Template Locations

2008-01-04T15:35:00.000-05:00

If you create your own Xcode project and file templates, you should know that Apple changed the location for templates in Xcode 3. For your project templates to show up in Xcode's list when you create a new project, make sure your templates are in the following location:

Developer/Library/Xcode/Project Templates

File templates need to be in the following location:

Developer/Library/Xcode/File Templates

Xcode 3 Change: No ZeroLink

2008-01-03T16:20:00.000-05:00

Apple removed ZeroLink in Xcode 3, which makes my ZeroLink post obsolete for those of you using Xcode 3. Apple says it improved the speed of the linker in Xcode 3 so ZeroLink is no longer needed.

For the vast majority of developers, getting rid of ZeroLink is a good thing. When you use Xcode 3 to build your project, you will know if you have any link errors. No more Build Succeeded messages followed by crashes and cryptic error messages when your application runs. Another bonus is that you will be able to run the debug versions of your programs outside of Xcode and run them on other people's Macs.

Setting Up SDL with Visual C++ 2008 Express

2007-12-27T13:15:00.000-05:00

Microsoft recently released Visual Studio Express. I wanted to see if my SDL setup instructions for Visual C++ 2005 Express (PDF) worked with Visual C++ 2008 Express so I installed Visual C++ 2008 Express and went through my instructions. The good news is Microsoft did not make a lot of changes in Visual C++ 2008 Express so most of the instructions still apply. There are two differences.

Visual C++ 2008 Express Contains the Win32 SDK

Unlike Visual C++ 2005 Express, Visual C++ 2008 Express ships with the Windows Platform SDK, also known as the Win32 SDK. Visual C++ 2008 Express's Win32 SDK support means you don't have to install the SDK separately, and you don't have to modify any files to get Win32 support.

If you're running Visual C++ 2008 Express, you can skip over the Installing the Windows Platform SDK, Updating the Visual C++ Properties File, and Updating the Application Wizard's Settings File sections in my instructions.

The Path to the Win32 SDK is Slightly Different

In the section Telling Visual C++ Where to Find Your SDL Headers and Libraries, I said the path to the Win32 SDK was the following path:

C:\Program Files\Microsoft Platform SDK

If you install Visual C++ 2008 Express, you'll find the Win32 SDK at the following path:

C:\Program Files\Microsoft SDKs\Windows\v6.0A

The v6.0A is the Win32 SDK version. If you're reading this in the future, the version number may change.

I've Installed Xcode 3

2007-12-26T19:20:00.000-05:00

I installed Mac OS X 10.5 and Xcode 3 last night so I can now answer Xcode 3 questions. As I spend more time with the new Xcode Tools, I will take note of changes Apple made in Xcode 3 and write about them here.

Changing SDL's Working Directory on Mac OS X

2007-12-11T15:45:00.000-05:00

The Mac OS X version of SDL sets the working directory to the directory containing the application bundle. This default behavior makes loading images and sounds more difficult because the images and sounds most likely reside in the application bundle's Resources folder. What would be nice would be to set the working directory to the Resources folder. How do you do this?

You change the working directory by modifying the method -setupWorkingDirectory: in the file SDLMain.m. You'll want to change the code in SDLMain.m in SDL's Xcode templates so your changes take effect for any new SDL projects you create. Just to be safe, you should comment out the original code or save a copy of it so you can go back to the original if things go wrong. Enter the following code in the -setupWorkingDirectory: method:


NSString *resourcePath = [[NSBundle mainBundle] resourcePath];
[[NSFileManager defaultManager] 
changeCurrentDirectoryPath:resourcePath];

Thanks to Keith Bauer, aka OneSadCookie, for the source code to change the working directory.

New Article: Playing Audio Files with QTKit

2007-12-06T12:55:00.000-05:00

I have a new article on my website that explains how to load and play audio files using the QTKit framework. It should be especially helpful to any Cocoa developer who wants to loop an audio file because information on looping was hard to find in Apple's QTKit documentation.

I Don't Have Leopard Yet

2007-10-29T16:00:00.000-05:00

Because I don't have Leopard yet, I don't have Xcode 3 so I can't answer your Xcode 3 questions. You can still ask them if you want, if you don't mind the response "I don't know". Apple has an Xcode mailing list where you can ask Xcode 3 questions as well as questions on other Apple developer tools like Interface Builder.

I will post on the blog when I get Leopard, also known as Mac OS X 10.5.

New Article: Mac Game Programming Roadmap

2007-10-11T16:15:00.000-05:00

I have a new article available that provides an overview of the technologies to learn to write Mac games. The article was motivated by a discussion that has been brewing on Apple's game development mailing list for several list. The discussion revolved around Apple's lack of support for games, and one complaint was that Apple did not have a game library like DirectX. Without a game library getting started with Mac game development can be difficult because he or she may not know where to begin. My article helps them know where to begin. If you're new to Mac game development, check out the article.

Changing the Application Name for an Xcode Project

2007-09-10T14:20:00.000-05:00

Note: I got about 95% finished with this post when I realized it should be on the Xcode Tools Tips page. Because I was almost finished, I decided to also post it on the blog.

When you create an Xcode project, Xcode uses the project name as the title of whatever it builds. If you create an Xcode application project named MyProject, Xcode will create an application named MyProject when you build the project.

Suppose you're working on your application for a few weeks when you discover the perfect name for your application. You change the name of your project from MyProject to PerfectName, clean your project, and rebuild it. You expect to find an application named PerfectName in your build folder, but the application is still called MyProject. How do you get Xcode to build the project so the application name is PerfectName?

The answer is to modify the Product Name build setting, which you can find in the Packaging build settings collection. Product Name is the name of what Xcode builds, such as an application, a framework, or a library. Xcode initially uses the project name as the product name so when you look at the Product Name build setting, it will most likely be blank. Change the value of the Product Name to what you want, which would be PerfectName in this ongoing example.

When you change the Product Name build setting, you'll want to change it for the target, not a single build configuration. Changing the Product Name build setting for the target makes sure the change takes effect for all build configurations.

Setting up Visual C++ on Windows Vista

2007-08-20T18:55:00.000-05:00

I have instructions on setting up Visual C++ 2005 Express for SDL and OpenGL on my OpenGL 2D book site. I based those instructions on what I had to do to set up Visual C++ on my brother's computer running Windows XP. When I used the instructions to set up Visual C++ on my Windows Vista virtual machine, a major problem occurred. Visual C++ crashed every time I tried to add an existing file to a project. The crashes occurred because I hadn't installed the necessary service packs.

There are two service packs you must install for Visual C++ to work with Vista. The first is Visual C++ 2005 Express Service Pack 1. The second is Visual Studio 2005 Service Pack 1 Update for Windows Vista. Both of these service packs can be downloaded at Microsoft's developer site.

Moving a Subversion Repository to a New Computer

2007-08-17T23:35:00.000-05:00

I recently got one of the new iMacs, and I had to move my local Subversion repository to the new Mac. Getting the repository to the new Mac was a little tricky. Most of the Subversion tutorials on the Internet deal with creating a repository from scratch so I figured an article on moving a Subversion repository to a new computer would help people.

Moving the Repository

Moving a repository to a new computer requires three steps.

Dump the repository's contents to a file.
Create a repository on the new computer.
Load the repository with the contents of the dumped file's contents.

Run the command svnadmin dump to dump the contents of a repository to a text file. Navigate to the directory above the repository, and run svndadmin dump.

svnadmin dump RepositoryName > DumpFile

Running svnadmin dump like I just did will write the contents of your repository to a file called DumpFile. Ideally you would dump the repository contents before you get your new computer and copy the dump file to your new computer. But I was able to copy my repository folder to the new computer and run svnadmin dump on the new computer.

After creating the dump file, run the command svnadmin create to create a new repository. Navigate to where you want the repository to reside and enter the following command:

svnadmin create RepositoryName

Now it's time to fill the newly created repository with the contents of the dump file. Run the command svnadmin load to fill the repository.

svnadmin load RepositoryName < DumpFile

Now you've managed to copy the repository over to the new computer.

Changing the Repository's Path

After recreating my old repository, I opened an Xcode project that was in the repository to see if the version control information was appearing in Xcode. The only information that was appearing was the files' local revision numbers. There was no information on previous versions of the project's files.

The cause of the problem was the repository path on the new computer did not match the path on the old computer. I needed to tell the files in the repository the new path to the repository.

The svn switch command accomplished this task. To tell the files the new repository path, move to the directory where the project's files reside and run the svn switch command using the --relocate option. When using the --relocate option, you first supply the old repository path, then the new path.

svn switch --relocate /Path/On/Old/Computer /Path/On/New/Computer

After running svn switch, all the version control information began to appear in Xcode.

SDL 1.2.12

2007-07-31T21:50:00.000-05:00

The latest version of SDL, 1.2.12, is available to download from the SDL website. Anyone using Mac OS X and supporting joysticks in their game should download the update because it fixes a joystick calibration bug. When starting a game, SDL would record joystick axis events when the joystick was not moved, causing movement in the game with no joystick movement. The only way to stop the unwanted movement was to move the joystick up, down, left, and right. The 1.2.12 update eliminates the unwanted movement, making joysticks work the way you would expect on Mac OS X.

Reducing Xcode's Window Clutter

2007-06-20T21:15:00.000-05:00

If you do a lot of work in Xcode, your desktop can quickly become cluttered with windows, which can make finding the window you want difficult. This post shows you what you can do to reduce the number of open windows in Xcode.

Grouped Editor Windows

When you open an editor window by double-clicking a source code file in the project window, you will notice a toolbar button in the upper right corner of the window. The button's text will say either Grouped or Ungrouped. Clicking the button changes the text from Grouped to Ungrouped and vice versa.

Grouped editor windows tell Xcode to open only one editor window. When you double-click a source code file in the project window, Xcode places the contents of the file in the single editor window. Ungrouped editor windows tell Xcode to open a new editor window every time you double-click a source code file in the project window. Grouping editor windows eliminates a lot of window clutter.

Editing in the Project Window

If a single editor window is too much clutter for you, you can edit source code in the project window. Click the Editor button in the project window toolbar to open an editor in the project window's detail view. Clicking the Editor button a second time brings back the original detail view.

All-In-One Layout

The first two tips eliminate the clutter of editor windows. But Xcode's default layout still creates lot of external windows: run log, debugger window, build results window, search results, and SCM results. How do you keep all these windows from opening? The solution is to switch to Xcode's All-In-One layout, which places all the external windows in the project window.

To switch to the All-In-One layout, open Xcode's preferences window by choosing Xcode > Preferences. Click the General button in the preferences window toolbar. Choose All-In-One from the Layout pop-up menu. The following screenshot shows what the All- In-One layout looks like.

The All-In-One layout looks similar to the default layout, but you will notice a Page area in the upper left corner of the project window with three buttons. The left button is the Project page, which looks like the default layout, but with two tabs for search results and SCM results. The center button is the Build page, which gives you access to the run log and build results window. The right button is the Debug page, which gives you access to the debugger window.

New Xcode Tip: Supplying Launch Arguments for Command-Line Programs

2007-05-31T15:57:00.000-05:00

I added a tip to the Xcode Tools Tips page on supplying launch arguments for command-line programs from Xcode. This information is tucked away in the excerpt from the Xcode chapter, but it's difficult to find. I saw a question about supplying launch arguments on a message board, and another person emailed me about it. When multiple people have the same question, it makes sense to add a tip so everyone can benefit.

New Xcode Tip: Changing the Executable Name

2007-05-16T16:45:00.000-05:00

I added a new tip to the Xcode Tools Tips page on changing the executable name in your Xcode projects. If you don't want to read the whole tip, I can summarize it in one sentence. Change your target's Product name build setting, which is part of the Packaging collection.

New Bundles Article

2007-05-10T01:39:00.000-05:00

I have a new article on bundles available. It introduces bundles, focusing on application bundles. After reading the article, you will know how to create a bundle, add files to the bundle, and retrieve files from the bundle.

Leopard Delay a Blessing for Me

2007-04-23T15:23:00.000-05:00

Apple did me a favor as a writer by delaying the release of Mac OS X 10.5 from June to October. With a June release I would have had a difficult decision to make: delay updating Xcode Tools Sensei until I finished the OpenGL book, or delay development on the OpenGL book to update the Xcode book. Apple gave me another four months to finish the OpenGL book.

All updates for Xcode 3 and Leopard will come in a new edition of Xcode Tools Sensei. Xcode and Interface Builder are going to have major updates. Trying to juggle Xcode 1.x, 2.x, and 3 in one text would be difficult for me to write and you to read. I also will have to take a bunch of new screenshots so it makes sense to have two versions of the book: the current version that supports Xcode 1.x and 2.x, and a new version specifically for Xcode 3. The electronic edition of the Xcode 3 version would be available at a discount for everyone who has the current version of the book.

Skim PDF Viewer

2007-04-04T15:25:00.000-05:00

Skim is a free, open-source PDF viewer for Mac OS X. Mac OS X comes with Preview, which views PDF files, and Adobe Acrobat Reader is freely available so what makes Skim special? Skim has features that make reading technical articles and academic papers easier.

The first of these features is the ability to add notes to a PDF document. It's the electronic equivalent of adding sticky notes to a paper document. When you're reading difficult material, being able to make notes to yourself helps in understanding the material.

A second useful feature is the ability to highlight areas of text by putting a circle or box around it. A third feature is snapshots, which let you keep important pieces of a document in easy reach.

Skim is at version 0.2, which means it's far from a finished product. But if you read a lot of PDF technical articles, you should give Skim a test drive.

Using Saturn on Intel Macs

2007-04-02T02:15:00.000-05:00

I read a post on Apple's performance and optimization mailing list that tells you what to do to use Saturn on Intel Macs. This information may be useful to some of you so I am writing about it here.

To use Saturn to profile your code, you must compile your code with either the -pg compiler flag (Generate Profiling Code build setting in Xcode) or the -finstrument-functions compiler flag. The -pg compiler flag is the flag most people use, but Apple hasn't added the support for -pg on Intel Macs yet so using the -pg flag won't allow you to run your code with Saturn on an Intel Mac.

The solution is to use the -finstrument-functions flag to compile your code. I didn't see an Xcode build setting for this flag so you'll have to add the flag to the Other C Flags or Other C++ Flags build setting in Xcode.

I don't have an Intel Mac so I can't test this for myself, but the information came from an Apple engineer so I will assume the information is accurate.

OpenGL Book Progress Report for March 2007

2007-03-30T14:43:00.000-05:00

I haven't posted anything about the OpenGL book for a while, but I am writing to let you know I am still working on it. Progress has been excruciatingly slow, which has been very frustrating to me. On the code front, I've been working on the physics code. On the writing front, I have a lot of material written on several chapters, but I still don't have a finished chapter. Whenever I write about something, it brings up several additional topics I have to write about. When I write about those topics, it brings up more things to write about, which makes finishing difficult.

I'm Changing Website Hosts

2007-02-28T16:57:00.000-05:00

I have started moving the Me and Mark Publishing website to a new host. Everything should be transferred within the next 1-2 days. Hopefully there won't be any problems. I will add an item to the Latest News section about the switch. If you see the item on the Me and Mark Publishing home page, you're viewing the site with the new host.

Seeing Xcode's Build Errors

2007-02-19T15:10:00.000-05:00

When you build an Xcode project, Xcode tells you whether or not the build succeeded. If the build succeeded, that's all you need to know, but if the build failed, you want to know what the errors are so you can fix them. Xcode has two places to look at your errors: the Errors and Warnings smart group and the build results window.

Errors and Warnings Smart Group

In the project window's Groups and Files list, you will see the Errors and Warnings smart group. Select the Error and Warnings group and the project window shows the build errors. Double-clicking an error or warning takes you to the line of code where the error occurred.

Build Results Window

When you need to see more detailed information about your build, use the build results window. Choose Build > Build Results to open the build results window. The build results window has three sections. The top section is the build results, which shows the high-level build steps. The middle section is the build transcript, which shows the low-level steps Xcode takes to build your project. The bottom section is the editor. Selecting an error from the build results or the build transcript shows the line of code in the editor where the error occurred.

Showing the Build Transcript

If you open the build results window for the first time, you won't see the build transcript. The build transcript is initially invisible, and you must tell Xcode to show it. Below the build results are four small buttons. Click the third button to show the build transcript.

Writing C++ Programs on Mac OS X

2007-01-31T20:35:00.000-05:00

A frequently asked question on Mac programming forums is "Can I write C++ programs on Mac OS X?". Yes, you can write C++ programs on Mac OS X

Install the Xcode Tools

The Xcode Tools contain everything you need to write Mac OS X applications, including C++ programs. Every copy of Mac OS X contains the Xcode Tools. If you have Mac OS X 10.4, there should be an item called Xcode Tools on the Mac OS X DVD. This item contains the installer. Older versions of Mac OS X that ship on multiple CDs contain either an Xcode Tools or Developer Tools CD.

Apple frequently updates the Xcode Tools so the version that shipped with your copy of Mac OS X is most likely not the most recent version. If you have a broadband Internet connection, I recommend going to Apple's developer page and signing up for a free ADC membership. After signing up for an ADC membership, you can download the most recent version of the Xcode Tools.

One common concern people have when installing the Xcode Tools is the size of the install. The easy install of the Xcode Tools is over 1.5 GB, which is overkill if all you want to do is learn C++. You can perform a custom install of the Xcode Tools to reduce the size of the install. If you are low on disk space, the easiest way to save space is to not install the developer documentation. The developer documentation takes about 1 GB of disk space, and you can view all the documentation online anyway.

Writing Standard C++ Programs

The people most likely to ask if they can write C++ programs on Mac OS X are Mac-using college students who are taking a class on C++ programming. C++ programming classes normally teach standard C++, which will run on most operating systems, including Mac OS X.

To write a standard C++ program with Xcode, you must create a C++ Tool project. C++ Tool projects are used to write command-line programs without a GUI, which makes programming easier. You can read an article on the Xcode Tools Sensei page that contains detailed instructions on creating and building a C++ Tool project.

Writing C++ GUI Programs

After learning C++ you may want to use your newfound knowledge to write Mac OS X GUI programs. You have three options for writing Mac GUI applications in C++. First, you can use Cocoa, writing your user interface code in Objective C and the rest of your code in C++. You must give your Objective C files the extension .mm, which tells Xcode to treat them as Objective C++ files. Objective C++ lets you mix C++ and Objective C code in the same source file.

Second, you can use Carbon, which is Apple's C API for writing GUI applications. If you choose to use Carbon, you may want to look into Nano, an open-source C++ framework built on top of Carbon.

Third, you can use a C++ cross-platform GUI framework like Qt or wxWidgets. I haven't used either of these frameworks, but you should check them out if you are interested in supporting Linux and Windows as well as Mac OS X.

TextWrangler and Interpreted Languages

2007-01-15T14:42:00.000-05:00

TextWrangler is a free text editor for Mac OS X. It also happens to be a nice development environment for interpreted languages, especially for Perl, Python, and Ruby programming.

TextWrangler's Advantage over Xcode for Interpreted Languages

Xcode is designed for compiled languages like C++ and Java, not interpreted languages like Python and Ruby. You can create an external build system project in Xcode, but it is not very useful for interpreted languages because there is nothing to build for interpreted languages. You have to run the Terminal application and launch your program from the command line using your language's interpreter.

TextWrangler's shebang (#!) menu allows you to run Unix scripts from TextWrangler so you don't have to launch Terminal. TextWrangler has built-in support for Perl, Python, and Ruby, which means you can run and debug Perl, Python, and Ruby programs from TextWrangler. You can use TextWrangler to run programs in other interpreted languages, but you can't debug them using TextWrangler's Run in Debugger menu item.

Creating and Running a Program with TextWrangler

Writing and running code in interpreted languages is easy in TextWrangler. The following steps show you how to write a simple Ruby program with TextWrangler:

Choose File > New Text Document.
At the bottom of the document window are three pop-up menus. The left menu should say (none). Choose Ruby from the left pop-up menu. This tells TextWrangler that you are writing a Ruby program, which turns on Ruby syntax highlighting and enables the Run in Debugger menu item.
Write your code. For a Hello World program, enter puts "Hello World".
Choose #! > Run to run the program.

The instructions for Perl and Python are similar. For Step 2 you would choose either Perl or Python from the pop-up menu and write Perl or Python code instead of Ruby.

If you are using another interpreted language, the first line of code must specify the path to the interpreter.

#!/path/to/interpreter

The #! sequence is the start of a Unix script.

Using TextWrangler with Xcode

Although you don't need Xcode for small projects if you use TextWrangler, Xcode has its place for larger projects. You would use Xcode for project organization and version control and use TextWrangler to write the code and run the program. The Xcode Tools Tips page has a tip on using external editors with Xcode.

ZeroLink

2007-01-08T16:06:00.000-05:00

I read many posts on Mac programming message boards about problems that end up being caused by ZeroLink. Responding to these posts gets tiresome after a while so I decided to write about ZeroLink. In this post I explain what ZeroLink does, the problems it causes, and how you can turn it off so it doesn't cause you problems.

What ZeroLink Does

Before I explain what ZeroLink does, I should explain how Xcode normally builds C, C++, and Objective C projects. When you tell Xcode to build your project, the compiler compiles each source code file, creating an object file for each source code file. After compiling each file the linker links each object file along with the libraries and frameworks you're using to create an executable file you can run.

As its name suggests, Xcode skips the linking stage when you build with ZeroLink. When you run your program built with ZeroLink, Xcode links object files when your program needs them.

What is the advantage of using ZeroLink? It makes building your project go faster. If your project has many source code files, ZeroLink can speed build times significantly. During development you're going to build your project many times so faster build times save you time.

ZeroLink's Dark Side

ZeroLink's build time savings have a cost. The cost is you can get bizarre program behavior, and the cause of this behavior can be difficult to find. There are two common problems ZeroLink causes. First, because ZeroLink skips the linking stage, you won't find any linker errors when you build your project. The error appears when you run the program in Xcode, and your program crashes.

Second, your program won't launch when you move the executable or try to run it on another Mac. Projects built with ZeroLink can be run only inside Xcode. Because ZeroLink doesn't do any linking, the executable file is just a shell. When you move the executable file and try to launch it, nothing happens because there's no code inside the executable file. The code is in the object files that haven't been linked.

The Cause of Confusion

ZeroLink-related problems occur most often for people new to Xcode, and it's not their fault. When you create a new Xcode project, Xcode sets the project's active build configuration (the configuration it will use when you build the project) to the debug configuration. The debug configuration initially enables ZeroLink. What this means is if you create an Xcode project, add code to the project, and build the project, you're building with ZeroLink, whether you intended to or not.

Most Xcode beginners do not intend to use ZeroLink and have no need for it. Unless you have a large project, the problems ZeroLink causes surpass the time saved by not linking. While ZeroLink has its place, most developers are better off not using it, and Apple would be better off turning off ZeroLink initially.

Turning off ZeroLink

Because Apple enables ZeroLink initially, it is up to you to turn it off. If you're running Xcode 2.2 or later, the easiest way to turn off ZeroLink is to choose Build > Allow ZeroLink. Make sure there is no check mark next to the menu item. No check mark means ZeroLink is turned off. When you turn off ZeroLink using this method, you can't use ZeroLink for any project. If you decide you want to use ZeroLink in the future, choose Build > Allow ZeroLink to give yourself the capability of turning ZeroLink on or off on a project by project basis.

If you're running an earlier version of Xcode, you must turn off the ZeroLink build setting for each project. The ZeroLink build setting is in the Linking build settings collection.

Linking External Libraries and Frameworks in Xcode

2007-01-03T01:05:00.000-05:00

As long as you stick with the Apple-supplied frameworks that reside in System/Library/Frameworks (Cocoa, Carbon, OpenGL, QuickTime, etc.), linking in Xcode is pretty simple. Add the framework to your project, and you're done.

Things get a little more complicated when you want to use other libraries and frameworks in your code. If you're new to Xcode, you may get a ton of undefined symbol linker errors when you build your project, with the undefined symbols being in the the libraries and frameworks you want to use. These errors mean the linker can't find the symbols. How can you eliminate these errors?

Add the Libraries and Frameworks to Your Project

It sounds obvious, but make sure you have added the external libraries and frameworks to your project. If you don't add them, your project will not link.

Add Search Paths

If you have added the libraries and frameworks to your project and you still get undefined symbol errors, the most likely cause is the linker can't find the libraries and frameworks. What you need to do is add search paths for the libraries and frameworks you're using.

Xcode has a Search Paths build settings collection. This collection lets you add search paths for libraries, frameworks, and header files. To add a search path, select the appropriate build setting and click the Edit button. A sheet will open. Click the + button in the sheet to add a search path, and click the OK button when you're done.

Linker Flags

Adding search paths eliminates most linker errors, but when it fails, you can add linker flags to the project. To add linker flags go to the Linking build settings collection. The Other Linker Flags build setting lets you manually add flags the linker will use when building your project.

If you still get linker errors, you're in for a long, frustrating search for a solution.

Updated Tip on Changing the Compiler

2007-01-02T01:37:00.000-05:00

I updated the tip on the Xcode Tools Tips page that deals with changing the compiler Xcode uses to build your project. The updated tip tells you to add the build settings GCC_VERSION_ppc and GCC_VERSION_i386 instead of changing rules for the target. There currently is no need for the GCC_VERSION_i386 setting because Xcode projects use gcc 4 as the default compiler and you can't build for Intel with anything earlier than gcc 4. But the setting will come in handy in the future when Xcode ships with a newer version of gcc.

There was nothing technically wrong with having a target rule that specified the compiler to use, but it was overkill when all you want to do is compile with an earlier version of gcc. Adding the GCC_VERSION_ppc build setting is more straightforward.

Introduction to Xcode's Debugger

2006-12-18T13:44:00.000-05:00

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

2006-12-12T22:11:00.000-05:00

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

2006-12-03T15:22:00.000-05:00

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

2006-11-28T16:46:00.000-05:00

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

2006-11-27T01:04:00.000-05:00

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

2006-11-24T15:05:00.000-05:00

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

2006-11-22T21:59:00.000-05:00

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.