Mail Archives: djgpp/1999/10/04/12:25:23
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.
- Raw text -