Crossfire Mailing List Archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: CF: the begining of crossfire
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
> 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, dave@Straylight.org
> -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 email@example.com]
[you can put yourself on the announcement list only or unsubscribe altogether
by sending an email stating your wishes to firstname.lastname@example.org]