[Crossfire-wiki] [Crossfire DokuWiki] page changed: map-technical
no-reply_wiki at metalforge.org
no-reply_wiki at metalforge.org
Wed Oct 17 22:04:43 CDT 2007
A page in your DokuWiki was added or changed. Here are the details:
Date : 2007/10/17 22:04
User : kbulgrien
Edit Summary: Pull in trunk/server/doc/Developers/Smooth.tex and de-tex (mostly).
@@ -1,12 +1,12 @@
- ======TECHNICAL INFORMATION ABOUT MAPS======
+ ======Technical Information About Maps======
This documented is intended to convey technical information on how crossfire deals with the map objects and objects placed on the maps. For the most part, I only intend document how the new code works, and not go too much into history on the older methods. A lot of the map code was re-written in early July 2001, which changed how many things are dealt with.
Mark Wedel
July 7, 2001
- =====1. Map Header=====
+ ======1. Map Header======
The map header is the section at the start of the map file that describes the maps characteristics. The values are described below.
The map variables now make some sense, and are only stored in the map structure itself. I still include the old value (the 'was') so if you are looking at old maps, you know what they mean. Generally speaking, the values in the map files themselves match the same element name in the map structure.
@@ -46,9 +46,9 @@
'winddir' - Rarely set. Direction of wind, 1-8, 1 is north, clockwise.
'sky' - The sky conditions for this map. See weather.h. Don't set this unless you really know what you are doing.
- =====2. Map Objects=====
+ ======2. Map Objects======
The objects within the map are saved in standard 'object save' form (same as is used for the players objects). Other files document the actual meaning, but the general form is:
arch <some name>
@@ -58,9 +58,9 @@
end
Note that x and y are in fact optional. If not present, the values default to zero.
- ====Multipart objects====
+ =====Multipart objects=====
Multipart objects pose a tricky problem, in that they have to appear together in the map file - this makes proper handling of layers hard to deal with.
In old map code, all the single spaces objects were saved, and then all the multi part objects were saved. This effectively means that the multi part objects always ended up on top. The multipart objects were saved with all their parts. For example:
@@ -85,9 +85,9 @@
This method does not work very well with the map tiling however (how do you reasonably deal with a monster that may be straddling the two maps?) Current code now only saves the head of the object. When the map is loaded, the objects on the map are examined to see what objects need to have more objects added on. Additional parts linked in are put just above floor level when linked in, so things like shops won't hide items that someone drops on them. For monsters, this linking shouldn't be a problem - once they start moving, they will get relinked as normal (on top).
The effect of saving only the head does have the effect of not being able to customize the non head parts of the object. This generally should not be a problem (in the case of shops/building, the exit code now knows to look only at the head for valid information). The case where this may not work as well as expected is for buildings where setting the move_block to non-archetype defaults will get lost.
- =====3. Map Tiling======
+ ======3. Map Tiling=======
Map tiling is a feature that lets multiple maps be connected, effectively forming a much larger single map. This is most useful for the outdoor world maps, where it is not practical to have on massive map, but the old style tiling method (copying areas of the adjoining map to the next one) are not very efficient.
The transfer of objects from one map to another tiled map are automatic. Presuming the proper macros are used (out_of_map, get_map_..), minimal extra work is necessary for everything to work right.
@@ -118,9 +118,9 @@
The value is derived as being half the maximum viewable area. The reason for this is that the line of sight code (and likely some other code) will only look one map away from a source coordinate. While the values can be less than 12, they should be at least 12 if the map tiles with another one in that direction. If the map is an 'end' map (ie, no further tiling in a specific direction), then having a value less than 12 should work just fine.
Note that tiles maps do not have to be symmetric - several maps could tile to a common map. That common map can only tile back to one of those. And example of where this might be used is for a courtyard of a multi floor house - that courtyard should be visible (and be the same) from all the levels, but you can only go from the courtyard to first floor rooms off the courtyard. This may not be ideal (ie, if flying, you should be able to go to any floor), but this tiling for elevation is just an example that can be used.
- =====4. Stacking of Objects on the Map=====
+ ======4. Stacking of Objects on the Map======
The stacking of objects on a map is somewhat confusing. This is because there are really two stacks a designer may care about - the actual stacking of objects on the map (as op->above points to) and the stacking of objects as they appear to the client.
It is usually the appearance in the client the designers care most about. However, actual stacking in the code can be important - some objects only look for objects above them - if you put a teleporter above a sword, that is different than if you put the teleporter below the sword.
@@ -128,9 +128,9 @@
When loading a map from disk, the server will keep the same stacking order as set in the map. Note however that multipart (big) objects are handled specially - because only the head of the object is saved, the stacking for the non head objects is always right above the floor. So if you put a troll down, with its head above a sword, when the rest of it is linked in, those other parts will be below any items on the ground.
Additional objects put on the space during play will generally be in stack order - newest object is on top. The one real exception is that flying objects (spells typically) will always be put on the top of the space, and then followed by non flying objects. So if a sword is dropped on a space with a bunch of active spell objects, within the server stacking, the sword will be below the spell objects, but above other objects on the space.
- ====Layers====
+ =====Layers=====
This ordering of objects in the server has little relation to how things appear in the client. With the client (and map2 protocol command), there are 10 visible layers, displayed in following order (from bottom up):
Floor (by definition, nothing beneath a floor is visible)
@@ -148,9 +148,9 @@
There can be other cases where map maker want to change layering. A current case is levitation boots - because they seem to fly, they would normally always be drawn on top of other objects. The archetype sets the map_layer flag to item, so that they will be drawn with the rest of the pickable objects.
In cases of there being more objects of a type than can be displayed on a space, the first fallback is to look at the visibility of the defined face. Visibility is a face, not object, attribute, but is used when certain objects should take viewing precedence over others. An example of its use is buildings and exits - you pretty much always want those visible, even if there are other non-pickable objects on the space (or a player casts some runes).
- ====Visibility====
+ =====Visibility=====
If the visibility for the face is the same, the last fallback is server (map) stacking. In this case, the object on the top of the stack will take precedence of objects further down. Note however that visibility is always used to put important objects higher on the space as far as the clients sees them. For example, suppose we have the following space with objects with the hypothetical visibilities:
mace (50)
@@ -163,5 +163,86 @@
But that is not the case - the high visibility of the bow causes it to be virtually placed above the other objects in the map view, so actual view would be bow, mace, sword, floor.
Because visibility is not an object attribute, there is generally little that can be done to control this, other than to set up the appropriate stacking.
+
+ ======5. Smoothing======
+
+ Author Tchize
+ Date: Seven of July 2003
+
+ =====Introduction to Smoothing=====
+
+ The crossfire graphical interface and internal map handling relies on a map made of square. No object can lies between squares. A typical square has the size of a standing player or other humanoïd sized creature (Goblins, Orcs, Gnolls, Dwarvens, Elves, ...). This lead to an awful interface concerning terrains transitions (Sea shores, road borders, mountains, a.s.o)
+
+ There are 2 ways to get rid of this problem:
+
+ * Suppress the square by square behavior of map handling. This means rework half of Crossfire code and redraw all maps
+ * Use some magic illusion.
+
+ =====What is Smoothing=====
+
+ Large discussions in the cf-devel mailing list was around a document on terrain transitions available on [http://www.gamedev.net/reference/articles/article934.asp].
+ It explains a way of handling terrain transition in cases like the one of Crossfire.
+
+ Consider the smoothing in Crossfire as the ability for an object to draw itself partially above the surrounding squares. For example, grass could overlap just a bit the road next to it, a mountain would not end abruptly but instead would have some hills above the neighbor sand.
+
+ =====How to Smooth?=====
+
+ Next of this document is divided in 2 parts. Drawers should be interested only in first part while developers may be interested in both parts.
+
+ ====Basic Smoothing====
+
+ Basically, there need to be some order for smoothing. If everything draws itself above every surrounding square, we would end up with some awful bunch of crappy disgusting mixture of color (a Picasso or alike).
+
+ So, we come to the...
+
+ ===First Rule of Smoothing===
+
+ An object O may draw itself above a neighbor object V if, and only if, 0 as a <<smoothlevel>> higher than V. See the things like that:
+
+ {img/smoothlevel.eps}
+
+ O in the example picture has a higher priority than V so O will overlap V a bit but V will not overlap O.
+
+ The smoothlevel is an integer value ranging from 0 (overlap nothing) to 255 (overlap above everything except other objects having also smoothlevel of 255). This is important to consider when you are going to give the smoothing ability to new objects. Let's say, for example, you want to add this ability to mountains. Let's imagine has a smoothlevel of 10 and trees have a smoothlevel 100 (just imagine, at time writing this doc, nothing fixed yet). Now let's say you want the mountains above the grass but, for graphical reasons, you want the trees above the mountains. You Choose a value between 10 and 100, not included. But mountains is a thing that goes above a lot of thing (grass, hills, swamps, brush, rocks, desert,...). So to keep the place for adding new elements in the future, you rather choose a high value for mountains (90 seems a good value according to these conditions).
+
+ So now you have chosen the smoothlevel for the mountain. What are you supposed to draw? You know what overlap what is decided by smoothlevel. But the graphics used during the smoothing is the...
+
+ ===Second Rule of Smoothing===
+
+ The picture used to draw a given object depend on the face of the object. All objects using the grass face, for example, if they have a smoothlevel higher than 0, will be smooth using the same pictures. So you will bind with the picture grass.111 a set of pictures telling the client what to draw when smoothing an object having the face grass.111.
+
+ Take a look at the canvas below:
+
+ {img/canvas_smooth.eps}
+
+ Each square have a size of 32x32, which is the size used by the current image sets. This canvas handles all cases of corner, borders, L shaped, U shaped and O shaped transitions. The picture is made of 16 elements by 2. The first line is all broder related transition. The second line is corner related transitions. Here is an example picture for grass (yeah really need someone to rework it):
+
+ {img/sgrass.base.111.eps}
+
+ The picture is named sgrass.base.111.png and located in the ground/smooth/grasslike directory of archetype. Ok, now you have a picture for smoothing grass, you have a smoothlevel for grass. There is only one last thing to do:
+
+ ===Final Rule of Smoothing===
+
+ Tell the server which picture to send the client. There is, in the server SVN directory a file named lib/smooth. This file is where you set this information. Each line in the file beginning with \emph{\#} is a comment. Other line should be made of 2 elements:
+
+ The first is the picture you want to smooth (here it is grass.111%
+
+ \footnote{Please note we suppressed the .png and the .base. elements of grass.base.111.png filename. Since what the server needs is the internal names. Take care of this. If the new picture you drawn didn't appear on the GUI, this is perhaps due to error in this file. And don't forget to copy this file, afterwards, to the install directory of server, using a make~install.%
+
+ }) the second is the 512x64 picture drawn at rule 2 and used when smoothing.
+
+ And example line might be as follows:
+
+ grass.111 sgrass.111
+
+ The entry default\_smoothed.111 is used when the server can not find an appropriate entry for an object. This correspond to the black canvas above so mapmakers or drawers can see immediately there is a problem.
+
+ Now, drawers know everything. Coders might want to read following part.
+
+ ====Smoothing in the Code====
+
+ Guess what...
+
+ TODO
IP-Address : 70.254.34.228
Old Revision: http://wiki.metalforge.net/doku.php/map-technical?rev=1192675098
New Revision: http://wiki.metalforge.net/doku.php/map-technical
--
This mail was generated by DokuWiki at
http://wiki.metalforge.net/
More information about the crossfire-wiki
mailing list