Crossfire Mailing List Archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: A quick draft of a preliminary proposal for a possible version of the crossfire protocol



Kjetil Torgrim Homme <kjetilho@ifi.uio.no> writes:
> Next time, Carl, please READ my posts before replying.

I try to -- really.  But after reading the same argument for half a  
dozen times in a few days, one tends to overlook subtle differences  
when one reads something similar one more time.  :-)

> First - BITMAPS won't be rotated for the player, so the roof of the
> shop would appear beneath the door.

Well, now that would be a little peculiar, wouldn't it ?

> But even a client which keeps old mapping information is allowed to
> throw it away if there is a real memory crunch.

The point was that the client could tell the server that it wouldn't
do that in order to save bandwidth.

> > Here I disagree.  What you are proposing is just a variation of the
> > client-side LOS scheme with all (or at least most) the attendant  

> > problems.
> 

> WHAT? My scheme is a superset of yours. Only objects in the viewpoint
> are updated, and only if they have changed since they last were in
> the clients viewport.
> 

> This can be done very efficiently in the server. No need to add flags
> dynamically to objects, just reserve a long word as a bitmask (max.
> 32 clients). Object size is currently ~250 bytes, so this doesn't
> make much of a difference RAM-wise or CPU-wise, but it has a
> tremendous effect bandwidth-wise.

You mean to say that every single map square even in a huge map is  
almost 1/4 of a kByte large ?  I have to admit that it has been some  
time since I studied the crossfire source, but I hadn't realized that.   
If that is so, another extra longword probably isn't worth fighting  
about.

> > No side _ever_ sends binary data without the other side requesting
> > it   first.  And the REQUEST command contains a TYPE field which
> > allows the   client to specify what kind of data it wants.
> 

> That was exactly my point. When the client requests an image, the
> server can respond with an image type unknown to the client, and the
> client can do _nothing_ about it.

No, there will only be one single image type (e.g. XPM) and every  
single client will have to understand that type.  We really don't want  
to have to build TIFF, GIF, JPEG, the MS Windows formats, IFFs a.s.o.  
in the server.  One single image type in the server and the client is  
free to cache images in its local format.

> > However the client can REQUEST not just PIX and SND types, but can
> > request the types BW1, BW2, BW3, ..  BW8 to receive black and white
> > XPMs of one to eight bit planes and CO1 to CO8 to receive color
> > XPMs of one to eight bit planes per color.
> 

> Why restrict yourself to 8 bit planes? The full set of XPM's in
> Crossfire could use 16,777,216 colours.

Now, if I may be so bold as to suggest that you read _my_ post before  
responding to it ?  8/bits per color and 3 colors == 16,777,216 total  
colors.

> An individual bitmap can only use 256 of them, though. More seriously
> - this isn't something we need to decide now, if you just allow some
> sort of negotiation.

Indexed colors really are a hack.  The server/transmission format  
should not contain it.  If the client has to work with fixed or limited  
color maps, let it request a direct color image of some color  
resolution and then do the conversion itself.

> And Carl, have a look at the crossfire.pix file to see that XPM is a
> different beast altogether from just an 8 bit colour image. (search
> for booze, for example)

I'm sorry but I do almost all my programming these days far away from  
graphics -- and if I have to do graphics programming I use NeXTstep  
i.e. display postscript so I've to plead ignorance about the details of  
the various X formats.

> One more thing I forgot last post: You misread the meaning of my MAP
> extension - it should list multiple pixmaps on that coordinate!

Multiple pixmaps in one square ?  But one paragraph below you say that  
you like ITEMs -- which make more than one pixmap in one square  
completely unnecessary.

> I must say I agree with Tero, though - we really don't want to go
> back to .om. 


That is really a question for the server design.  I can see good points  
on either side, but I'm in too many discussions already.

> I revise my standpoint, and suggest
> 

> MAP <x> <y> <lightness>
> 

> currently, <lightness> will only have two meanings, 0 (corresponds to
> UNMAP) and 9. When we get light sources later, we can send other
> numbers. Many clients could map all values > 0 to 9, ie. no shading.

As much as I like lighting in principle your proposal requires that in  
the common case where the player carries a light source, you send MAP  
commands for almost every square in the viewport every time the player  
takes a step.  Do you think you could live with a system in which every  
square is either lighted (i.e. MAPed) or unlighted (i.e. UNMAPed) ?

> Okay, with all that said, perhaps a little on where I agree with you?
> :) ITEM commands are a nice, general approach to it, especially after
> you said that animation sequences is just another sort of image.

Thank you.  It is nice to see that at least one reader agrees on at  
least one part of my proposal. :-)

> BTW, I think there should be a protocol response for damage.  DAM
> <object damaged> <object doing damage> <number>
> 

> That way a client can present it graphically, not just spew out a
> stream of text. Since the client knows the names, it can make up the
> text itself if it wishes to.

Sounds fine to me with the exception that I'd add a string to the end  
of the DAM command which gives some text description like e.g. "burns"  
or "hits %s terribly with darkblade.".  Just saying 'Foo damages bar  
for 5 points' sounds a little bland.

	Carl Edman