| Name: | Xbat |
|---|---|
| Version: | 1.11 |
| Authors: | Yuuji Waizumi |
| License: | GPL |
| Operating System: | Linux and other Unixes |
| Website: | http://www.nemoto.ecei.tohoku.ac.jp/~wai/index_e.html |
Xbat is an action game that mimics the classic Xevious. Xevious was released in December of 1983 by Namco. The game displays an overhead view of the terrain and continuously scrolls upward. You pilot a spacecraft over the various landscapes using missiles and bombs to destroy opponents.
Everything from the graphics to the levels of Xbat mimic Xevious very well. For those fans of the Xevious game, I don't believe that the hidden flags can be found in this remake.
Xbat uses an imakefile to create the makefile. By running 'xmkmf -a', it automatically determines the appropriate compile and link options for X windows. After which you simply run 'make' and 'make install' as you would for most programs.
On a little endian system you would then find that the program doesn't function properly. The install documentation tells you that Intel computers need to set UNION to one. A program is even included to determine what the value of UNION should be. This is why imakefiles aren't used very much. Autoconf has the ability to do everything imake does and determine machine specific information.
Creating an autoconf file isn't too difficult. Included with autoconf is autoscan. Autoscan helps in creating the configure.in file by scanning the source files. The file generally needs adjustment but it is a good start. For Xbat I removed the checks for C++ compilers, Lex, and other programs. The collection of library checks were removed along with AC_PATH_X in favor of AC_PATH_XTRA which is an enhanced check for X windows. Since Xbat requires X windows the configure script should notify the user on failure, but right now it doesn't. The manual setting of UNION is avoided by checking the machine's endianess.
In addition to creating the configure.in file, Makefile.in needs to be created. When the configure script is run it will fill in the variables surrounded by ampersands. In order to better conform with the file system standard, I changed the data files to be placed in /usr/local/share/Xbat since they are machine independent. Here's the patch to simplify the installation of Xbat. Unfortunately patch files won't eliminate the left over Imakefile and Makefile. The configure file won't have the execute bit set either.
One of the big advantages of the Internet is the diverse collection of people that contribute to it. One of the big disadvantages of the Internet is the diverse collection of people that contribute to it. In the case of Xbat, the programmer's native language is not English and his code reflects this. Variable names may not have much significance to others. New programmers from other countries will encounter similar problems with file and function names.
The structure of the code is logical and fairly easy to follow. Comments are minimal in any language. The code uses K&R style C which might be unfamiliar to some. The difference can be seen in function parameters:
ANSI C: K&R C:
void Title(int flag) void Title(flag)
int flag;
{ {
... ...
} }
Except for the language barrier, the code shouldn't cause much problem.
When using binary data files the byte ordering that the machine uses make a difference. A little endian machine, such as the Intel x86 family, will store the lowest value in the first byte. Big endian reverses the order. The reasoning behind the orderings doesn't matter as much as what it does. For example the number 8 stored in a 16 bit integer would be:
| Endian | Byte 0 | Byte 1 |
| Little | 8 | 0 |
| Big | 0 | 8 |
However, Xbat doesn't use these techniques for binary files. Rather than using floating-point math, the author choose to use fixed-point. Fixed-point means that instead of representing any real number the data has a fixed number of decimal places it stores. For example the United States currency could be represented with 2 digits after the decimal. Since floating-point is more complicated, fixed-point can be faster. Yuuji Waizumi arranged the fixed-point numbers such that the full number was stored in four bytes with the highest two bytes having a special significance. Therefore, he needs to know if the high bytes are stored first or last.
Except for enemy_func.h there are no prototypes in the Xbat header files. ANSI C made function prototypes common practice so it's not surprising they aren't present here. The header files don't have the customary "if not defined" checks that prevents a header file from being included twice. Their use in Xbat is mainly for defines, structs, and global variables.
The global variables defined in xev.h are declared extern in everything except when _MAIN is defined. However, this isn't done with the palette declared in colorlist.h. So every file that includes this header has a separate copy of the palette. This patch corrects the problem so that only one instance of the palette is created.
back.h seemed to have a similar problem where it would create multiple instances of fn. When I attempted to fix the problem with a similar patch, the executable size didn't decrease. The file is only included in two files so one extra copy should have been eliminated. However, I hadn't noticed that only one of those files, back.c, is compiled into the game.
From examining the code I had discovered that the terrain map files are simple binary dumps that stores the tile for a particular map square. Although it is possible to edit such a file by hand to create levels, I suspected that a map editor was constructed to simplify the process. Once I noticed the unused med.c, it didn't take long to conclude that this is the map editor.
Map editors are means to an end, not ends upon themselves. Functionality often takes importance over simple user interface. The Xbat map editor is good example of this. The code is littered with fprintfs to standard error. Here's a list of key commands:
| Key | Action |
|---|---|
| Up Arrow | Scrolls upwards |
| Down Arrow | Scrolls downward |
| Right Arrow | Next draw tile |
| Left Arrow | Prev draw tile |
| z | Increment draw tile by 10 |
| x | Decrement draw tile by 10 |
| l | Load file |
| s | Save file |
Two important things to notice from this list. First there is no exit command. Second there is no method of placing a tile with the keyboard. The left mouse button places one tile. The middle button places a 2x2 block of tiles. The right button creates a 4x4 tile block. Don't expect a dialog box for loading or saving files. It simply reads a string from standard input. Constructing a pretty interface costs time with very little gain unless the game is intended to support player created levels.
In addition to the terrain map files, each level has a chijou and kuuchuu file. I haven't played around with these. It would be reasonable to assume one handles ground targets, while the other handles air ships. Both are text files so there probably isn't an editor for them.
No game development kits or graphics libraries need to be installed. Xbat runs under X windows without even the shared memory extensions. All color modes are properly handled with the exception that the game requires at least 8 bit color. For a low level X windows programs it is remarkably well behaved.
For game images, a simple run length encoding scheme is used. Run length encoding stores a length followed by the color value instead of just the color values. This allows repetative pixels to be compressed very easily. For Xbat, the image files don't even have a header or other information. Instead of converting some other standard file format, the author created ced, an image editor specifically for Xbat. Although usable, the editor offers limited functionality. It can't even edit the compressed files. Instead rlcomp and dlcomp convert to and from the run length encoding respectively. Like the map editor, this is a means to an end and that is all.
As with graphics, no abstract library is used for keyboard input. The event handling is almost localized to inkey.c. Unfortunately the configuration menu has a specialized input routine. No support is provided for joysticks. Joystick support shouldn't be difficult to add. Since my computer with a joystick is not currently working, I didn't construct a patch.
The game does not run at a fixed speed. Therefore the user must adjust the speed setting according to the machine. Ideally the game would limit the frame rate to a particular speed. Machines too slow for the frame rate would be a problem but otherwise the game difficulty varies by machine making the scoring relatively meaningless.
The artificial intelligence is largely unexplored. It does seem to be state machine driven. I believe the data files in the Domo directory affect the actions of the game objects. Originally text files, they are converted to binary data files by t2b.