Blitting and sprites

As far as Allegro is concerned, a bitmap and a sprite are the same thing, but to many people the two words imply slightly different things. The function draw_sprite() is called so rather than draw_bitmap() partly because it indicates that it uses a masked drawing mode (if it existed, you could expect draw_bitmap() to be a simple block copy), and partly for historical reasons. In Allegro 1.0 there were actually different structures for sprites and bitmaps, each with their own set of abilities. Allegro 2.0 merged these into a single more flexible structure, but retained some names like draw_sprite().

In wider (non-Allegro) terms, the two words can mean quite different things. Generally you can say that sprites are a subset of bitmaps, but even that isn't true in 100% of cases.

BITMAP: a widely accepted term that will be understood by anyone even remotely connected with computer graphics. It simply means an image built up from a grid of pixels, ie. just about any picture that you are likely to come across on a computer (vector graphics formats are the exception, but those must be rendered into a bitmap format before they can be displayed by most hardware). A more accurate term but slightly rarer term with the same meaning is "pixmap" (pixel-map).

SPRITE: a particular usage of bitmapped images, restricted to video games (other types of programmer probably won't be familiar with this term). Originally on machines like the C64, sprites were a hardware feature that allowed a number of small bitmap images to be loaded into special registers, and they could then be superimposed over the main graphics display and moved around just by modifying the position register. They were used for the moving objects (player and enemy characters), and enabled the C64 to do much more impressive things than would have been possible if all the drawing had to be done directly by the puny CPU.

Later on, a lot of old C64 programmers upgraded to machines like the Atari ST, which didn't have any special sprite hardware, but they carried on referring to their main moving objects as sprites (the routine to draw such a thing would obviously be called draw_sprite()). A sprite is really just a bitmap graphic which is drawn onto the screen, but when you call it a sprite rather than a bitmap, this suggests it is a gameplay element that can move freely around the world rather than being a static part of the environment, and that it will be drawn in a masked overlay mode rather than as a solid rectangle (there is also a strong implication that a sprite will be animated by cycling through a number of frames, but that isn't always the case).

In recent years some people have started using "sprite" to refer to any character graphics, even if they are not in fact drawn as 2d bitmaps, eg. "this game uses 3d polygonal player sprites". This is a confusing misuse of the word (Doom uses sprites, Quake does not), but it does happen.

The origin of the term "blit" is also rather interesting. This was originally BitBlt, an abbreviation of BITmap BLock Transfer, which was a function designed (possibly) by the people at Xerox who did so much of the pioneering work on graphics display systems, and subsequently copied by virtually everybody doing computer graphics (the Microsoft Windows GDI still provides a BitBlt function with identical functionality to the original). This routine was a workhorse for all sorts of drawing operations, basically copying bitmap graphics from one place to another, but including a number of different ROP modes (Raster OPerations) for doing things like XOR, inverting pixels, etc. A whole family of related words grew up around the BitBlt function, but "blt" is impossible to speak (try saying "bltter" or "bltting" :-) so people added the vowel to make it easier to pronounce.

Therefore, the act of calling the BitBlt function came to be known as "doing a blit". The obvious next step was to rename the function itself to blit(), which generally took place at the same time as people decided to simplify the original, removing the different ROP modes on the grounds that they aren't needed for games coding and don't work well with anything higher than monochrome images in any case. This leaves us with a function called blit(), which is an abbreviation for "block transfer". A strong case could be made for calling this blot() instead, but somehow that just doesn't sound the same!

Anyway, all the routines in this chapter are affected by the clipping rectangle of the destination bitmap.


void blit(BITMAP *source, BITMAP *dest, int source_x, int source_y, int dest_x, int dest_y, int width, int height);

