Re: CF: the begining of crossfire

[Mark Wedel <>]

David Andrew Michael Noelle wrote:

>     Why not have it both ways?  Make the decision of whether to use the
> small 16x16 tiles or the new large tiles a client option.  The small tiles
> are still needed for the inventory anyway, so they're not going away any
> time soon.  It shouldn't be too hard to register that switch with the server
> so it knows whether to send you only small tiles or small tiles for
> inventory and large for map.

 Note that currently, the tiles are 24x24, with the revised tiles 32x32.

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

> 
> And now today's math lesson:
>                 16 x 16 tiles   24 x 24 tiles   32 x 32 tiles
> 11 x 11 map     176x176 window  264x264 window  352x352 window
> 17 x 17 map     272x272 window  408x408 window  544x544 window

 To add on:
  19 x 19	304x304		456x456		608x608
  21 x 21	336x336		504x504		672x672

 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.

 Some of this may be affected by ranges - I would generally say that you should
be able to see the source or range attacks (if you go realistic of course).  So
one other adjustment would be to reduce ranges (bow have a range of 10 or
something).

> 
>     When the new graphics are ready, your map view might take up too much
> space if you're running at 800x600, but at 1024x768 of higher you should be
> okay.  The graphics would fill half your screen and you could arrange the
> text in the other half of the screen.  Still, I would recommend that when
> the graphics are expanded to include the larger tiles and more of them, both
> should be client options.  By all means, default to the big, pretty picture,
> but for those unfortunate souls who are trapped in aging hardware, keep the
> low-resolution, low-bandwidth options around.  At least until they actually
> get in the way.

 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.

 Either way, there is some desire to limit the number of images one must
create/update when adding new archetypes.

> 
> --
>             -Dave Noelle,                 
>             -the Villa Straylight,  http://www.straylight.org
> Coalition Against Unsolicited Commercial Email  ==  http://www.cauce.com
> 
> Disclaimer: U.C.L.A. doesn't share my opinions; life isn't that good.
> 
> Quote of the Day:
> "Tilting at windmills hurts you more than the windmills." - Lazarus Long
> -
> [you can put yourself on the announcement list only or unsubscribe altogether
> by sending an email stating your wishes to ]
-
[you can put yourself on the announcement list only or unsubscribe altogether
by sending an email stating your wishes to ]