Crossfire Mailing List Archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Pixmap update.
- To: (Mark Wedel)
- Subject: Re: Pixmap update.
- From: Tyler Van Gorder <>
- Date: Mon, 4 Oct 93 11:12:37 PDT
- Cc: crossfire (at) ifi.uio.no
- In-Reply-To: <>; from "Mark Wedel" at Oct 4, 93 12:22 am
>
>
> 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.
It is also important to note what these images will look like in black and
white...as many of the terminals used are such.
>
> 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.
Well, what you are purposing is to allocate roughly 4/5 of a 255 color map...
This would most likely require crossfire to create its own colormap...which
then creates the "techno-color" effect everytime the mouse cursor moves to/
from the crossfire windows......Allocating 216 colors in the default map would
be very difficult....sometimes crossfire doesnt like to allocate 16 :>
The number of colors would have to be small.....
>
> 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.)
How about drawing the top 2 or 3 objects?
>
> 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.
ACK!! no animationS?@@$$#%%
>
> 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
>
>
I very much like the idea of masking...and if it can be implemented effectively
:cool :>
I would definately like to keep animation.....not to keen on dropping it.
Tyler