Menu
▾
▴
[Crossfire-cvs] SF.net SVN: crossfire:[19287] arch/trunk
|
From: Crossfire C. r. messages.
<cro...@li...> - 2014-03-29 00:13:31
|
Revision: 19287
http://sourceforge.net/p/crossfire/code/19287
Author: partmedia
Date: 2014-03-29 00:13:23 +0000 (Sat, 29 Mar 2014)
Log Message:
-----------
Combine naming guide with README, convert to AsciiDoc.
Modified Paths:
--------------
arch/trunk/README
Removed Paths:
-------------
arch/trunk/Naming.doc
Deleted: arch/trunk/Naming.doc
===================================================================
--- arch/trunk/Naming.doc 2014-03-23 16:03:28 UTC (rev 19286)
+++ arch/trunk/Naming.doc 2014-03-29 00:13:23 UTC (rev 19287)
@@ -1,262 +0,0 @@
-archetype-file NAME.arc
-
-image-file
-
- NAME.PDA
-
- where
- P - part number
- D - coding, or any other instance
- coding in
- A - animation phase
-
-numbering, PDA
-
- - 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, A, B, C, D, E, F, ..., Z
- - Alphanumeric
- - Can be thought as hexadecimals
-
-name NAME:
-
- - Maximum of 10 characters long, so max file name is 14 characters,
- that fit into portability requirements
-
-Part numbers:
-
- 3x3 : 1 2 3
- 4 5 6
- 7 8 9
-
- 2x2 : 1 2
- 3 4
-
- 3x2 : 1 2 3
- 4 5 6
-
- 2x3 : 1 2
- 3 4
- 5 6
-
-Codings:
-
- Direction:
-
- 8 1 2
- \ | /
- 7- 0 -3
- / | \
- 6 5 4
-
- Same as in Crossfire
-
- Turnable (reflecting objects):
-
- 0 to left, vertical
- 1 to right, horizontal
-
- - also in gates, signs, ...
-
-Walls:
-
- Name format: name_X.arc, name_X.PDA.png
-
- 1
- |
- 8 -+- 2
- |
- 4
-
- X is a bit-wise combination expressed in hexadecimal form. For example,
- 8 + 4 + 2 + 1 = F describes a vertical cross, and 4 + 1 = 5 identifies a
- vertical wall.
-
- P, D, and A are always 1.
-
- f diagonal connecting points are not
- offered by the arch. If d Object Names:
-
- When creating .arc files, the object name is determined by a similar,
- but distinctly different, scheme. See the server code in
- server/build_map.c and random_maps/wall.c for the source of the
- information that follows. The arch name (ie. awall) must not have any
- underscores. A suffix in the form _U[_V[_W]] is appended to the arch
- name.
-
- U is the number of connection points (ie. for a pillar U == 0, and for
- a cross U == 4).
-
- At the time of this writing, the formulae for calculating V and W is
- not known, but, U, V, and W can be determined as follows. Calculate a
- value called "connect" by adding the values of the connecting points:
-
- 4
- |
- 1 -0- 2
- |
- 8
-
- Then use "connect" to pick a suffix:
-
- 0: _0
- 1: _1_3
- 2: _1_4
- 3: if (has_window)
- _win2
- else
- _2_1_2
- 4: _1_2
- 5: _2_2_4
- 6: _2_2_1
- 7: _3_1
- 8: _1_1
- 9: _2_2_3
- 10: _2_2_2
- 11: _3_3
- 12: if (has_window)
- _win1
- else
- _2_1_1
- 13: _3_4
- 14: _3_2
- 15: _4
-
- For a complete example, a vertical cross wall graphic in an awall arch set
- is named awall_F.base.111.png. Face information is kept in awall_F.face,
- and the archetype data is in awall.arc. Inside awall.arc, the Object name
- is awall_4.
-
-Diagonal (extended) walls, roads, etc.
-
- The legacy wall-naming convention is used in conjunction with the
- extension to the name format described here to provide a uniform naming
- scheme that supports corner connections. Legacy names do not need to
- change to simply add diagonal versions of the legacy graphics.
-
- The name format is name_XY.arc, name_XY.PDA.png
-
- X follows the same rules as used for the legacy wall format, except that
- when there are no NSEW connecting points, X == 0.
-
- Y may be omitted, or may be 0 if diagonal connecting points are not
- offered by the arch. If diagonal connecting points are implemented, Y is
- a bit-wise combination computed in the same manner as X, and is also
- expressed as a hexadecimal digit. The difference is that it refers to
- corner connections:
-
- 1 2
- \ /
- X
- / \
- 8 4
-
- For example, name_0F refers to a diagonal cross, or connecting points in
- all four corners. name_05 and name_0A refer to pure diagonals.
-
- Since diagonal pieces require corner fills, P is used to differentiate the
- component parts of the diagonal.
-
- P (part number) ranges from 1 to 3.
-
- 1 : used for "normal" pieces that connect direction points.
-
- 2 : used for a top corner fill needed to complete diagonal
- connections.
-
- 3 : used for a bottom corner fill needed to complete diagonal
- connections.
-
- Examples of diagonal files are dirtroad_05.211, dirtroad_05.311,
- dirtroad_0A.211, and dirtroad_0A.311. The archetypes for these
- are stored in dirtroad_05.arc and dirtroad_0A.arc. The corner
- fill is a "part" of a diagonal, and is not really useful on its
- own.
-
- The .211 and .311 file names are based on the full diagonal, but
- are used for all diagonal connecting points. Usually it is not
- necessary to customize the corner piece to fit each and every
- possible XY combinationi that incorporates a diagonal connecting
- point.
-
- Object Names:
-
- When creating object names, use a different format (_U_XYP) unless
- the legacy naming format can be figured out and adapted to the
- diagonal set - in which case, it should be documented here. This
- format allows consistent object naming in the event that renaming is
- desirable in the future, and it does not collide with the legacy
- object naming.
-
- U = Number of connecting points.
- XY = Where X and Y are re-used as described above.
- P = Where P is the part number.
-
-Cave:
-
- Complex
-
-River names:
-
- NOTE: Consider deprecation of this format in favor of the extended wall
- naming. It is more flexible than this format.
-
- Simple diagonals, like non-branched rivers, are saved as name_XY.arc and
- name_XY.PDA.png.
-
- X and Y use the direction scheme shown above (and copied here for
- ease of reference). For example, river_15 runs north/south; river_26
- runs from the northeast to the southwest.
-
- 8 1 2
- \ | /
- 7- 0 -3
- / | \
- 6 5 4
-
- X and Y do not define direction of water flow. They are simply
- connecting points to neighboring arches of the same set. X and Y are
- ordered low to high, so it is not expected that a river_62 exist;
- instead the piece is named river_26.
-
- A cul-de-sac, or dead-end could have X == 0 and Y set to the connect
- point. Conceptually, a pool could follow this same naming convention
- and set X == Y == 0.
-
- D and A are presently always set to 1.
-
- P ranges from 1 to 3.
-
- 1 : used for "normal" pieces that connect direction points.
-
- 2 : used for a top corner wedge used to fill in diagonals (i.e. A
- wedge in the top right or top left corner).
-
- 3 : used for a bottom corner wedge used to fill in diagonals (i.e.
- A wedge in the bottom right or bottom left corner).
-
- Examples of wedges are river_48.211, river_48.311, river_26.211,
- and river_26.311. The archetypes for these are stored in
- river_48.arc and river_26.arc. The wedge is a "part" of a
- diagonal, and is not really useful on its own.
-
- River junctions, add another digit to the format used by simple diagonals,
- and are stored as name_XYZ.arc and name_XYZ.PDA.
-
- X, Y, and Z represent the three directions the river exits. 367 would
- be east,southwest, and west. Junctions, or branchesi, may also have
- multiple parts - this happens when the junction has a diagonal
- direction.
-
- By convention, directions for the river parts are in ascending order.
- That is, if the exit locations are 2, 6, 3, the name could be
- branch_236 (not branch_326, or branch_623, etc).
-
- Complex branching paths could be set by adding digits to allow four or
- more connecting points, but use of the extended walls format is
- recommended instead.
-
-Modified:
-
- 93/08 he...@lu... - created
- 94/05 ma...@ra... - updated river definitions.
- 10/06 kbulgrien - rewrite & add extended wall name format.
-
Modified: arch/trunk/README
===================================================================
--- arch/trunk/README 2014-03-23 16:03:28 UTC (rev 19286)
+++ arch/trunk/README 2014-03-29 00:13:23 UTC (rev 19287)
@@ -1,41 +1,48 @@
-This is a generic README file for the arch directory.
-You should also read the CHANGES for and Naming.doc file.
+Crossfire Archetype Guide
+=========================
+Crossfire Development Team <cro...@me...>
+1.70.0-dev, March 2014
+:numbered:
+:toc:
- The color bitmap files use the XPM library (called xpm-3.4f on
-most ftp sites. A later version may be out now.)
+Pixmaps
+-------
+The color bitmap files use the XPM library (called xpm-3.4f on
+most ftp sites. A later version may be out now.)
- This library is needed in order to compile crossfire with the color
+This library is needed in order to compile crossfire with the color
pixmap support.
- The pixmap files have the same name as the bitmap file with ".xpm"
-concatenated to the end. If your system has short filename length
+The pixmap files have the same name as the bitmap file with ".xpm"
+concatenated to the end. If your system has short filename length
limits, this may cause a problem.
- I use 'pixmap' to edit the xpm files. This should be available the
-same place the xpm library can be found. It does require the xpm
+I use `pixmap` to edit the xpm files. This should be available the
+same place the xpm library can be found. It does require the xpm
library.
-All of the XPM files have been colored. However, only a small number
+All of the XPM files have been colored. However, only a small number
have actually been done so properly - that is, by hand, and with the
-proper outlines. Many people are working on fixing more of these up.
+proper outlines. Many people are working on fixing more of these up.
- If you do start to work on colorizing the other directories, please
-let me know. Otherwise, you may start working on something that someone
+If you do start to work on colorizing the other directories, please
+let me know. Otherwise, you may start working on something that someone
else has already done.
The file xpm.template in the dev directory is a XPM file that has all of
-the colors that are allowable for XPM files. This is to limit the total
+the colors that are allowable for XPM files. This is to limit the total
number of colors used, in order not of overrun color spaces on systems.
If you really need a color not in that file, please send mail to Mark
Wedel (mw...@py...), and it might be added to the list of
acceptable colors.
-For a list of colors to use, look at the dev/xpm.template file.
+For a list of colors to use, look at the 'dev/xpm.template' file.
+Mark Wedel
+mw...@py...
- Mark Wedel
-mw...@py...
-----
+Perspective
+~~~~~~~~~~~
Some coloring/perspective hints/clarifications from David Sundqvist:
Perspective in Crossfire is based on the XY coordinate system of possible
@@ -51,3 +58,255 @@
Wind is generally coming from the left side, so smoke or other things
affected by wind should be travelling towards the right side.
+
+Naming Conventions
+------------------
+
+Archetype File Name
+~~~~~~~~~~~~~~~~~~~
+The name of an archetype file should be no more than 10 characters long, for
+a total of 14 characters in the entire file name. This is to ensure maximum
+portability across different systems.
+
+NOTE: Is this still a limitation?
+
+Archetype file names should end with an extension of '.arc'. Image files
+have a 3-digit extension in the form of '.PDA', where:
+
+ P - part number
+ D - coding, or any other instance
+ coding in
+ A - animation phase
+
+Numbering (PDA)
+^^^^^^^^^^^^^^^
+
+ - 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, A, B, C, D, E, F, ..., Z
+ - Alphanumeric
+ - Can be thought as hexadecimals
+
+Part Numbers
+^^^^^^^^^^^^
+
+ 3x3 : 1 2 3
+ 4 5 6
+ 7 8 9
+
+ 2x2 : 1 2
+ 3 4
+
+ 3x2 : 1 2 3
+ 4 5 6
+
+ 2x3 : 1 2
+ 3 4
+ 5 6
+
+Codings
+^^^^^^^
+
+.Direction
+
+ 8 1 2
+ \ | /
+ 7- 0 -3
+ / | \
+ 6 5 4
+
+ Same as in Crossfire
+
+.Turnable (reflecting objects)
+
+ - 0 to left, vertical
+ - 1 to right, horizontal
+ - also in gates, signs, ...
+
+Walls
+~~~~~
+
+Name format: 'name_X.arc', 'name_X.PDA.png'
+
+ 1
+ |
+ 8 -+- 2
+ |
+ 4
+
+X is a bit-wise combination expressed in hexadecimal form. For example,
+8 + 4 + 2 + 1 = F describes a vertical cross, and 4 + 1 = 5 identifies a
+vertical wall.
+
+P, D, and A are always 1.
+
+.Object Names
+
+When creating '.arc' files, the object name is determined by a similar,
+but distinctly different, scheme. See the server code in
+'server/build_map.c' and 'random_maps/wall.c' for the source of the
+information that follows. The arch name (ie. awall) must not have any
+underscores. A suffix in the form _U[_V[_W]] is appended to the arch
+name.
+
+U is the number of connection points (ie. for a pillar U == 0, and for
+a cross U == 4).
+
+At the time of this writing, the formulae for calculating V and W is
+not known, but, U, V, and W can be determined as follows. Calculate a
+value called "connect" by adding the values of the connecting points:
+
+ 4
+ |
+ 1 -0- 2
+ |
+ 8
+
+Then use "connect" to pick a suffix:
+
+ 0: _0
+ 1: _1_3
+ 2: _1_4
+ 3: if (has_window)
+ _win2
+ else
+ _2_1_2
+ 4: _1_2
+ 5: _2_2_4
+ 6: _2_2_1
+ 7: _3_1
+ 8: _1_1
+ 9: _2_2_3
+ 10: _2_2_2
+ 11: _3_3
+ 12: if (has_window)
+ _win1
+ else
+ _2_1_1
+ 13: _3_4
+ 14: _3_2
+ 15: _4
+
+For a complete example, a vertical cross wall graphic in an awall arch set
+is named awall_F.base.111.png. Face information is kept in awall_F.face,
+and the archetype data is in awall.arc. Inside awall.arc, the Object name
+is awall_4.
+
+Diagonal Walls and Roads
+~~~~~~~~~~~~~~~~~~~~~~~~
+The legacy wall-naming convention is used in conjunction with the extension
+to the name format described here to provide a uniform naming scheme that
+supports corner connections. Legacy names do not need to change to simply
+add diagonal versions of the legacy graphics.
+
+The name format is 'name_XY.arc', 'name_XY.PDA.png'
+
+X follows the same rules as used for the legacy wall format, except that
+when there are no NSEW connecting points, X == 0.
+
+Y may be omitted, or may be 0 if diagonal connecting points are not offered
+by the arch. If diagonal connecting points are implemented, Y is a bit-wise
+combination computed in the same manner as X, and is also expressed as a
+hexadecimal digit. The difference is that it refers to corner connections:
+
+ 1 2
+ \ /
+ X
+ / \
+ 8 4
+
+For example, name_0F refers to a diagonal cross, or connecting points in
+all four corners. name_05 and name_0A refer to pure diagonals.
+
+Since diagonal pieces require corner fills, P is used to differentiate the
+component parts of the diagonal.
+
+P (part number) ranges from 1 to 3:
+
+ 1 : used for "normal" pieces that connect direction points.
+
+ 2 : used for a top corner fill needed to complete diagonal
+ connections.
+
+ 3 : used for a bottom corner fill needed to complete diagonal
+ connections.
+
+Examples of diagonal files are 'dirtroad_05.211', 'dirtroad_05.311',
+'dirtroad_0A.211', and 'dirtroad_0A.311'. The archetypes for these are stored
+in 'dirtroad_05.arc' and 'dirtroad_0A.arc'. The corner fill is a "part" of a
+diagonal, and is not really useful on its own.
+
+The '.211' and '.311' file names are based on the full diagonal, but are used
+for all diagonal connecting points. Usually it is not necessary to
+customize the corner piece to fit each and every possible XY combinationi
+that incorporates a diagonal connecting point.
+
+.Object Names
+
+When creating object names, use a different format (_U_XYP) unless
+the legacy naming format can be figured out and adapted to the
+diagonal set - in which case, it should be documented here. This
+format allows consistent object naming in the event that renaming is
+desirable in the future, and it does not collide with the legacy
+object naming.
+
+ U = Number of connecting points.
+ XY = Where X and Y are re-used as described above.
+ P = Where P is the part number.
+
+Rivers
+~~~~~~
+WARNING: Consider deprecation of this format in favor of the extended wall
+naming. It is more flexible than this format.
+
+Simple diagonals, like non-branched rivers, are saved as 'name_XY.arc' and
+'name_XY.PDA.png'.
+
+X and Y use the direction scheme shown above (and copied here for ease of
+reference). For example, river_15 runs north/south; river_26 runs from the
+northeast to the southwest.
+
+ 8 1 2
+ \ | /
+ 7- 0 -3
+ / | \
+ 6 5 4
+
+X and Y do not define direction of water flow. They are simply connecting
+points to neighboring arches of the same set. X and Y are ordered low to
+high, so it is not expected that a river_62 exist; instead the piece is
+named river_26.
+
+A cul-de-sac, or dead-end could have X == 0 and Y set to the connect point.
+Conceptually, a pool could follow this same naming convention and set
+X == Y == 0.
+
+D and A are presently always set to 1.
+
+P ranges from 1 to 3.
+
+ 1 : used for "normal" pieces that connect direction points.
+
+ 2 : used for a top corner wedge used to fill in diagonals (i.e. A
+ wedge in the top right or top left corner).
+
+ 3 : used for a bottom corner wedge used to fill in diagonals (i.e.
+ A wedge in the bottom right or bottom left corner).
+
+Examples of wedges are river_48.211, river_48.311, river_26.211, and
+river_26.311. The archetypes for these are stored in river_48.arc and
+river_26.arc. The wedge is a "part" of a diagonal, and is not really useful
+on its own.
+
+River junctions, add another digit to the format used by simple diagonals,
+and are stored as name_XYZ.arc and name_XYZ.PDA.
+
+X, Y, and Z represent the three directions the river exits. 367 would be
+east,southwest, and west. Junctions, or branchesi, may also have multiple
+parts - this happens when the junction has a diagonal direction.
+
+By convention, directions for the river parts are in ascending order. That
+is, if the exit locations are 2, 6, 3, the name could be branch_236 (not
+branch_326, or branch_623, etc).
+
+Complex branching paths could be set by adding digits to allow four or more
+connecting points, but use of the extended walls format is recommended
+instead.
This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site.
|