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} |