Mail Archives: djgpp/1998/01/30/17:45:43
On Thu, 29 Jan 1998 13:07:57 -0500 in comp.os.msdos.djgpp Matt Riker
<SPAMGUARDriker AT pipcom DOT com> wrote:
: No, what I really want to do is this:
: draw_sprite(screen,datafile[spritename].dat,16,16);
: Where 'spritename' is a constantly changing variable. In the middle of
: my program, I want 'spritename' to be anything, depending on what sprite
: the user chooses.
OK, you have a major misunderstanding of the way datafiles work, and
what the header file actually means ;).
When you load a datafile, you get a pointer to an array of DATAFILE
objects. Each object in this array represents one object in the
datafile, and you access the object's data through the `dat' field.
So the first object in the datafile `file' is file[0], and its data is
stored at file[0].dat in some format (which depends on the type of the
object). The second object is file[1], the third is file[2], etc.
But you don't know which is which inherently. The grabber does, when
it creates the datafile, so it creates a list of #defines (in your
header file) which let you write THIS_OBJECT in place of a numeric
index *at compile time only*. This only works at compile time because
the compiler (preprocessor, actually) replaces the macro THIS_OBJECT
with the number it represents. After compile time the header file is
useless.
So, for what you want to do the header file is (almost) useless. You
can do what Nate suggested, viz. create a look-up table of strings and
numbers, but that's not the way I suggest you do this. There are three
reasonably neat solutions:
1) Load your objects individually. When you do this, you receive a
pointer to a single DATAFILE object, and can use its data through its
`dat' field (e.g. `object->dat'). When you load the object, you pass
Allegro the exact name of the object, as it appears in the Grabber
(not the header file). This only works if you didn't strip the
property information from the datafile, and is rather slow if you used
global compression (individual object compression is OK though). This
is my personal preferred method. If you name the objects sensibly in
the datafile you can easily construct their names at run-time,
e.g. sprintf (obj_name, "SPRITE_%d", n);
2) Rely on the objects in the datafile being ordered alphabetically by
name. Shawn assures us that this will remain true in the future. So,
if for example you have four frames of a sprite you can name them
`SPRITE_1', `SPRITE_2', `SPRITE_3' and `SPRITE_4'. Also create a
dummy object called `SPRITE' which is empty. Then, thanks to the
alphabetic ordering of the objects, the object indices will be
sequential, so SPRITE_1 (in the header file) == SPRITE + 1, etc. So
now you can write for example the following function:
/* check my syntax on the draw_sprite call... */
draw_sprite (screen, datafile[SPRITE + n].dat, x, y);
where `n' is the number of the frame of the sprite you wish to draw.
This is probably the simplest method.
3) Use the object names stored in the datafile to find the object
you're looking for. When a datafile is loaded in, its property
information is loaded in too. You can search through each object's
properties for the "NAME" property, and check it against the name of
the object you're looking for. This is slow, though, so you'll want
to create aliases for each object beforehand; but by this stage you
might as well be using (1). The only advantage here is that you'll
get faster load times with globally compressed datafiles.
4) Use subdatafiles and (2) or (3). Continuing the hypothetical
situation from (2), you could put all the frames of your sprite in a
sub-datafile and either rely on their alphabetic ordering or check
their "NAME" properties.
There are, of course, many other ways; these are, I think, the four
most common. I personally like (1) for robustness and (2) for
simplicity.
You might like to refer to chapter 10 of Allegro Vivace, which deals
with datafile use at a simple level, and explains some of the above
(perhaps in more depth).
http://www.canvaslink.com/gfoot/vivace/
--
george DOT foot AT merton DOT oxford DOT ac DOT uk
- Raw text -