No, I would gather from the discussion that this just refers to the image, which is a bitmap. The bitmap will be read in by the program at runtime.
So rather than coding the sprite directly, you draw the sprite in some kind of photoshop style program and then save it as "raw" bitmap data. As long as you know the dimensions and exact format of the data, this is the easiest kind of image to process, because it does not have a header and is uncompressed.
Here's an example of what I mean by "format": a normal (non-transparent) bitmap contains 3 bytes per pixel. These occur in the file in order, row by row, from the top left corner. The data is said to be interleaved because it alternates Red value, Green value, Blue value (as opposed to organizing the file with 3 sections).
Some image software such as gimp will do an image dump into C code. For example, here is the first little bit of my current avatar. This was created by loading the jpg into gimp and resaving it with the extension .c instead of .jpg. I don't know what other image editors will do this -- it's actually of debatable value, since if you compile a few of these in it will increase the size of your executable substantially. It would be more normal, as I said, to save the image as .raw, in a separate file, and then read it in at runtime:
Code:
/* GIMP RGB C-Source image dump (CIAvatar.c) */
static const struct {
unsigned int width;
unsigned int height;
unsigned int bytes_per_pixel; /* 3:RGB, 4:RGBA */
unsigned char pixel_data[55 * 55 * 3 + 1];
} gimp_image = {
55, 55, 3,
"\0\0\0\0\0\0\0\1\0\0\1\0\0\1\0\0\1\0\0\1\4\0\0\7\0\0\16\0\0\14\1\0\0\11\6"
"\0\11\5\0\6\0\0\10\0\5\10\0\14\10\2\16\3\0\4\6\0\0\11\1\0\12\1\0\15\4\0\32"
"\16\0!\25\0&\34\0-#\0'\36\0""8.\0-\"\0*\36\0""1!\0%\25\0#\17\0\22\0\0\25"
"\6\0\10\0\0\3\0\0\0\2\1\1\2\4\0\1\2\0\0\2\11\11\13\1\0\4\0\0\2\4\4\6\2\7"
"\3\0\4\0\0\7\0\0\2\0\1\1\0\1\0\11\1\0\16\0\0\13\0\0\2\0\2\0\0\1\0\0\1\0\0"
"\1\0\0\1\0\0\1\0\0\1\0\0\0\5\0\0\11\2\2\16\0\0\11\1\0\0\3\0\0\11\4\0\12\3"
"\0\7\0\0\13\1\0\12\2\0\7\0\0\12\1\0<4!c[F\207\201i\234\226\200\212\205o\211"
"\211q\227\231\201\215\217w\216\216t\177~_\230\224q\230\223m\222\212f\241"
"\230y\204zac[H%\36\14\30\25\4\5\3\0\3\1\0\6\5\0\21\17\22\1\0\4\0\0\4\22\22"
"\24\0\1\0\0\2\0\0\5\1\0\2\0\0\2\0\1\0\0\1\0\5\1\0\13\0\0\7\0\0\2\0\1\0\0"
"\2\0\0\2\0\0\1\0\0\1\0\0\1\0\0\1\0\0\0\11\0\0\13\0\0\5\16\14\17\2\0\1\7\3"
"\4\3\0\0\4\0\0\17\14\0\7\3\0\15\4\0UK\15\301\265\213\253\243\214vppGFV\40"
"%B-:\\\32,P\36""4Y\17'K\37""6X\34""0U\35,S\37+U,5`\36&MCIcqrv\263\262\240"
"\261\255\207MF\30\25\13\0\10\0\0\6\0\0\2\0\12\4\5\12\0\1\2\0\3\0\0\3\0\0"
This goes on for another 300 lines. As you can see, directly coding an image would be very tedious.
.xpm images are C code, if you look at them in a text viewer instead of an image viewer, eg:
Code:
/* XPM */
static char *Toaster[] = {
/* columns rows colors chars-per-pixel */
"48 48 90 1",
" c #020202",
". c #0C0C0C",
"X c #141414",
Again, the only problem with this is you must compile it in to take advantage of the format.