#ifdef vs #if (part 1)

In C/C++, it is common to compile some sections of code conditionally, e.g. debugging code, new untested features, cross-platform support, etc. The most common way to conditionally compile code is to use the #define preprocessor directive, then bracket conditionally compiled code with either #ifdef or #if.

Here is a simple #ifdef example:

#define DEBUG_SYSTEMX  //remove this #define to disable (e.g. comment-out this line).
//...
#ifdef DEBUG_SYSTEMX
    //... system x debugging code ...
#endif

And, here is a simple #if example:

#define NEW_FEATURE  1  //change 1 to 0 to disable
//...
#if NEW_FEATURE
    //... new feature code ...
#endif

Both of the above accomplish the same thing (conditional compilation), but they have different implications, e.g. the following will cause a compiler error when DEBUG_SYSTEMX is defined:

#if DEBUG_SYSTEMX  //BAD! #if WHEN IT SHOULD BE #ifdef
    // ... system x debugging code ...
#endif

However, when DEBUG_SYSTEMX is not defined, the code will be compiled out because the preprocessor treats undefined macros as 0 in conditional tests (which just so happens to match expectation).

The following would not work as intended, either:

#ifdef NEW_FEATURE  //BAD! #ifdef WHEN IT SHOULD BE #if
    // ... new feature code ...
#endif

Because NEW_FEATURE is always defined (to either 1 or 0), #ifdef NEW_FEATURE is always true, and the supposedly “conditional” code is always compiled.

