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