Re: CF: the begining of crossfire

[David Andrew Michael Noelle <dave@Straylight.org>]

Mark Wedel wrote:
> 
>  Note that currently, the tiles are 24x24, with the revised tiles 32x32.

    Oh yeah.  I knew that.  Sorry for the confusion.  I must have been
typing in my sleep again.


>  I believe, but am not positive, that under the revised system, the 32x32
>  tiles will still be used for inventory.

    Sorry again.  I thought I read in here something about needing both the
small and large tiles.  Like I said, sleep-typing.  And I was imagining them
doubling in size.  If they're going from 24 to 32, the extra inventory space
really isn't worth keeping both image sets.


>  How much larger the viewable map is has yet to be determined.  My personal
> preferance is to make it quite a big bigger, and have things like line of
> sight, darkness, and other factors limit how far you can see.

    A good deal of the viewable area size discussion may have been before I
joined.  17x17 was the only suggestion I recalled seeing.  Of course, my
memory isn't what it used to be.  At least, I don't think it is.  It's hard
to be sure.

    My preference would be to make the map window size a client option with
a maximum set on the server.  People might want to use a smaller viewport
for the same reasons people used to play Doom in low-resolution windows with
borders.  (Does anybody still play Doom?  Do people still do that with Quake
II, or whatever the obsession is this month?)  A smaller window means less
network traffic and less processing load, since the server would know about
it and only do as much work as it needed to.


>  One problem with multiple image sets is maintenance.  Right now, we
> have xpm and bitmap (of which the later could perhaps go away, but they
> are still useful on slow connections or monochrome systems).  One
> discussion for the new images was to go to png (more portable and
> bandwidth friendly than xpm).  If we have 32x32 plus 24x24 plus
> bitmaps, that is 3 image sets needed maintenance.  So if you update one,
> you update all.
> 
>  An easier solution would be to have the 32x32, and if need on low res
> systems is there, perhaps also 16x16.  Automatically convert (reduce)
> the 32x32 to that size - be a half size should make the results better.
>  This could either be done on the client side (so server still only
> needs to detail with one image size, and this also works better as the
> client could download the 32x32 and use those for the map, and shrink
> them to 16x16 for the display) or pre shrink them on the server as part
> of the collect process.

    Sounds like a much better idea to me.  I'm not sure whether it would be
better for the client or the server to scale the images, but I suspect that
in most cases network bandwidth will be a more valuable resource than client
processor load.  That could be implemented seperately, as a client-side
feature, without the server knowing or caring about it.

-- 
            -Dave Noelle,                 dave@Straylight.org
            -the Villa Straylight,  http://www.straylight.org
Coalition Against Unsolicited Commercial Email  ==  http://www.cauce.com

Disclaimer: The above opinions aren't even mine
"The secret to happiness is short-term, stupid self-interest."  -Calvin

Quote of the Day:
The gene pool could use a little chlorine.
-
[you can put yourself on the announcement list only or unsubscribe altogether
by sending an email stating your wishes to crossfire-request@ifi.uio.no]