Simba/Doc/mufasa_developers.tex

\documentclass[a4paper, 10pt]{report} % perhaps book?

% For images
\usepackage{graphicx}

% For URLs

\usepackage{url}

% For all our math joys
\usepackage{amsmath}

% For correct line-breaking.
\usepackage[english]{babel}

% Syntax highlighting.
\usepackage{listings}

\usepackage{color}

\setlength{\parskip}{1.5ex}

\begin{document}
\title{Mufasa Developers Manual}
\author{Merlijn Wajer (Wizzup?) \and Raymond van Veneti\"{e} (mastaraymond)}
\maketitle
\tableofcontents
\lstset{language=Pascal}
\definecolor{lightgray}{rgb}{0.9,0.9,0.9} 
\definecolor{mycommentcol}{rgb}{0.2,0.2,0.8} 

\lstset{morecomment=[l][\color{mycommentcol}]{//},
morecomment=[s][\color{mycommentcol}]{/*}{*/}}
\lstset{backgroundcolor=\color{lightgray}}

\chapter{Foreword}

A word of thanks to the SRL Community\footnote{http://villavu.com/} and some of
it's members.
The following persons (in no particular order) have contributed in some way to
Simba, note that not all names correspond to the real name of a person, but
rather to their corresponding internet name.
Benjamin J Land (aka BenLand100), Nielsie95, Markus, Bullzeye95,
Yakman, Mixster, ss23, Nava2, Dgby714, Widget.

A special word of thanks goes to Frederic Hannes (Freddy1990) for maintaining
his program\footnote{SCAR, http://freddy1990.com}, for giving us inspiration
and generally for all the time he has put in SRL.

That's about it for the foreword, we hope this Document will be of any use to
you as reader.

Wizzup? and Raymond

\chapter{Introduction}

This is the Simba / MML (Mufasa Macro Library) documentation, aimed at
developers. The document will take several different approaches in treating and
explaining Simba / MML internals. We will first discuss the general 
structure of a particular subject, and if necessary, spent a few sections
on files linked with the subject. 
As Simba depends heavily on the MML and the MML can also actively be used in 
other languages, we will first discuss the MML, and then turn to Simba.

\chapter{MML}

The MML\footnote{Mufasa Macro Library} consists out of several
modular\footnote{Even though they are seen as modular, some have dependencies on
other modules} classes / objects. Each of these classes strive to be
completely platform independent. We will look at each of these classes.
\footnote{
The last class - TMFiles - may be removed in the future, as it doesn't
perform any special operations that are hard to do on other platforms or
operating systems.
}

\begin{itemize}
    \item   TIOManager
    \item   TMFinder
    \item   TMBitmaps
    \item   TMDTM
    \item   TMOCR
    \item   TMFiles
\end{itemize}

And finally, to bundle all these components into one class, the MML contains a
TMClient class, which simply initialises all the previously mentioned classes
when it is created, and destroys them when it is destroyed. It also allows
modules to access other modules, using the TMClient reference.

\section{TMClient}

\subsection{Introduction}

% Don't confuse with a client

\section{TIOManager}


\subsection{Introduction}

\subsection{TTarget}
\subsection{TRawTarget}
\subsection{TBitmapTarget}
\subsection{TWindow\_Abstract}
\subsection{TEIOS\_Client}
\subsection{TEIOS\_Target}
\subsection{TEIOS\_Controller}
\subsection{TTarget\_Exported}
\subsection{TIOManager\_Abstract}

\section{TMFinder}

\subsection{Introduction}

The TMFinder class is basically a large collection of different object
\footnote{Object being either a colour, bitmap or dtm} ``finding'' methods.
It has a reference to it's ``parent'' Client object, since it needs to have
access to TIOManager for retreiving client data, and access to managed bitmaps
and dtm's in TMBitmaps and TMDTM.


\subsection{Caching}
% ClientTPA + CachedWidth/CachedHeight.

\subsection{Colour Comparison Algorithms}

% CTS 0,1,2


\section{TMBitmaps}

\section{TMDTM}

\subsection{The DTM}

DTM is shorthand for Deformable Template Model. \\

\emph{``DTM'' is the term used in SCAR. If it is actually a Deformable Template
Model is definately debateable; but for now we will stick to ``DTM''.} \\

A DTM is in my view just a relatively simple way of defining a relationship
between several points. Each of these points have a relative offset to each
other, and may differ in colour, tolerance, area size and shape.
A DTM consists out of one \textbf{Main Point}, and several \textbf{Sub Points}
The structure of a DTM looks like this:

\begin{figure}[ht]
    \includegraphics[scale=0.4]{Pics/DTM}
    \caption{Structure of a DTM.}
\end{figure}

Where each point in a DTM has a colour, tolerance, area size and area shape
entity. The main point's ``point'' is typically $ (0, 0) $, and all the
sub point points are arelative to the main point. ``Point Match'' defines if a point should match or should \textbf{Not} match.

Of course, the actual representation in Pascal is slightly different:


\begin{lstlisting}
  pDTM = record
    l: Integer;
    p: TPointArray;
    c, t, asz, ash: TIntegerArray;
    bp: Array Of Boolean;
    n: String;
  end;
\end{lstlisting}

\subsubsection{DTM Example}

If one was to create his own DTM, he\footnote{Or she} would first have to
think of a useful DTM structure.

Say:
$$ MainPoint = (123, 456)  $$
$$ SubPoint_1 = (122, 460) $$
$$ SubPoint_2 = (120, 450) $$

Then we could create the following pDTM structure:

\begin{lstlisting}
	// Give dtm.p a length of three.
	// Mainpoint
	dtm.p[0] = Point(123, 456);

	// Subpoints
	dtm.p[1] = Point(122, 460)
	dtm.p[2] = Point(120, 450)
\end{lstlisting}

Note that we do not include other variables, such as colour, tolerance, area
size and area shape; but they should be handled in a similar manner.

However, this code is not very clear about the relation between the DTM's
 points. Better would be to write:

\begin{lstlisting}
    // Give dtm.p a length of three.
    // Mainpoint
    dtm.p[0] = Point(0, 0);

    // Subpoints
    dtm.p[1] = Point(-1, 4)  // 122 - 123 = -1, 460 - 456 = 4
    dtm.p[2] = Point(-3, -6) // 120 - 123 = -3, 450 - 456 = -6
\end{lstlisting}

As you can see it is perfectly valid to use negative points.

\subsubsection{Color and Tolerance}

The colour value of a point in a DTM is just a RGB integer value.
Black = 0, Red = 255, White = 16777215, et cetera.

The value tolerance decides if a colour is similar enough to the given
colour; if this is the case, we say that the colours \textbf{matched}.

With no Area Size and Area Shape specified\footnote{Read: with Area
Size = 0 and Area Shape = Rectangle} we say that a DTM matches if for each
point in the DTM, the colour at the relative point matches the colour in dtm
with the given tolerance.

$$ \forall p \in P, \forall t \in Tol, \forall c \in Col : T(C(p), c) \leq t
 $$

With C() defining the colour at the given point, and T() defining the tolerance
between the two given colours.

\subsubsection{Area Size and Shape}

Area Size and Shape add that nifty extra functionality to DTM's.
\textbf{Area Size} defines the area that should all match the colour
with the given tolerance. \\
\textbf{Area Shape} is currently not implemented, mainly because
we haven't found a good use for area shapes.

\subsection{How does TMDTM fit in?}

The TMDTM class is a DTM manager. It provides methods to add, store, load
and free DTM's. It has a few other features. One of it's other features
is keeping track of what DTMs are unfreed. It can also, for example help you
find a bug in your code, by printing out information of the DTM that you forgot to free.
You can also give names to DTMs, which eases debugging even further.

If you try to access an invalid DTM, the MML will throw an exception.

\section{TMOCR}

\section{TMFiles}

\section{Finding algorithms}

\section{Portability to other languages}

Since it is near to impossible to simply import the MML classes, we are
currently writing a library called `libmml', which offers a non-OOP wrapper
around the MML library.


\chapter{Simba - General}
% Loading/Saving
% Auto updating
% Settings?
% Code Completion?

\chapter{Simba and PascalScript}


\end{document}