Crossfire Archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: CF: images & caching.
On Mar 6, 6:57pm, Scott Wedel wrote:
> I propose that both can be solved if upon start of client game play that
> all font info in an image format native to the client's display logic
> ia locally available to the client. This converts those client issues
> from real time performance (bandwidth and CPU) issues into a simpler
> image database info issue.
bandwidth during gameplay is fully a function of the connection speed of the
client (assuming most are at home or at the end of slow links.) So having a
seperate image server doesn't help that out - you are still downloading the
same amount of data
While conversion of a client font via the update utility does work, that
doesn't really answer the question of what the primary type support is.
That is important because that format will determine what
capabilities/information the images carry. If we stick with XPM, than
translucent pixels (which png supports) are not possible, so conversion to png
via the client font utility (or pre conversion on the server side) limits the
usefulness of png.
IT is certainly a fact that the client (either via font utility or just built
in the the client) must be able to convert from at least some image types to
native form. So the question still remains of what should that list be (might
just be a 1 or 2 item list)
As a note - right now, it would probably be possible to write a client font
utility as you describe that gets the fonts from the server (same port,
different proccess). So it is really up to the client to determine how it
wants to deal with new images. Whether some admins might want to set up
seperate font server processes is up to them.
But the point still remains: The client must know that it can always get
images in some known format (so the client writer can know what conversion
types it needs to put in.) And that seems to be what the discussion is all
about - XPM is already a known format, but not widely used outside of X, so
conversion routines must be hand written. PNG is better known, as if GIF.
Certainly, it would be possible to write conversion routines to go from XPM to
PNG or GIF, and that could be done as part of collect.pl or something. The
XPM->GIF conversion would be pretty straightforward, and as far as I know, GIF
offers nothing more than XPM, so that is not a problem. A XPM->PNG conversion
could probably also be done, but here there are features of PNG that will never
be used.
It would be easy to keep things as is - bitmap and XPM will always be known to
be supported, and GIF/PNG/whatever else is just a bonus (could perhaps add a
S->C: IMAGE_TYPES <list> at startup, so the server could tell client what types
of images are supported for download). But I guess the question comes down to
- is XPM worth keeping as one of the known image types, or should we move to
something else?
Secondary font servers and all other logic aside, what gets distributed in the
arch package needs to be decided - and whatever form that is, it would
certainly be part of the always known will be supported on teh server list.
--
-- Mark Wedel
mark@pyramid.com
[to unsubscribe etc., send mail to crossfire-request@ifi.uio.no]
References: