[CF-Devel] multi tile monsters - one png
Michael Toennies
michael.toennies at nord-com.net
Mon Jul 16 22:11:40 CDT 2001
Yes, you described it exactly.
The simplification is for the artist and for the server also, because
we don't must synchronize the animation of a multi tile monster anymore -
we got only one tile (= head) with this information.
The problem with the right shifting of the image on client side is easy,
when we define 2 simple rules. The iso client is in fact working with this.
Because in iso a image be higher than a floor tile, the client always assume
that
the image start at y=0 as offset the bottom of the floor tile. For this
reason,
we must shift the monsters/items we use for iso in a new position.
If the image is higher then the floor tile, we do a
(in real all floor tiles has the same width/high of course)
blit_y_pos = floor_tile_y_pos
if(image_high > floor_tile_high)
blit_y_pos -= image_high - floor_tile_high;
For the x position, we can do the same, if we assume that the first x pixel
of the image is
the x start of the first left tile - this also works in iso. So, if the
image is > floor_width,
we just shift it one floor_width to the left until the rest is not bigger,
then we got it.
All what the client then needs is the to know at which (relative or not)
position the head is -
when the head then the right bottom tile is!
To handle multi tile objects in this way (a fixed head in the right bottom
corner) should not be
bad and maybe its useful for other things too.
At last, we got a rid off the multi part images, which is a must for
interesting more artist in my
opinion (they are all girls and don't like to cut there pictures :) and we
have a positive effect
on server & bandwith side (a minor effect perhaps, but permanent).
The client must do more work then, but its only some calculation and this
use performance where most
performance is: on cpu side. And because there is only one picture to blit,
it should also be faster
there because blitting images is a bottleneck (well, don't think there will
be a noticable speed
effect ever).
That the map cmd then has more place to submit other objects on the free
layer cell is a really nice
side effect i don't notice before.
Well, when i add all this we should include this single image per multi tile
ASAP... It has alot of
good effects.
Michael
>
I think I agree with what was said. I'm going to restate what I
>
think it means
>
and how to do it just to prevent any confusion.
>
>
The way I would see doing this would be multipart monsters would
>
still have
>
multiple object parts, but only the head would have a face, and the image
>
pointed to would be of the appropriate size. The other parts
>
would have no
>
face/animation value. This means images of an arbitrary size
>
must be supported
>
- the server doesn't care about that.
>
>
Note that one side effect of this is that it now means even more
>
data can be
>
displayed/sent to the client. Take a 2x2 monster - of those 4 spaces, the
>
monster is using 1 of the 3 available layers. With this system,
>
the head of the
>
monster is taking 1 of the 3 layers, but the other 3 spaces have
>
all 3 layers
>
available, which means that you could effectively get 4 or more
>
layers drawn on
>
the client map (or more can be caused by the fact you have other multipart
>
objects overlapping with this one even)
>
>
Now there are two main cases I see:
>
>
1) Tall objects (ie, towers, giants): in this case, when the
>
image is drawn,
>
the location is the base. Lets say the tower is 32x64 and a
>
single space (say
>
5,5). In this case, it should be drawn such that it goes on 5,4
>
and 5,5. It
>
should not be drawn such that it goes on 5,5 and 5,6
>
>
2) Objects whose head starts the definition of their footprint.
>
Say dragons and
>
perhaps stores. In this case, the head is the base. Take a 2x2
>
creature, head
>
also at 5,5. In this case, it should be drawn such that it fills
>
up 5,5, 5,6,
>
6,5, 6,6
>
>
Note that the above are simple cases. Maybe you want to make
>
that ogre be
>
32x44 so it is a little taller. Since only the server knows the
>
actual size of
>
the object, presumably the server has to communicate to the
>
client if the object
>
should be drawn up or drawn down.
>
>
Ideally, the archetype itself does not know or care what the
>
image looks like.
>
But the easiest approach is to probably add a flag to the objects
>
which gets
>
sent to the client to tell if the image should be drawn 'up' or
>
drawn down.
>
I've given this some thought, and any other determination to do this would
>
require just as much work (ie, redoing the way multipart objects
>
go, etc) Some
>
objects would probably still need to get redone - right now, I believe all
>
multipart objects have the head at the upper left. I could
>
certainly see cases
>
where the monsters footprint is say 2x2, but the monster itself
>
should be much
>
taller (think of things like titans). In this case, the titan
>
should get redone
>
such that the head as at the bottom right, so that when we tell
>
it to draw up,
>
it still covers all the spaces which its footprint belongs.
>
>
In terms of offset - yes, that is necessary if the head is
>
outside the viewable
>
map area. But there is no real way to include that along with
>
the draw up/draw
>
down flag. I suppose you could set the high bit for what should
>
be the face to
>
denote this is a multipart face, and then include the draw
>
up/draw down flag and
>
offset in the first two bytes, followed by 2 bytes for the actual image.
>
>
Probably the hardest part will be updating the clients to
>
properly deal with
>
all of this. The client current knows about things in the tile
>
format, and only
>
redraws what it needs to - aside from supporting these large
>
images, it needs to
>
know that when it redraws space x,y, a big image at q,r extends
>
into x,y, so
>
that also needs to get redrawn (or at least some portion of it).
>
_______________________________________________
>
crossfire-devel mailing list
>
crossfire-devel at lists.real-time.com
>
https://mailman.real-time.com/mailman/listinfo/crossfire-devel
>
More information about the crossfire
mailing list