[CF-Devel] Fw: [Crossfire-cvs] CVS commit: arch/ground
crossfire-devel-admin at archives.real-time.com
crossfire-devel-admin at archives.real-time.com
Sat Jun 21 03:13:37 CDT 2003
Todd wrote:
>>
>>
There is already a 'visibility' value in the archetype. Using this to
>>
denote mountain > forest > grass > water would be fine.
>
>
>
and this wouldn't interfere with visibility?
visibility in the arch is a 'hint' on which objects are more noticable than
others.
Given that you can only display 3 objects on a space, suppose you have the
case of 'ground, tower, dagger'. That's easy - draw all three. But now move
an arrow on that space. Which of the tower, dagger, and arrow don't we draw?
Visibility field basically determines that. Generally, bigger things have
higher visibility - if you can only see limited things, your going to see the
big things.
I think this works out just fine with the terrain stuff - I can't think of any
cases where you have forest on top of grass and have questions of which you can
see (since the forest will clobber the grass). But if there was, the visiblity
works out - the forest should be more noticable than the grass it sits on.
>
I wouldnt want to increase the number of faces sent and increase the
>
bandwith, however there are some advantages to having the client do some
>
weighting/layering on it's own from with the face information provided.
>
Perhaps I am not understanding the fundimentals here but I suggested
>
something like a 0-16 value so you can have the client lay out other
>
things than just landscape transitions (probably not more than 6 or 7
>
levels?) you could have the client use the lower levels to merge three
>
or four images into one ground layer or use the higher levels to add
>
things over the tile (like large creature overlapping or magical
>
semitransparent glows or rains and fog and such masks. If you want the
>
client to do transition layering of tiles you will need some of these
>
such as the first 6 or 7 anyway.
Ok. That is a completely different point, and does exist to some extent - the
handling of big images goes on 'parallel' layers. Thus, if say you have a 4x4
giant, only the base of the giant (lower right corner) counts as a layer that is
used up on the client side of things. Thus, the other three spaces can have 3
objects in addition to the giant, because the giant (when one big image) doesn't
use the same layer as the stuff sent by the server.
Of course, the most flexibly way woudl be to allow the client to say how many
layers it wants. Eg, I want up to 7 layers of information, or I only want 3, or
I want 4, or whatever.
However, that does make things complicated - at minimum, the server must be
able to support up to some number of layers, so that increases its complication
of what to put on each layer. But you also get trickier issue - suppose there
actually is 7 layers of information - you could have something like 'floor,
treasure, dagger, gold, player, arrow, arrow', with the arrows moving in
different directions, and hence different images.
If the client only wanted say 3 layers, taking the top two layers (arrows) and
bottom layer (floor) is obviously not the right approach - you want to really
take an arrow, the player, and the floor. But how to really figure that out for
all these different possiblities would be a pain.
As a note, when I first started playing with putting xpm's into crossfire, I
did experiment with drawing every object on the space. Other than major
performance problems (granted, this was a long time back), at some point, you
really don't gain anything. A pile of stuff in a shop looks like one item on
top of a pile that isn't really distinguishable.
>
>
Something like:
>
>
0 - no transition - default for most objects
>
1 - water tiles
>
2 - sand, swamp, marsh, road
>
3 - grass, brush, desert
>
4 - trees, dunes
>
5 - hills, treed hills, steppes
>
6 - mountains
>
7 - high mountains (mountain2)
>
8 - very high mountains (mountian4)
>
9 - highest mountains (moutnain5)
>
10 - objects in this tile
>
11 - player level (players overlap most things)
>
12 - specific object auras (red glows and such, maybe some of the other
>
less tangible spell effects...)
>
13 - image overlap from tile y+1 (large image overlapping so your
>
halfling can stand behind a tree to take a leak and such)
>
14 - auras for overlapping monsters and area effects
>
15 - snow and rain animations
>
16 - ?
I guess I'm sort of missing what you are saying here, and where those values
come from (are these something the server communicates to the client?)
Is it basically the client will still only send a max of 3 images/space, but
might say 'this is layer 12, and this one is layer 4, and this one is layer 0'?
I'd have to think about what actual effect that would have. The only thing I
could really think of is this could be useful for big (multipart) images to make
figuring out how they stack with others easier. There is a bit of voodoo in the
way it is right now.
At some point, the map protocol probably needs to be extended to deal with
lighting in an intelligent way. Right now, we basically send the darkness for
each space (that is visible). It'd make much more sense for the server to say
'this map has an ambiant darkness of x'. And for spaces that are visible to
player and that have light sources, the server would send along like 'x,y has a
glow of 3, a,b has a glow of 4'. And now the client can be much more clever
about how it does the lighting.
One could even extend that slightly - 'this space has a glow of 4, and it is
red', or 'this space has a glow of 2, and it is blue'.
As part of that ambiant light information, the server could also send along
other global map information, eg, 'it is raining' or 'it is snowing', and the
client could then draw snow/rain/whatever graphics all over the map.
_______________________________________________
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