So, both cases (#ifdef and #if) have problems if you accidentally use the incorrect test.

Of the two problems, using #ifdef when it should be #if appears to be the more serious error, since it can result in unintended code being included in a build, and no compiler errors or warnings will be generated (unless the conditional code happens to depend on other code which gets compiled out).

However, using #if when it should be #ifdef does the correct thing when the macro is undefined, and it generates a compiler error when the macro is defined (making it simpler to track down).

In this regard, #ifdef appears superior, but there are other considerations which should be taken into account. I’ll delve into some of those considerations (and cases you can’t do much about) in following posts.

How do you pronounce “Linux”?

I used to pronounce “Linux” with a hard “i” [as in "Aye, aye, captain!"], since it rhymes with the way we pronounce “Linus” in English.

Seems natural, doesn’t it?  I mean, considering that the creator’s name is “Linus”, right?

However, Linus Torvalds is Finnish, and in Finnish, the pronunciation of the “i” in his name is closer to a hard “e” (not a hard “i” as in English — his name is more like “Lee-noose” than the English “Lie-nuhs”), so he says that Linux is pronounced with a soft “i”. I assume that he feels a soft “i” is closer to a hard “e”, and I would agree — not that it matters at all what I think — he’s the creator of “Linux” and can pronounce it any way he wants — even if he decides the correct pronunciation is “Eunuchs”.

Did I go there?  Yes, I did.  Sorry, but look up more info on “Unix”, and you might be surprised…

On that note, Linus tells us how to pronounce Linux with a soft “i” in this YouTobe (and also his name — in 3 languages, no less — show off! j/k).  Not that this is anything new, but at least I’m glad I finally understand it.

Concurrent programming (part 1)

Intro

This is the first in a series of “thought pieces” about concurrent programming, especially as it relates to realtime applications. The motivation is for use in games, but this series is not game-specific.

The concurrent programming debate

There is a lot of interest (and griping) these days about the problems of writing efficient bug-free concurrent code (especially in the context of multicore systems). If you’re reading this, you probably already know why it has become a hot topic, so I’ll skip the explanation.

In any case, many people seem to feel the same way as guru Donald Knuth, author of the highly regarded The Art of Computer Programming series. This is what he said in a recent interview.

…I might as well flame a bit about my personal unhappiness with the current trend toward multicore architecture. To me, it looks more or less like the hardware designers have run out of ideas, and that they’re trying to pass the blame for the future demise of Moore’s Law to the software writers by giving us machines that work faster only on a few key benchmarks!

However, some people feel differently. Contrast Knuth’s statement with the following quote [from a lecture given in 1977] of another guru, John Backus, famous for being the “Backus” in BNF (Backus Normal Form, aka Backus Naur Form) formal language specification:

Surely there must be a less primitive way of making big changes in the [data] store than by pushing vast numbers of words back and forth through the von Neumann bottleneck. Not only is this tube a literal bottleneck for the data traffic of a problem, but, more importantly, it is an intellectual bottleneck that has kept us tied to word-at-a-time thinking instead of encouraging us to think in terms of the larger conceptual units of the task at hand. Thus programming is basically planning and detailing the enormous traffic of words through the von Neumann bottleneck, and much of that traffic concerns not significant data itself but where to find it.

To be fair, Backus was talking about changes in programming paradigms (specifically, proposing the use of functional programming), not parallel processing, but his point that there must be better methods of programming that transcend “word-at-a-time thinking” still seems relevant today.

Is the debate moot?

It may seem that debating concurrency is pointless. After all, we’ve started down the multicore path, and it seems like there is no turning back. That is probably true. For the foreseeable future, hardware will continue to increase in concurrency.

However, it is conceivable that software might remain procedural/imperative (e.g. if someone solves the long-standing problem of automating parallelization of sequential code). In addition, deciding how to approach the problem of concurrency depends on how we perceive the advantages and disadvantages of mimicking sequential code.

So, I do not think the debate is entirely moot. It is largely moot for hardware, but not for software, especially insofar as it affects our perception.

What’s my take on concurrency?

I agree with John Backus’s sentiment about the state of programming. A lot has changed in the 30+ years since his lecture, but even now, the status-quo of programming languages and methodologies feels limited by the intellectual “von Neumann bottleneck”.

In fact, I believe concurrent hardware will lead us to languages and methodologies which more naturally express solutions to realtime application problems. After all, realtime applications are about simulating large numbers of simultaneous activities. Simulation is naturally concurrent. All this time, we’ve been trying to simulate concurrency with sequential programs.

But, if simulation is naturally concurrent, why is concurrent programming so difficult?

The problem is that we don’t yet have adequate languages, tools, and methodologies for dealing with processor concurrency. Once those are developed, concurrency will be liberating. We will finally be able to write realtime applications the way we always wanted to (but didn’t know how).

Fortunately, the development of those languages, tools, and methodologies will be expedited by the fact that no one can ignore concurrency any longer.

[to be continued....]

Your prototype is your final product (part 1)

About 5 years ago, I worked at a division of Brooks Automation which built semiconductor wafer-sorting robots. My most interesting project was creating an experimental image-processing algorithm to detect a reference notch on a silicon wafer (which is used as a reference position for etching — we used it to locate ID numbers and barcodes). It was a challenging project — the reference notch is a rather small feature that only occupies a few pixels in a wafer image.

I was excited to demonstrate that the project should work in principle, so I threw together a prototype as quickly as I could. I made it very clear to everyone (including management) that this would be a prototype only, that it was unsuitable for mass-distribution, and that I would need some time after the demonstration to rewrite the code.

So, after about 3 weeks and with the help of some hardware tweaks (to provide a high-contrast image) I got it to detect the notch location about 90% of the time. Not bad for a first pass, but clearly it would need a lot of work to get that up to production quality (somewhere above 99%).

But, there was a problem…I had used a lot of “rapid prototyping” techniques (and hacking) to get things done as quickly as possible. I had used smart pointers instead of proper memory management, and as a consequence, there was a lot of memory waste (holding on to unnecessary images in the image processing chain) and thrashing/fragmentation (caused by allocation/deallocation of image buffers which could have been reused). The algorithm worked, but it was slow. I don’t recall exactly, but I think it took about 3 seconds to process an image.

But I thought “Not to worry, with some additional time to rewrite proper memory management routines, plus optimizations, that will easily reduce to half a second or less.”

The next day, my boss told me that we would use the code as-is.

I explained that the code was not ready for production, that I needed time to rewrite. I explained about the memory management problems and how optimization would require a different code structure. I also reminded him again that I had been upfront about the need to spend extra time for a rewrite (I had reminded him almost daily because I anticipated such a problem). He still wouldn’t budge and insisted that I continue with the current code base.

That’s when I learned the lesson which became the title of this post: Your prototype is your final product.

It’s a good thing to remember. Whenever you work on code (or engineer any product), what you think of as a prototype is likely to be seen as a final product by management. Once management sees visible results, they want it right away. And, in many cases, they just don’t understand the value of improving things that are “under the hood”. After all, what they see seems just fine to them, so what value could there possibly be in improvements?

[to be continued...]

Tryin’ ta git back ta duh bloggin…

As you can tell, there was a really long gap in my posting. During that interim, I had worked on several posts, but none of them were completed. There are a few reasons for that:

1. I like to make my posts as clean and clear as possible, so I tend to spend a lot of time writing them.
2. The posts I had been working on are quite long, so there is a lot that needs to be edited.
3. I’ve been trying to delve into topics that are not yet “solved” (e.g. parallel programming). I’m still trying to formulate my own thoughts on those topics, so I’m never sure how to present them.
4. I also write on topics that go against the grain of “accepted practice”. That requires compelling arguments to keep people from thinking I’ve gone bananas, e.g. a post about why innovation isn’t always a good thing… See, bet you’re thinking “bananas” already [you'll understand when I get to it].

Anyway, the end result is that I haven’t posted anything.

So, I’m going to get back to it by breaking up long articles into series of posts. That will probably be better, anyway. Who really wants to read a gigantic article all at once?

Now I just have to figure out a good way to link series together so they can be found as a unit (on the off chance you do like reading gigantic articles after all).

There is no rum in frustum

One of my co-workers has been finding (and sometimes correcting) typos in our code. One of the typos (which is in almost every game engine at one time or another) is “frustrum” instead of “frustum”. I suggested that we compile a list of common typos and title it “There is no rum in frustum”.

The last bug

Coworker: Hey, John. How’s that code going?

Me: Well, it’s looking pretty good. I just fixed the last bug we know about … And you know what that means, right?

Coworker: It’s done?

Me: Well, no … Not quite.

Coworker: What’s it mean, then?

Me: It means there’s a lot we don’t know.

So, what’s the difference…engine?

Today, I found this quote by Charles Babbage on Wikipedia:

On two occasions I have been asked … “Pray, Mr. Babbage, if you put into the machine wrong figures, will the right answers come out?” … I am not able rightly to apprehend the kind of confusion of ideas that could provoke such a question.

Now, there’s something any programmer can sympathize with!

USB Flash Drive

I finally picked up a 1 GB USB flash drive [actually, it was a few months ago, but I digress].

Maybe it’s because I’m an “old timer”, but 1GB in a tiny package at an “impulse buy” price point is just incredible. No wonder the 1.44 MB floppy disk is dead. This little flash drive holds almost as much data as 700 of those floppies, it’s small enough to leave on your keychain, and it’s far more durable.

Thinking even farther back, I remember when I loaded programs for my Atari 800 from a cassette tape! It took several minutes just to load a few dozen K of data. It was a big deal when I finally got a 5-1/4″ floppy drive. I got a special “double-density” drive which held about 180KB (you could flip the disk over to get another 180KB, for a total of 360KB)…So my flash drive holds almost as much as 3000 of those old floppies! Wow.

My “Production Diary” entry posted on Mercs 2 website

My “production diary” entry was posted on the Mercs 2 website about an hour ago. I tried to have a little fun with it, so we’ll see what people think…

SDL_pfont update

Although it has been slow-going, I have managed to make significant progress on SDL_pfont. The font rendering works, and the tool can process a bmp to generate an output image and an SDL_pfont data file.

There are a few more things I want to do before releasing it, though, for example:

• Verify that all code is ANSI C.
• Add command-line args for:
  • minimal spacing between glyphs in the output bmp, and
  • whitespace width
• Write some overview documentation (the source code is documented, but tool command-line parameters and basic do’s and don’ts should be covered).
• Create a decent sample font.

So, hopefully it won’t be that much longer before I have something that is ready for release…

GDC call for submissions

The GDC call for submissions just opened, and I’ve been thinking about presenting a lecture for GDC 2007. My current project at Pandemic Studios would make for a good presentation, but preparing a GDC lecture (along with a paper) is a huge time investment. First, you have to prepare a summary, then you work with a reviewer/editor to revise the summary, write a paper, and create a PowerPoint presentation. Then you have to practice the lecture, preferably in front of an audience. Preparing for my lecture on the Full Spectrum Warrior Camera System in 2004 seemed to eat up all my spare time, so I’ll have to think if over before making up my mind.

Giant List of Classic Game Programmers

I have to admit, I’ve got a soft spot in my heart for the good ol’ 8-bit days. My first computer was an Atari 800, and I had the greatest time learning how to program BASIC and assembly language, inspired by all the great games I played on that system.

For all of you nostalgic souls out there that haven’t yet found The Giant List of Classic Game Programmers, click your way to retro-Mecca now. Just don’t blame me should you forget to return from your pilgrimage. Look up your favorite oldies, find out who programmed/designed them, then see what else they created. You might be surprised about the connections you uncover.

When I get a chance, I’ll post about the list’s revelation that literally stunned me. It’s not anything I would expect to shock anyone else, and it probably reveals more about me than about the list, but hopefully you’ll enjoy reading about it anyway…

Until then…Happy time-hoppin’…

String hash identifiers

In the games industry, it is common practice to use hashes of strings as identifiers for objects. String hash identifiers are a useful compromise between the differences in human and computer "comprehension" — humans understand and remember string identifiers better than arbitrary numeric quantities, while computers operate most effectively with numbers.

CRC is one of the most common hashes, but there are other options, such as FNV. I prefer FNV because it is even simpler than CRC and doesn't require a lookup table as the typical CRC implementation does.

The advantages of using hashes are:

• Hash values are always the same data size no matter how long a string is.
• A primitive data type (typically a 32-bit unsigned int) can hold the hash.
• Equality/inequality comparison is fast.
• Less memory space is required than for strings.
• They make good indices into hash tables.

Like all techniques, string hash identifiers have disadvantages. Because a hash is just an arbitrary number with no intrinsic meaning, the only way to find the string a hash originated from is to look it up in a hash-to-string table. And that means you have to create a hash-to-string table if you want "reversibility". If the string was hashed without storing it in a lookup table, it may not be possible to determine the original string (though putting a conditional breakpoint in the code often works).

It is also necessary to be on the lookout for hash collisions (two different strings which hash to the same value). They are reasonably rare, but the data sets of many games are getting large enough that a few collisions will occur during the course of a project. Collisions can lead to obscure bugs which are hard to track down. Often, this can be caught in debug builds by checking for duplicate strings when inserting hashes into lookup tables. When a problematic collision is found, it can be fixed by renaming one of the items.

Even so, the advantages of string hash identifiers typically outweigh the disadvantages. I have worked on several projects that use this technique, and the consensus is that it has been worthwhile.

I'll be writing more on this topic soon…

E3 stuff

I know…over a week after E3 ends is a little late to be writing about it…

The exciting part

Mercenaries 2 was being shown to the press at our Pandemic (and Bioware) booth. I'm always excited when the project I'm working on is at the show. It's nice to meet people who are interested in what you're doing, especially after you've put in so much effort getting your game ready for the show.

Impression

My impression (which is shared by many attendees I spoke with) is that there wasn't anything that "blew me away". Sure, there were some especially nice looking games/trailers (e.g., Crysis, MGS4, Assassin's Creed) and some innovations (like the Wii controller), but there wasn't anything that seemed stand-out amazing.

My theory is that games have matured to the point where everyone is pretty much state of the art. So, most products have great graphics, fluid gameplay, outstanding SFX, etc. The people that are ahead of everyone else aren't that far ahead any more–there just isn't enough headroom left to make a giant leap.

Celebrity sighting

My celebrity sighting of the show…

I was standing near a kiosk when I notice security guards scurrying about. Then, I see some guy walking and a herd of people following him. I think to myself "He looks familiar…but who is he? Warren Spector? Why would so many people be tailing Warren?"

Then he walks by, just a few feet from me. I spot his nametag:

Steven Spielberg.

So, that explained the crowd (and the security). A pretty cool celebrity sighting in my book. Yeah, he was probably there to promote a game, but it was neat to spot him on the show floor.

I’ve finally made the Firefox switch

I've finally decided to make the Mozilla Firefox switch, leaving Internet Explorer in the dust.

Don't always trust your first impression

I had heard about Mozilla Firefox some time ago, but I didn't really take it too seriously. After all, IE was pre-installed and worked well enough…Switching to Netscape Navigator seemed more trouble than it was worth. And, Firefox is just a spin-off of Navigator, right? How much different could it really be?

THX Deep Note

Slashdot posted about The THX Sound, which details how the THX sound effect (affectionately known as "Deep Note") was created. Apparently, the guy wrote a 20,000 line C program to control an Audio Signal Processor (ASP). Sounds like way too much work by today's standards…but it was way back in '83 ! Wow, time sure flies. I wouldn't have guessed that THX was that old…

Pseudorandom number generators (PRNGs)

Here's a good article on PRNGs (specifically, the "LCG" variety).  My favorite is the 32 bit "super-duper" generator that simply multiplies the current value by 69069.  It's fast and also has one of the best distributions of the simple PRNGs.  Although this is not good enough for cryptography or scientific applications, it is just about perfect for games.

Gonna have to move my posts the hard way

It looks like I'm not going to have much luck moving my old posts to my new website by an automated method, so I'm going to start doing it by hand.  I hope I get the timestamps right…

SDL_pfont project kickoff

INTRO

If you haven't heard of it yet, SDL is a cross-platform 2D graphics library, which also includes a few other features, like mouse/keyboard input.

WHY MAKE ANOTHER SDL FONT SYSTEM?

There are many libraries that run on top of SDL. Among them are several font libraries. I have taken a look at all the ones I could find, but they seem to share the following drawbacks:

1. They include other libraries. Typically, they will at minimum require SDL_image , which then includes Zlib. It is also common to require some other special library (e.g., SDL_ttf requires FreeType).
2. The format is not very efficient to draw. Most font formats require pixel-by-pixel processing. It would be nice to just make one rectangular blit per glyph.

Please don't get me wrong. I'm not criticizing these libraries. Several of them are very good at what they do, e.g., SDL_ttf is good at letting you write code that uses TrueType fonts quickly and easily. But there should be a better option for games programming, where simplicity and speed take precedence.

That is why I'm beginning work on SDL_pfont. It addresses both of the above issues by splitting the project into:

1. A simple proportional font rendering system.
2. A tool that processes a source image to produce a font.

I plan to release SDL_pfont as open source (assuming I feel comfortable with the resulting code). Here are the requirements I'd like SDL_pfont to meet:

FONT RENDERING SYSTEM REQUIREMENTS

• ANSI C interface
• Simple data structures
• Does not require any libraries except SDL (and a few standard C routines).
• Uses BMP format for texel data (since SDL supports BMP natively)
• Font is stored in a disk format matching the memory format

TOOL REQUIREMENTS

• ANSI C preferred (I might use some simple "C++ is better C" constructs).
• Command-line utility
• A plain-text configuration file defines the expected actions
• Process a source BMP image to produce:
  • An output image containing the font glyphs
  • An output file containing the font data (in the target's native format)

CONCLUSION

And, that's it for now. I'll post updates as the project continues.