[crossfire] House sizes
Alex Schultz
alex_sch at telus.net
Tue Feb 13 23:46:58 CST 2007
Aaron Baugher wrote:
> I like the idea mentioned earlier of trying to keep them within a
> range. The ranges could even overlap somewhat. Say a house one block
> wide on the outside could be 1-15 tiles wide on the inside, while a
> two-block-wide house image could be 10-25 inside, a 3-block house
> 20-35, and so on.
>
As a brief note, I'd be inclined to say the recommended size should
start greater than 1. Unless of course we have a 1 tile house outside,
where the house takes much less than the full tile image ;)
>> Also, there is some limit on how big multipart images can be - I'd
>> have to look at the map protocol, but I think right now it is
>> somewhere in the 6-8 space range. This could be fixed in various
>> ways.
>>
>
> I don't know if there's a limit on tile size, but there's a 10000-byte
> limit on images sent to the server in MAX_IMAGE_SIZE. If you raise
> that, you soon run into MAXSOCKSENDBUF, which is currently 12239
> bytes. (I discovered those when I converted the Demon_Lord into a
> single image and it was considerably larger than that before
> compression.) I was able to compress Demon_Lord, which is a 4x8
> image, to 7841 bytes, but it only has two colors, so I'm guessing a
> more colorful image would be larger.
>
I'm thinking, that for 2.0 it may be desirable to use a separate port
for media (images anyway) transfer, and perhaps we could even consider
http for that part (though I'd say that if we wanted to use http, we'd
want to optimize things by using cgi and GET parameters, or perhaps a
micro-http-server specialized for serving cf images via http (after all,
non-standard-complient http can be very simple ;P))
> Also, do many players still play on an 11x11 map view? Buildings that
> are 5x5 or so would make that map feel *very* crowded. Maybe we could
> assume that by 2.0, all the clients would be capable of displaying a
> larger area than that?
Well, so far as I can tell, I'd estimate around half of active users use
gcfclient2, and a majority of the others using gcfclient, meaning a
significant portion of the users are on a map view probably not bigger
than 15x15, which is the biggest I can usably get the gcfclient view at
1280x1024 resolution.
I believe though, that for 2.0, we should consider depreciating, if not
removing, gcfclient and the x11 client. Also, Gros/Lauwenmark apparently
has a major update to jxclient just about ready, which looks to me like
it could be promising to eventually become a prominent, if not the most
prominent, client in my opinion. I believe that for 2.0 we should be
able to assume that the client should be able to display at least 15x15
or so, at any resolution that client intends to support, but beyond that
we should try to keep our options open for 2.0 clients for now I'd say.
Another thought is, do we want to toss the 'classic' tileset? On that
same note, would it be worth just plain removing tileset support in
order to simplify things?
Alex Schultz
More information about the crossfire
mailing list