Copyright 1998, Benjamin C. W. Sittler and Stefan M. W. Sittler
VS Bomber is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation; either version 2 of the License, or (at your option) any later version.
VS Bomber is distributed in the hope that it will be useful, but without any warranty; without even the implied warranty of merchantability or fitness for a particular pupose. See the GNU General Public License for more details.
You should have received a copy of the GNU General Public License along with VS Bomber; if not, write to the Free Software Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
VS Bomber is video game similar to Hudson Soft's Dyna Blaster and Bomberman. It was developed using the Allegro game-programming library by Shawn Hargreaves and the DJGPP GNU development system for DOS. It has since been ported to XWinAlleg under RedHat Linux 4.2, and is theoretically portable to other Allegro implementations.
The game is simple: bombers walk around a maze and try to blow each other up. Special items collected throughout the maze lead to a more interesting game by improving the range, type and number of bombs a bomber can lay and allowing lit bombs to be kicked back and forth between bombers.
There is also a harmful item in the maze: poison. A poisoned player suffers in some way until the poison wears off or is transmitted to another player by contact. A poisoned player is highlighted by a poison marker icon floating over the player's head.
Currently, VS Bomber uses a keyboard setup fixed at compile-time.
shot.bmp
.
The tileset included as part of VS Bomber, alltiles.bmp
,
was drawn by Stefan M. W. Sittler. It is arranged on a 32x32-pixel grid, which
is the right size for 640x480 and 640x400 graphics modes. In
higher-resolution graphics modes, the game will be surrounded by a
black border. This tileset won't work in lower-resolution graphics
modes.
One way to avoid the black border in higher-resolution and errors in
lower-resolution graphics modes is to rescale the tileset image using
an image-manipulation program. For example, 320x240 and 320x200
graphics modes work best with a 16x16-pixel tile, so halving the image
size in each dimension will convert alltiles.bmp
to
work in these modes. You could also generate your own tileset using the
same layout as alltiles.bmp
.
To use your updated tileset you can give VS Bomber some command-line options, or add some strings to your Allegro CFG file. Let's say you have a tileset called 'mcga.bmp' which is layed out on a 16x16-pixel grid and you want to run VS Bomber in 320x200x8-bit mode. You can do this on the command-line:
vs -t mcga.bmp -s 16x16 -r 320x200x8
If you want the settings to be more permanent, you can add the following section to your Allegro CFG file:
[vs] tiles = mcga.bmp char_size = 16x16 gfx_res = 320x200x8
Another useful option is gfx_card (-g command-line option,) which allows you to override Allegro's autodetection of your video card.
There are many other command-line and configuration-file options; run the following comment to list them:
vs -h
VS Bomber has two fast-but-buggy renderers; use F9 to try them. While the perfect renderer (0) doesn't generate incorrect output, it can be a bit slow. The fast renderer (1) flickers a bit, but gives a much better framerate than the perfect renderer. The fast renderer with vsync (2) has slightly less flicker than the normal fast renderer, but the output still isn't perfect. It also doesn't work well under Windows. There's one more problem with the fast renderers: they aren't always faster than the perfect renderer! The ripple renderer (3) simulates the appearance of rippling water. It doesn't yet do a very good job, though, and it forces a full-screen update on every single frame. This is very slow.
In general, each renderer can be thought of as drawing in the following order: first, the lower tile layer is drawn (possibly rippled). Second, the visible sprites are drawn, deepest (greatest z coordinate) to shallowest (least z coordinate.) Finally, the upper tile layer is drawn, unless it has been disabled. Most renderers try to minimize video memory writes by only re-drawing portions of the screen which have changed.
In some situations this can lead to uneven performance, as updating the changed regions of the screen may take longer than the 20 ms allotted for a screen update. If this is always the case, the game will run very slowly. To compensate for this, the game will skip some screen updates. This is known as frame skipping. The game's frame skipping behavior can be modified using the -f NUM command-line option or the frameskip=NUM configuration option. NUM is the number of updates to skip for every completed update. If NUM is -1, the frameskip will be adjusted dynamically.
Another option is to change the speed of the game itself. This can be by adjusting the period of the update timer interrupt. By default it is configured to update 50 times per second, or once every 20 ms. To change the timer period use the -S NUM command-line option or the speed=NUM configuration option. NUM is the number of ms between updates.
Here's a typical frameskip and for the ripple renderer on a slow 486 with a really lame video card:
vs -f 5 -S 40
This can be given in the Allegro CFG file instead:
[vs] frameskip = 4 speed = 40
Adjusting the timer period affects the game difficulty somewhat. If you'd like to see how fast your machine can run VS Bomber, you can disable the timer entirely using the -u ("unthrottled") command-line option.
The primary authors of VS Bomber are Stefan M. W. Sittler and Benjamin C. W. Sittler. The latest version of VS Bomber is available from http://www.nmt.edu/~bsittler/projects.html.
Many improvements have been made to the game at the suggestion of players, and many more are sure to come. Email comments, suggestions, donations, etc. to bsittler@nmt.edu.
Lung Ripper Champion is still a figment of your twisted imagination, thankfully.