Building A-code games from intermediate C sources

Derived C sources
Building an executable from the C sources

Building a "dumb" executable
Linux/Unix users have it easy!
Building an executable with command history and editing
Building an X-windows/Windows aware executable with command editing
Default data file handling
Alternative data handling
Ditching the data file
Ditching the data file without access to the A-code source

Glk library

Glk for X-windows on Linux
Glk for Windows

Derived C sources

A-code games are, naturally enough, written in A-code, but as the first step of building an executable out of the A-code source, my A-code-to-C translator creates self-contained, intermediate ANSI C source, which can be then compiled and linked as any C program would be. This allows A-code games to be distributed in a highly portable C-source format.

I assume that you already have an A-code game C source, either from one of the A-code games adventure downloads page, or as the result of translating some A-code source by running acdc. If so, all you need now is an ANSI C compiler, though a pre-ANSI (K&R) compiler would probably do too.

Building an executable from the C sources

Building a "dumb" executable
Simply compiling and linking all .c source files to be found within the tarball (cc *.c -o advname), will give you a "dumb" executable, without any windows awareness, or command editing.

Linux/Unix users have it easy!
If you happen to be using Linux or Unix (and if not, why not? :-), you can simply use the advbuild script supplied in the tools sub-directory in the 91K gzipped A-code tarball, which also contains the source of acdc, and the A-code kernel source files. The script will attempt to determine whether you have GLK available on your system, or failing that, the readline library, and will build as smart as executable as can be managed.

Building an executable with command history and editing
If you have installed the GNU readline library and the ncurses library (a dependency of readline), you can built a version of an A-code game with command history and editing. Just add -DREADLINE to the compiler flags, and link in the readline and ncurses libraries from wherever they are installed (cc *.c -DREADLINE -lreadline -lncurses -o advname).

Building an X-windows/Windows aware executable with command editing
You can also build a windows-aware executable, by using the Glk library. To do so, use the -DGLK compilation flag and link with the Glk library (cc *.c -DGLK -lglk -o advname). This is, of course easier said than done, because you are rather unlikely to have either the Glk header file glk.h, or the Glk library itself. Hence two additional packages with all the necessary Glk bits are provided in the next section, one for use on Linux, and one on Windows. (Sorry, for any other platform you are on your own!)

Default data file handling
By default, acdc creates a .dat data file, which is read by the game at run time. Also by default, the game executable will maintain a set of 32 1KB data buffers, in which it will cache 32 most recently used 1K chunks of the data file. This arrangement guarantees good performance even on a very old machine, and even if running the game from a floppy disk. But you don't have to stick with defaults...

Alternative data file handling
By defining compilation symbols on the compilation command line, you can alter the way the game accesses its data file:
- You can change the number of data buffers by defining the SWAP symbol: -DSWAP=100 will result in a set of 100 data buffers. Any number may be specified from 16 to 128. If the specified number is outside this range, it will be coerced to the permitted maximum or minimum, as appropriate. Not assigning a value to the SWAP symbol is the same as defining the default number of 32 buffers.
- Instead of fiddling with data buffers, you can instruct the game to read the data file into memory on startup, and ignore the data file from then on. Use the -DMEMORY on the compilation command line to achieve this.
- Or you can go to the ohter extreme, and force the game to read data from the file without any explicit buffering (though there will be some done by the O/S, of course). This is done by adding -DFILE to the compilation command line.
Ditching the data file
Alternatively, if you are running acdc to translate an A-code source, you have the option of dispensing with the data file altogether, and cause the data to be pre-loaded into the executable. Be warned though that the resulting executable may be too large for some machines and/or compilers.

To ditch the data file, you need to use the -preload command line option when running acdc. Instead of creating the .dat file, it will then create the adv6.h header file, which will be automatically incorporated in the executable, when you compile and link the derived C source -- assuming you machine/compiler can handle it.

If you subsequently decide that this was a bad idea after all, or if you got from somewhere else a derived C source which includes the adv6.h header file and no .dat file, and your compiler can't stomach it, don't worry. Just compile the C source with one of the symbols specifying a particular way of handling the data file, even though there is none (i.e. use -DSWAP, -DMEMORY or -DFILE, as explained above). This will exclude adv6.h from being incorporated into the executable. What is more, when run, the executable will attempt to open the data file, and finding none will try to open the header file and to construct the .dat file out of that -- after which it will proceed to treat the file in the way you requested.

Ditching the data file without access to the A-code source
If you only have the derived C sources for an A-code game, plus the corresponding .dat file, you can still embed the data file in the executable, by using the dat2hdr utility contributed by Alan Staniforth. This utility and its reverse hdr2dat, together with their manpages, are provided as ANSI C source under the tools subdirectory in the gzipped A-code tarball. If using them, remember that you will also need to modify the adv00.c module to include or not include (as appropriate) the adv6.h header file.

Glk library

If you don't have a Glk library, you can try using these Glk bundles -- one for Linux and one for Windows.

Glk for X-windows on Linux
This 71K gzipped tarball contains the Glk header file glk.h, which you will need for compilation, and Andrew Plotkin's XGlk library implementation libxglk.a for Linux on Intel 32 bit architecture (with a few small fixes to make it compile and to stop gcc complaining about the use of tmpnam()). But beware! Xglk's handling of fonts is, to put it politely, rudimentary, and you may find the display quality to be more-or-less unsatisfactory, depending on the quality of times fonts family installed on your machine. To help players to change this font default without fiddling with X resources, the XGlk library in the above tarball, has been slightly modified, to take the default font family name from the setting of the environmental variable GLKFONT.

Glk for Windows
This 308K zipped package contains the Glk header file glk.h which you will need for compilation, the runtime glk.dll implementation by David Kinder, and a libglk.a library derived by Cygwin from glk.dll, which should be linked with the binaries if you are using gcc. (Don't know about other compilers -- I am a Unix/Linux user; on Windows I just blindly follow David's instructions. :-)

Back to A-code page
Back to main page

Mike Arnautov, Tuesday, 01-Jan-2008 05:17:33 MST