Copies a rectangular area of the source bitmap to the destination bitmap. The source_x and source_y parameters are the top left corner of the area to copy from the source bitmap, and dest_x and dest_y are the corresponding position in the destination bitmap. This routine respects the destination clipping rectangle, and it will also clip if you try to blit from areas outside the source bitmap. Example: 
      BITMAP *bmp;
      ...
      /* Blit src on the screen. */
      blit(bmp, screen, 0, 0, 0, 0, bmp->w, bmp->h);
      
      /* Now copy a chunk to a corner, slightly outside. /*
      blit(screen, screen, 100, 100, -10, -10, 25, 30);
You can blit between any parts of any two bitmaps, even if the two memory areas overlap (ie. source and dest are the same, or one is sub-bitmap of the other). You should be aware, however, that a lot of SVGA cards don't provide separate read and write banks, which means that blitting from one part of the screen to another requires the use of a temporary bitmap in memory, and is therefore extremely slow. As a general rule you should avoid blitting from the screen onto itself in SVGA modes.

In mode-X, on the other hand, blitting from one part of the screen to another can be significantly faster than blitting from memory onto the screen, as long as the source and destination are correctly aligned with each other. Copying between overlapping screen rectangles is slow, but if the areas don't overlap, and if they have the same plane alignment (ie. (source_x%4) == (dest_x%4)), the VGA latch registers can be used for a very fast data transfer. To take advantage of this, in mode-X it is often worth storing tile graphics in a hidden area of video memory (using a large virtual screen), and blitting them from there onto the visible part of the screen.

If the GFX_HW_VRAM_BLIT bit in the gfx_capabilities flag is set, the current driver supports hardware accelerated blits from one part of the screen onto another. This is extremely fast, so when this flag is set it may be worth storing some of your more frequently used graphics in an offscreen portion of the video memory.

Unlike most of the graphics routines, blit() allows the source and destination bitmaps to be of different color depths, so it can be used to convert images from one pixel format to another. In this case, the behavior is affected by the COLORCONV_KEEP_TRANS and COLORCONV_DITHER* flags of the current color conversion mode: see set_color_conversion() for more information.

See also: masked_blit, stretch_blit, draw_sprite, gfx_capabilities, set_color_conversion.
Examples using this: Available Allegro examples.
void stretch_blit(BITMAP *source, BITMAP *dest, int source_x, source_y, source_width, source_height, int dest_x, dest_y, dest_width, dest_height);

Like blit(), except it can scale images (so the source and destination rectangles don't need to be the same size) and requires the source and destination bitmaps to be of the same color depth. This routine doesn't do as much safety checking as the regular blit(): in particular you must take care not to copy from areas outside the source bitmap, and you cannot blit between overlapping regions, ie. you must use different bitmaps for the source and the destination. Moreover, the source must be a memory bitmap. Example: 
      BITMAP *bmp;
      ...
      /* Stretch bmp to fill the screen. */
      stretch_blit(bmp, screen, 0, 0, bmp->w, bmp->h,
                   0, 0, SCREEN_W, SCREEN_H);
See also: blit, masked_stretch_blit, stretch_sprite.
Examples using this: exalpha, exconfig, exscale, extrans.
void masked_blit(BITMAP *source, BITMAP *dest, int source_x, int source_y, int dest_x, int dest_y, int width, int height);

Like blit(), but skips transparent pixels, which are marked by a zero in 256-color modes or bright pink for truecolor data (maximum red and blue, zero green), and requires the source and destination bitmaps to be of the same color depth. The source and destination regions must not overlap. Example: 
      BITMAP *hud_overlay;
      ...
      /* Paint hud overlay on the screen. */
      masked_blit(hud_overlay, screen, 0, 0, 0, 0,
                  hud_overlay->w, hud_overlay->h);

If the GFX_HW_VRAM_BLIT_MASKED bit in the gfx_capabilities flag is set, the current driver supports hardware accelerated masked blits from one part of the screen onto another. This is extremely fast, so when this flag is set it may be worth storing some of your more frequently used sprites in an offscreen portion of the video memory.

Warning: if the hardware acceleration flag is not set, masked_blit() will not work correctly when used with a source image in system or video memory so the latter must be a memory bitmap.

See also: blit, masked_stretch_blit, draw_sprite, bitmap_mask_color.
Examples using this: ex12bit, expat.
void masked_stretch_blit(BITMAP *source, BITMAP *dest, int source_x, source_y, source_w, source_h, int dest_x, dest_y, dest_w, dest_h);

