doc/Developers/smooth.tex

%% LyX 1.3 created this file.  For more info, see http://www.lyx.org/.
%% Do not edit unless you really know what you are doing.
\documentclass[english]{article}
\usepackage{pslatex}
\usepackage[T1]{fontenc}
\usepackage[latin1]{inputenc}
\usepackage{graphicx}
\IfFileExists{url.sty}{\usepackage{url}}
                      {\newcommand{\url}{\texttt}}

\makeatletter
\usepackage{babel}
\makeatother
\begin{document}

\title{Documentation on smoothing\\
Draft}


\author{Tchize}


\date{Seven of July 2003}

\maketitle

\section{Introduction}

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 awfull
interface concerning terrains transitions (Sea shores, road borders,
mountains, a.s.o)

There are 2 ways to get rid of this problem:

\begin{itemize}
\item Suppress the square by square behaviour of map handling. This means
rework half of crossfire code and redraw all maps
\item Use some magic illusion.
\end{itemize}

\section{What is smoothing}

Large discussions in the cf-devel mailing list was around a document
on terrain transitions available on \url{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 moutain would'nt
end abruptly but instead would have some hills above the neighbor
sand.


\section{How to smooth?}

Next of this document is divided in 2 parts. Drawers should be interrested
only in first part while developpers may be interested in both parts.


\subsection{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 crapy disgusting mixture of color (a Picasso or
alike).

So, we comme to the

\begin{flushright}\textbf{First Rule}\end{flushright}

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:

\includegraphics{img/smoothlevel.eps}

O in the exampel 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 moutains
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 on hell
are you supposed to draw? You know what overlap what is decided by
smoothlevel. But the graphics used during the smoothing is the 

\begin{flushright}\textbf{Second Rule}\end{flushright}

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:

\noindent \includegraphics[%
  width=1.0\columnwidth]{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):

\begin{flushleft}\includegraphics[%
  width=1.0\columnwidth]{img/sgrass.base.111.eps}\end{flushleft}

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:

\begin{flushright}\textbf{Final Rule}\end{flushright}

Tell the server which picture to send the client. There is, in the
server CVS 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 follow:

\texttt{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 immediatly there is a problem.

Now, drawers know everything. Coders might want to read following
part.


\subsection{Smoothing in the code}

Guess what...

TODO
\end{document}
Revision:	1.1.1.1 (vendor branch)
Committed:	Fri Feb 3 07:12:36 2006 UTC (18 years, 5 months ago) by root
Content type:	application/x-tex
Branch:	UPSTREAM
CVS Tags:	UPSTREAM_2006_03_15, LAST_C_VERSION, STABLE, UPSTREAM_2006_02_22, difficulty_fix_merge_060810_2300, UPSTREAM_2006_02_03
Branch point for:	difficulty_fix
Changes since 1.1:	+0 -0 lines
Log Message:	initial import
#	User	Rev	Content
1	root	1.1	%% LyX 1.3 created this file. For more info, see http://www.lyx.org/.
2			%% Do not edit unless you really know what you are doing.
3			\documentclass[english]{article}
4			\usepackage{pslatex}
5			\usepackage[T1]{fontenc}
6			\usepackage[latin1]{inputenc}
7			\usepackage{graphicx}
8			\IfFileExists{url.sty}{\usepackage{url}}
9			{\newcommand{\url}{\texttt}}
10
11			\makeatletter
12			\usepackage{babel}
13			\makeatother
14			\begin{document}
15
16			\title{Documentation on smoothing\\
17			Draft}
18
19
20			\author{Tchize}
21
22
23			\date{Seven of July 2003}
24
25			\maketitle
26
27			\section{Introduction}
28
29			The crossfire graphical interface and internal map handling relies
30			on a map made of square. No object can lies between squares. A typical
31			square has the size of a standing player or other humanoīd sized creature
32			(Goblins, Orcs, Gnolls, Dwarvens, Elves, ...). This lead to an awfull
33			interface concerning terrains transitions (Sea shores, road borders,
34			mountains, a.s.o)
35
36			There are 2 ways to get rid of this problem:
37
38			\begin{itemize}
39			\item Suppress the square by square behaviour of map handling. This means
40			rework half of crossfire code and redraw all maps
41			\item Use some magic illusion.
42			\end{itemize}
43
44			\section{What is smoothing}
45
46			Large discussions in the cf-devel mailing list was around a document
47			on terrain transitions available on \url{http://www.gamedev.net/reference/articles/article934.asp}.
48			It explains a way of handling terrain transition in cases like the
49			one of crossfire.
50
51			Consider the smoothing in crossfire as the ability for an object to
52			draw itself partially above the surrounding squares. For example,
53			grass could overlap just a bit the road next to it, a moutain would'nt
54			end abruptly but instead would have some hills above the neighbor
55			sand.
56
57
58			\section{How to smooth?}
59
60			Next of this document is divided in 2 parts. Drawers should be interrested
61			only in first part while developpers may be interested in both parts.
62
63
64			\subsection{Basic smoothing}
65
66			Basically, there need to be some order for smoothing. If everything
67			draws itself above every surrounding square, we would end up with
68			some awful bunch of crapy disgusting mixture of color (a Picasso or
69			alike).
70
71			So, we comme to the
72
73			\begin{flushright}\textbf{First Rule}\end{flushright}
74
75			An object O may draw itself above a neighbor object V if, and only
76			if, 0 as a <<smoothlevel>> higher than V. See the things like that:
77
78			\includegraphics{img/smoothlevel.eps}
79
80			O in the exampel picture has a higher priority than V so O will overlap
81			V a bit but V will not overlap O.
82
83			The smoothlevel is an integer value ranging from 0 (overlap nothing)
84			to 255 (overlap above everything except other objects having also
85			smoothlevel of 255). This is important to consider when you are going
86			to give the smoothing ability to new objects. Let's say, for example,
87			you want to add this ability to mountains. Let's imagine has a smoothlevel
88			of 10 and trees have a smoothlevel 100 (just imagine, at time writing
89			this doc, nothing fixed yet). Now let's say you want the moutains
90			above the grass but, for graphical reasons, you want the trees above
91			the mountains. You Choose a value between 10 and 100, not included.
92			But mountains is a thing that goes above a lot of thing (grass, hills,
93			swamps, brush, rocks, desert,...). So to keep the place for adding
94			new elements in the future, you rather choose a high value for mountains
95			(90 seems a good value according to these conditions).
96
97			So now you have chosen the smoothlevel for the mountain. What on hell
98			are you supposed to draw? You know what overlap what is decided by
99			smoothlevel. But the graphics used during the smoothing is the
100
101			\begin{flushright}\textbf{Second Rule}\end{flushright}
102
103			The picture used to draw a given object depend on the face of the
104			object. All objects using the grass face, for example, if they have
105			a smoothlevel higher than 0, will be smooth using the same pictures.
106			So you will bind with the picture grass.111 a set of pictures telling
107			the client what to draw when smoothing an object having the face grass.111.
108			Take a look at the canvas below:
109
110			\noindent \includegraphics[%
111			width=1.0\columnwidth]{img/canvas_smooth.eps}
112
113			Each square have a size of 32x32, which is the size used by the current
114			image sets. This canvas handles all cases of corner, borders, L shaped,
115			U shaped and O shaped transitions. The picture is made of 16 elements
116			by 2. The first line is all broder related transition. The second
117			line is corner related transitions. Here is an example picture for
118			grass (yeah really need someone to rework it):
119
120			\begin{flushleft}\includegraphics[%
121			width=1.0\columnwidth]{img/sgrass.base.111.eps}\end{flushleft}
122
123			The picture is named sgrass.base.111.png and located in the ground/smooth/grasslike
124			directory of archetype. Ok, now you have a picture for smoothing grass,
125			you have a smoothlevel for grass. There is only one last thing to
126			do:
127
128			\begin{flushright}\textbf{Final Rule}\end{flushright}
129
130			Tell the server which picture to send the client. There is, in the
131			server CVS directory a file named lib/smooth. This file is where you
132			set this information. Each line in the file beginning with \emph{\#}
133			is a comment. Other line should be made of 2 elements:
134
135			The first is the picture you want to smooth (here it is grass.111%
136			\footnote{Please note we suppressed the .png and the .base. elements of grass.base.111.png
137			filename. Since what the server needs is the internal names. Take
138			care of this. If the new picture you drawn didn't appear on the GUI,
139			this is perhaps due to error in this file. And don't forget to copy
140			this file, afterwards, to the install directory of server, using a
141			make~install.%
142			}) the second is the 512x64 picture drawn at rule 2 and used when smoothing.
143			And example line might be as follow:
144
145			\texttt{grass.111 sgrass.111}
146
147			The entry default\_smoothed.111 is used when the server can not find
148			an appropriate entry for an object. This correspond to the black canvas
149			above so mapmakers or drawers can see immediatly there is a problem.
150
151			Now, drawers know everything. Coders might want to read following
152			part.
153
154
155			\subsection{Smoothing in the code}
156
157			Guess what...
158
159			TODO
160			\end{document}