Creating ANSI C sources from the A-code source

(A-code acdc version 12.18)

Contents


A-code source

Logically, an A-code source is a single file, usually with the .acd suffix. (The suffix is optional; if present, it can be omitted when nominating to acdc the A-code file to be processed.

In practice, A-code source can be split into a number files, which are incorporated in the "main" one by means of the A-code include major directive. Again, such include files are conventionally suffixed with .acd, which suffix may be omitted in include statements.

Obtaining and building the acdc translator

Obtaining is easy: here's the 239K gzipped tarball acode-12.29.tgz, which contains the ANSI C source code of acdc (and or the A-code kernel too). Building is also easy, in the standard GNU manner: run the configure script and then run make.

Running acdc

The acdc translator takes the following command line arguments (in any order):

<sourcefile>
The name or pathname of the main A-code source file; if omitted, it is prompted for. Any include statements are taken to be relative to the directory in which the main source file is located.

-plain abbreviable to -p
Causes the game text data not to be encrypted.

-preload abbreviable to -pr
Causes the game text data to be preloaded into the executable. This results in a large executable, but avoids having a separate .dat file.

-file-page [<npage>] abbreviable to -fp
Requests a separate .dat text data file to be created and to be accessed by the game using its own internal paging mechanism. The optional <npage> argument defaults to 32 and specifies the number of 1KB paging buffers. Only useful for really small, slow machines.

-file-read abbreviable to -fr
Requests a separate .dat text data file to be created and to be accessed by the game by direct file reads as required. Only useful for really small, slow machines.

-file-memory abbreviable to -fm
Requests a separate .dat text data file to be created and to be read in full into the games memory on startup. Useful only if the OS objects to large executables.

-xref abbreviable to -x
Requests that a cross-reference file of the A-code source be created. For technical reasons (meaning I am being lazy), this file is called game.xrf It is not sorted and can be processed further with the sortref Perl utility, supplied as a part of the acode package.

-no-warnings abbreviable to -nw
Suppresses warnings about unused symbols in the A-code source.

-quiet abbreviable to -q
Suppresses most of the standard info messages generated by acdc in translating the A-code source.

-debug abbreviable to -d
Causes A-code source to be added as comment lines to the translated C source files. Also adds trace message showing individual A-code code chunks being entered during play. Also causes the DEBUG symbol to be defined in the kernel source.

-help abbreviable to -h
Lists available command line arguments.

Derived ANSI C sources are created in the directory from which acdc is run, except that if a sub-directory called C is found in in the directory in which the A-code source is located, the derived sources are placed there.

Adding kernel source files

The A-code kernel consists of source files adv00.c, adv01.h and adv0.h. All three can be found in the above linked A-code tarball. Copy them alongside the C sources created by acdc, and you will have the complete C source required to build an executable.

NB: The kernel sources as supplied are equivalent to, but not compatible with the "uglified" sources which I distribute as A-code game C sources. Do not mix them!

Building an executable

Building a simple adventure executable from the derived C sources is simplicity itself: just compile and link the lot together with any ANSI C compiler. But the resulting executable will be lacking command history and editing facilities, and under Windows will be only usable at a DOS prompt. If that's good enough for you, fine. but if you hit problems, or want a more sophisticated version, read the guide to building A-code games from intermediate C sources.


Back to A-code page
Back to main page
Mike Arnautov, Sunday, 02-May-2010 05:42:31 MDT