Crossfire Mailing List Archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Pixmap update.




 The code is pretty much completed.

 As of now, bit masks are used, and I have changed the code so that all
object on the square (above the floor) is displayed.

 As an example is a shop.  Now both the item and tile under it is displayed.
This looks a lot nicer (inventory and look window also uses the 
bitmasks.  The change there is not so dramatic.  The main difference is
that black and white can be used at the same time.)

 What really needs to be done is to color the pixmaps themselves.  Instead
of just black and white (like they are now) color them appropriately.
With pixmaps, another advantage is that each object can be many
colors.

 Which then creates a problem.  If all the pixmaps are colored without
paying attention to how the others are colored, this can easily use up
more colors than are available for that display (there are around
1800 images).  The XPM library will try to re-color pixmaps if the 
defined color for it is not available.  However, depending on the loading,
the first many might be browns, reds, and yellows, leaving very few
greens, blues, and magentas to match too.

 One option is to use a standard set of color for the pixmaps.  A pixmap
can only be colored that color if it is on a list.  This has the advantage
that you will not likely have color conflicts, but also requires some
adminstration.  A simple one would be to have 5 values for any red, green,
or blue value (for 5 values, they would probably be 0, 64, 128, 192, 255).
This consumes 125 colors (a 6 color scenario would be 216).  The
disadvantage with this scheme is that referance by rgb value would be
required, since there are not many colors in the rgb database that will
match that predefined set of values.

 But what is really needed is people to color all the pixmaps to start
out with.  The effective number may be less than 1800, since many of the
pixmaps are multi part (ie, 4 pixmaps put together makes up a large building
image).

 Other notes:  Speed is not that bad (although most of the pixmaps
are still just BW without bitmask, just converted into XPM format (but
the same calls are done as what will be used when they are colored)).  The
main performance hit (I believe) comes from the fact that drawing objects
is more time consuming, because instead of just drawing the top object
on any square, it draws all the objects on that square.  However, if the
top object does not change, it will not re-draw that square (if you are
standing still, for example.)

 Some ways to boost performance would be to not animate objects (fewer
redraws and search through the objects for that square), keep it like the
old and only draw the top object (doesn't look as nice), or maybe implement
a better scrolling algorthym, so that the it copies the game window that will
exist after teh scroll, puts it back in the game window, and then only
needs to do the more time consuming search through the item list for
the new area to be displayed.

 The last case would probably work best without animation.

 However, if you have a fast system, this may be a very minor point in
any case.

   Mark Wedel
master@rahul.net