Crossfire Archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: CF: images & caching.
On Mar 9, 7:21pm, Brian Thomas wrote:
> Subject: Re: CF: images & caching.
> >
> > You have to remember that image ordering in crossfire can change. If I
add
> > say a new map, with 10 new images, those new images might be #100, #101,
#650,
> > #1350, etc. Under the above scheme, that is a lot of negotiating back and
> > forth to figure out where the new images are, or is much more complicated.
> >
>
> Here's a semi-naive question: Why dont we identify the images
> by their names instead of their (compiled) numerical position?
> In such a case, you could arbitarily add images to any cache
> without screwing up the prior identification of other images.
When doing map updates, it is much more efficient to send what is on a
particular space by image number (2 bytes, although I believe the current
packing actually gives something less than that, but still enough for current
terms).
If you use image names when dealing with transmitting that, map transmission
size greatly increases.
As a note - when using image caching the server will send the name & number
for images, so the client can do the translation - this is also why the client
stores the image in teh cache via name, so when it does the lookup, it does it
via name.
>
> I mean, by default, the image names must be unique. If a number
> must be used, why not use something like a numerical conversion
> of the image name (uh, I dunno, say atoi or sum such algorithm).
Currently, crossfire is currently implemented in such a way that images are
stored in arrays - I think you could have holes without problems, but note that
if we do a 15 bit numbering scheme, that increases memory footprint some.
However, the bigger problem with a hash or other conversion is duplicates. If
you are hashing into 15 bits, and there are 2500 images, most hashing schemes
will probably result in duplicates - how do we deal with that?
Note that the name to num conversion that server sends isn't much data, and
certainly saves in the long run vs sending them in map updates. And in fact,
that works fine right now.
The real issue/discussion seems to be coming down on how to handle client
initialization that wants to verify it has all the images before doing anything
else.
I will note that my last estimation on amount to transmit would be high if
transmission is done in a range (ie, images 0 500 name1 name2 ... name500), as
the bmaps file also includes 7 digits of numbering and a space for each name.
After stripping that out, the image names total to about 40K.
--
-- Mark Wedel
mark@pyramid.com
[to unsubscribe etc., send mail to crossfire-request@ifi.uio.no]
References: