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

Re: Pixmap update.



Tyler Van Gorder writes:
 > >  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.....

I also prefer predefined colors, maybe 16 or 32 colors would be
sufficient. In straigh RGB there would be big amount of rarely used
colors, like different kinds of grays etc.

 > >  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?

Or how about as compromise drawing only floor and top object. 
Currently the top visible object is saved in the mapstruct, and
there's no need to traverse through object lists, which is quite heavy
operation. Floor outlook would be quite easy to add into mapstruct.

 > >  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?@@$$#%% 

I don't like the idea of losing animations either.

	- Jarkko