From: George Foot Newsgroups: comp.os.msdos.djgpp Subject: Re: Allegro Datafiles - More Problems Date: 30 Jan 1998 16:11:51 GMT Organization: Oxford University, England Lines: 85 Message-ID: <6asu47$5c4$7@news.ox.ac.uk> References: NNTP-Posting-Host: sable.ox.ac.uk Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 8bit To: djgpp AT delorie DOT com DJ-Gateway: from newsgroup comp.os.msdos.djgpp Precedence: bulk On Thu, 29 Jan 1998 13:07:57 -0500 in comp.os.msdos.djgpp Matt Riker 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