Message-ID: From: Shawn Hargreaves To: djgpp AT delorie DOT com Subject: Re: colored mask and... Date: Mon, 4 Oct 1999 14:07:07 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Reply-To: djgpp AT delorie DOT com night.walker writes: > 1- I'm building a Warcraft-style game: how can I make each unit > sprite have the owner's color? > Actually i'm using RLE Sprites from 8 to 32 bpp. > Is it possible to set a range of colors to be a "color mask" and > replace it with another choosen range of colors when drawing it? If you are in a 256 color mode you can do this very easily with the draw_lit_sprite() function. That just uses a big (64k) lookup table to translate each pixel, where it uses the source pixel color as one array index, the color parameter you passed to draw_lit_sprite() as the other array index, and looks up in the color_map table to decide what resulting color value should be drawn to the screen. This is most commonly used for lighting effects, but if you set up the right values in color_map, you can make up to 256 different mappings that will replace any particular colors with any other colors. In truecolor modes things are a bit more awkward. If you are drawing 256 color source graphics onto a truecolor screen, you could do it just by changing the palette before you draw each sprite, but if your source graphics are also truecolor, there is no such easy trick. It is possible that you could write a custom pixel blending function and then use the lit drawing functions, but that would be very slow: I think your best option would just be to store multiple copies of each image, preconverted to the right colors. > 2- Which is the difference between scroll_screen() and > request_scroll()? scroll_screen() changes the start address before it returns from the call (that usually means waiting for a monitor retrace, then altering a hardware register, and then returning). request_scroll() tells the hardware to change the start address whenever the next retrace occurs, but then returns straight away, even if this hasn't actually happened yet. This lets your program get on with doing other work while it waits for the retrace (for instance you can use it to do triple buffering), but is only possible on some hardware: check the GFX_CAN_TRIPLE_BUFFER flag in gfx_capabilities to see if your card supports it. > Why I must wait poll_scroll()? After you call request_scroll(), then you can use poll_scroll() to see whether the retrace has actually happened yet or not. > 3- set_config_data() is alternative to set_config_file or > requires it? It is an alternative. When you set a config file, that just tells Allegro what disk file contains the config data, but when you call set_config_data(), you pass it a block of memory that you have already set up to contain the right information. You might use this if you wanted to hardcode the config values rather than letting your user control them, or if you were reading the Allegro config information from part of some other file format that is specific to your program. > 4- When loading a single datafile object I cannot access > properties. It seem that properties are not loaded with > the object, being objects themselves; Yes, the properties are stored as part of the index rather than inside the object itself. It isn't practical to make the individual object loading functions return that information, because it would make them extremely inefficient (it is impossible to tell what properties are for which object until you get to that object itself, so to do this I would have to always read in all the property data, which makes the load function many times slower). > the question is: how can I read an object property without > loading an entire datafile? I'm afraid you can't, or at least not unless you write your own function to read in the datafile (the format is documented in grabber.txt, and it is quite easy to manipulate as long as you use the Allegro packfile functions to deal with the compression and nested chunk stuff). > Is it possible to load datafile objects individually by > ID and not by name? Again, not unless you write your own loader function. There is no real reason to do this, though: the index positions are a bad thing to identify objects by because they are very arbitrary (for instance they change whenever you add new objects), and it is just as efficient to access object by name as it would be by index. If you really want to use numeric names, just call your objects "1", "2", "3", etc :-) In most situations, though, it is best not to use individual object loading at all. The datafile format is not designed for random access, so it is _much_ faster if you can load the whole file in one pass. If you need to only load parts of it, consider grouping related objects into a nested datafile, so you can then load all of that nested datafile object with a single call... Shawn Hargreaves.