Like masked_blit(), except it can scale images (so the source and destination rectangles don't need to be the same size). This routine doesn't do as much safety checking as the regular masked_blit(): in particular you must take care not to copy from areas outside the source bitmap. Moreover, the source must be a memory bitmap. Example: 
      BITMAP *hud_overlay;
      ...
      /* Stretch hud overlay over the screen. */
      masked_stretch_blit(hud_overlay, screen, 0, 0,
                          hud_overlay->w, hud_overlay->h,
                          0, 0, SCREEN_W, SCREEN_H);
See also: blit, masked_blit, stretch_blit, stretch_sprite.
void draw_sprite(BITMAP *bmp, BITMAP *sprite, int x, int y);

Draws a copy of the sprite bitmap onto the destination bitmap at the specified position. This is almost the same as blit(sprite, bmp, 0, 0, x, y, sprite->w, sprite->h), but it uses a masked drawing mode where transparent pixels are skipped, so the background image will show through the masked parts of the sprite. Transparent pixels are marked by a zero in 256-color modes or bright pink for truecolor data (maximum red and blue, zero green). Example: 
      BITMAP *spaceship;
      ...
      draw_sprite(screen, spaceship, x, y);

If the GFX_HW_VRAM_BLIT_MASKED bit in the gfx_capabilities flag is set, the current driver supports hardware accelerated sprite drawing when the source image is a video memory bitmap or a sub-bitmap of the screen. This is extremely fast, so when this flag is set it may be worth storing some of your more frequently used sprites in an offscreen portion of the video memory.

Warning: if the hardware acceleration flag is not set, draw_sprite() will not work correctly when used with a sprite image in system or video memory so the latter must be a memory bitmap.

Although generally not supporting graphics of mixed color depths, as a special case this function can be used to draw 256-color source images onto truecolor destination bitmaps, so you can use palette effects on specific sprites within a truecolor program.

See also: draw_sprite_v_flip, draw_trans_sprite, draw_lit_sprite, draw_gouraud_sprite, stretch_sprite, rotate_sprite, draw_character_ex, draw_rle_sprite, draw_compiled_sprite, masked_blit, blit, bitmap_mask_color.
Examples using this: exsprite.
void stretch_sprite(BITMAP *bmp, BITMAP *sprite, int x, int y, int w, int h);

Like draw_sprite(), except it can stretch the sprite image to the specified width and height and requires the sprite image and destination bitmap to be of the same color depth. Moreover, the sprite image must be a memory bitmap. Example: 
      /* Create tunnel like effect. */
      for (step = 1; step < 16; step++) {
         int width = SCREEN_W / step;
         int height = SCREEN_H / step;
         stretch_sprite(screen, image, SCREEN_W / 2 - width / 2,
                        SCREEN_H / 2 - height / 2, width, height);
      }
See also: draw_sprite, stretch_blit, bitmap_mask_color.
void draw_sprite_v_flip(BITMAP *bmp, BITMAP *sprite, int x, int y);

void draw_sprite_h_flip(BITMAP *bmp, BITMAP *sprite, int x, int y);

void draw_sprite_vh_flip(BITMAP *bmp, BITMAP *sprite, int x, int y);

These are like draw_sprite(), but they additionally flip the image vertically, horizontally, or both, respectively. Flipping vertically means that the y-axis is reversed, while flipping horizontally means that the x-axis is reversed, between the source and the destination. This produces exact mirror images, which is not the same as rotating the sprite (and it is a lot faster than the rotation routine). The sprite must be a memory bitmap. Example: 
      if (key[KEY_RIGHT])
         draw_sprite(screen, hero_right, pos_x, pos_y);
      else if (key[KEY_LEFT])
         draw_sprite_h_flip(screen, hero_right, pos_x, pos_y);
      else
         draw_sprite(screen, hero_idle, pos_x, pos_y);
See also: draw_sprite, bitmap_mask_color.
Examples using this: exsprite.
void draw_trans_sprite(BITMAP *bmp, BITMAP *sprite, int x, int y);

Uses the global color_map table or truecolor blender functions to overlay the sprite on top of the existing image. This must only be used after you have set up the color mapping table (for 256-color modes) or blender functions (for truecolor modes). Because it involves reading as well as writing the bitmap memory, translucent drawing is very slow if you draw directly to video RAM, so wherever possible you should use a memory bitmap instead. Example: 
      /* Some one time initialisation code. */
      COLOR_MAP global_trans_table;
      create_trans_table(&global_trans_table, my_palette,
                         128, 128, 128, NULL);
      ...
      if (get_color_depth() == 8)
         color_map = &global_trans_table;
      else
         set_trans_blender(128, 128, 128, 128);

      draw_trans_sprite(buffer, ghost_sprite, x, y);

The bitmap and sprite must normally be in the same color depth, but as a special case you can draw 32 bit RGBA format sprites onto any hicolor or truecolor bitmap, as long as you call set_alpha_blender() first, and you can draw 8-bit alpha images onto a 32-bit RGBA destination, as long as you call set_write_alpha_blender() first. As draw_sprite() this function skips transparent pixels, except if the source sprite is an 8-bit image; if this is the case, you should pay attention to properly set up your color map table for index 0.

See also: draw_sprite, draw_lit_sprite, draw_trans_rle_sprite, color_map, set_trans_blender, set_alpha_blender, set_write_alpha_blender, bitmap_mask_color.
Examples using this: exalpha, exblend, exlights, extrans, exxfade.
void draw_lit_sprite(BITMAP *bmp, BITMAP *sprite, int x, int y, int color);

In 256-color modes, uses the global color_map table to tint the sprite image to the specified color or to light it to the level specified by 'color', depending on the function which was used to build the table (create_trans_table or create_light_table), and draws the resulting image to the destination bitmap. In truecolor modes, uses the blender functions to light the sprite image using the alpha level specified by 'color' (the alpha level which was passed to the blender functions is ignored) and draws the resulting image to the destination bitmap. The 'color' parameter must be in the range [0-255] whatever its actual meaning is. This must only be used after you have set up the color mapping table (for 256-color modes) or blender functions (for truecolor modes). Example: 
      /* Some one time initialisation code. */
      COLOR_MAP global_light_table;
      create_light_table(&global_trans_table, my_palette,
                         10, 10, 60, NULL);
      ...
      if (get_color_depth() == 8)
         color_map = &global_light_table;
      else
         set_trans_blender(40, 40, 255, 255);

      /* Lit the cape with a blueish light. */
      draw_lit_sprite(buffer, colored_cape, x, y, 64);
See also: draw_sprite, draw_trans_sprite, draw_gouraud_sprite, draw_lit_rle_sprite, color_map, set_trans_blender, bitmap_mask_color.
Examples using this: exblend.
void draw_gouraud_sprite(BITMAP *bmp, BITMAP *sprite, int x, int y, int c1, int c2, int c3, int c4);

More sophisticated version of draw_lit_sprite(): the 'color' parameter is not constant across the sprite image anymore but interpolated between the four specified corner colors. The corner values passed to this function indicate the strength of the color applied on them, ranging from 0 (no strength) to 255 (full strength). Example: 
      /* Some one time initialisation code. */
      COLOR_MAP global_light_table;
      create_light_table(&global_trans_table, my_palette,
                         0, 0, 0, NULL);
      ...
      if (get_color_depth() == 8)
         color_map = &global_light_table;
      else
         set_trans_blender(0, 0, 0, 128);

      /* Enemies are in shadow unless lit by torch. */
      draw_gouraud_sprite(buffer, menacing_spy, x, y,
                          light_strength_on_corner_1,
                          light_strength_on_corner_2,
                          light_strength_on_corner_3,
                          light_strength_on_corner_4);
See also: draw_sprite, draw_lit_sprite, color_map, set_trans_blender, bitmap_mask_color.
Examples using this: exshade.
void draw_character_ex(BITMAP *bmp, BITMAP *sprite, int x, int y, color, bg);

Draws a copy of the sprite bitmap onto the destination bitmap at the specified position, drawing transparent pixels in the background color (or skipping them if the background color is -1) and setting all other pixels to the specified color. Transparent pixels are marked by a zero in 256-color modes or bright pink for truecolor data (maximum red and blue, zero green). The sprite must be an 8-bit image, even if the destination is a truecolor bitmap. Example: 
      BITMAP *logo;
      ...
      /* Draw the logo silhouette in red. */
      draw_character_ex(screen, logo, SCREEN_W / 2, SCREEN_H / 2,
                        makecol(255, 0, 0), -1);
See also: draw_sprite, bitmap_mask_color.
void rotate_sprite(BITMAP *bmp, BITMAP *sprite, int x, int y, fixed angle);

Draws the sprite image onto the bitmap. It is placed with its top left corner at the specified position, then rotated by the specified angle around its centre. The angle is a fixed point 16.16 number in the same format used by the fixed point trig routines, with 256 equal to a full circle, 64 a right angle, etc. All rotation functions can draw between any two bitmaps, even screen bitmaps or bitmaps of different color depth.

Positive increments of the angle will make the sprite rotate clockwise on the screen, as demonstrated by the Allegro example.

See also: draw_sprite, rotate_scaled_sprite, rotate_sprite_v_flip, rotate_scaled_sprite_v_flip, pivot_sprite, pivot_sprite_v_flip, pivot_scaled_sprite, pivot_scaled_sprite_v_flip, itofix, Fixed point trig.
Examples using this: exsprite.
void rotate_sprite_v_flip(BITMAP *bmp, BITMAP *sprite, int x, int y, fixed angle);

Like rotate_sprite, but flips the image vertically before rotating it. To flip horizontally, use this routine but add itofix(128) to the angle. To flip in both directions, use rotate_sprite() and add itofix(128) to its angle.
See also: rotate_sprite, rotate_scaled_sprite_v_flip, pivot_sprite_v_flip, pivot_scaled_sprite_v_flip.
Examples using this: exsprite.
void rotate_scaled_sprite(BITMAP *bmp, BITMAP *sprite, int x, int y, fixed angle, fixed scale);

Like rotate_sprite(), but stretches or shrinks the image at the same time as rotating it.
See also: rotate_sprite, rotate_scaled_sprite_v_flip, pivot_scaled_sprite, pivot_scaled_sprite_v_flip.
void rotate_scaled_sprite_v_flip(BITMAP *bmp, BITMAP *sprite, int x, int y, fixed angle, fixed scale);

Draws the sprite, similar to rotate_scaled_sprite() except that it flips the sprite vertically first.
See also: rotate_sprite, rotate_scaled_sprite, rotate_sprite_v_flip.
void pivot_sprite(BITMAP *bmp, BITMAP *sprite, int x, int y, int cx, int cy, fixed angle);

Like rotate_sprite(), but aligns the point in the sprite given by (cx, cy) to (x, y) in the bitmap, then rotates around this point.
See also: rotate_sprite, pivot_scaled_sprite, pivot_sprite_v_flip.
Examples using this: exsprite.
void pivot_sprite_v_flip(BITMAP *bmp, BITMAP *sprite, int x, int y, int cx, int cy, fixed angle);

Like rotate_sprite_v_flip(), but aligns the point in the sprite given by (cx, cy) to (x, y) in the bitmap, then rotates around this point.
See also: rotate_sprite, rotate_sprite_v_flip, pivot_sprite.
Examples using this: exsprite.
void pivot_scaled_sprite(BITMAP *bmp, BITMAP *sprite, int x, int y, int cx, int cy, fixed angle, fixed scale);

Like rotate_scaled_sprite(), but aligns the point in the sprite given by (cx, cy) to (x, y) in the bitmap, then rotates and scales around this point.
See also: rotate_sprite, rotate_scaled_sprite, pivot_sprite, pivot_scaled_sprite_v_flip.
void pivot_scaled_sprite_v_flip(BITMAP *bmp, BITMAP *sprite, int x, int y, int cx, int cy, fixed angle, fixed scale);

Like rotate_scaled_sprite_v_flip(), but aligns the point in the sprite given by (cx, cy) to (x, y) in the bitmap, then rotates and scales around this point.
See also: rotate_sprite, rotate_scaled_sprite_v_flip, rotate_sprite_v_flip, pivot_sprite, pivot_scaled_sprite.
Back to contents