[Scummvm-cvs-logs] SF.net SVN: scummvm:[51943] tools/branches/gsoc2010-decompiler/decompiler/ doc
pidgeot at users.sourceforge.net
pidgeot at users.sourceforge.net
Mon Aug 9 21:29:15 CEST 2010
Revision: 51943
http://scummvm.svn.sourceforge.net/scummvm/?rev=51943&view=rev
Author: pidgeot
Date: 2010-08-09 19:29:15 +0000 (Mon, 09 Aug 2010)
Log Message:
-----------
DECOMPILER: Update documentation based on feedback
Still need to replace \verb
Modified Paths:
--------------
tools/branches/gsoc2010-decompiler/decompiler/doc/Makefile
tools/branches/gsoc2010-decompiler/decompiler/doc/cfg.tex
tools/branches/gsoc2010-decompiler/decompiler/doc/codegen.tex
tools/branches/gsoc2010-decompiler/decompiler/doc/disassembler.tex
tools/branches/gsoc2010-decompiler/decompiler/doc/doc.tex
tools/branches/gsoc2010-decompiler/decompiler/doc/engine.tex
tools/branches/gsoc2010-decompiler/decompiler/doc/preamble.tex
tools/branches/gsoc2010-decompiler/decompiler/doc/restrictions.tex
Modified: tools/branches/gsoc2010-decompiler/decompiler/doc/Makefile
===================================================================
--- tools/branches/gsoc2010-decompiler/decompiler/doc/Makefile 2010-08-09 18:42:07 UTC (rev 51942)
+++ tools/branches/gsoc2010-decompiler/decompiler/doc/Makefile 2010-08-09 19:29:15 UTC (rev 51943)
@@ -1,4 +1,4 @@
-latexcmd=latex
+latexcmd=pdflatex
document=doc
dvi2ps=dvips
ps2pdf=ps2pdf
@@ -13,6 +13,4 @@
$(index) $(document)
$(latexcmd) $(document)
$(latexcmd) $(document)
- $(dvi2ps) $(document).dvi
- $(ps2pdf) $(document).ps
-$(RM) $(cleanfiles)
Modified: tools/branches/gsoc2010-decompiler/decompiler/doc/cfg.tex
===================================================================
--- tools/branches/gsoc2010-decompiler/decompiler/doc/cfg.tex 2010-08-09 18:42:07 UTC (rev 51942)
+++ tools/branches/gsoc2010-decompiler/decompiler/doc/cfg.tex 2010-08-09 19:29:15 UTC (rev 51943)
@@ -10,7 +10,7 @@
\item Perform analysis on vertices
\end{itemize}
-Calls to in-script functions are not represented with edges in the graph. This is done to keep functions separate from one another, so if your engine uses a jump as part of calling functions, you need to make sure you've given that particular jump the type kCall.
+Calls to in-script functions are not represented with edges in the graph. This is done to keep functions separate from one another, so if your engine uses a jump as part of calling functions, you need to make sure you have given that particular jump the type kCall.
The first step is handled in the constructor, while the next three steps are handled by the \verb+createGroups()+ method. The last step is handled by the \verb+analyze+ method.
@@ -20,11 +20,11 @@
When function detection is enabled, unreachable blocks of code will be treated as functions, unless the presumed entry point is located within the range of another function. The end point of the function will then be the last instruction reachable from the entry point.
-Functions detected this way will be given the name \verb+auto_+. You can use this as a prefix to the actual name to signify that the function may not actually be a function, or you can ignore it and just replace it with the name you'd normally use.
+Functions detected this way will be given the name \verb+auto_+. You can use this as a prefix to the actual name to signify that the function may not actually be a function, or you can ignore it and just replace it with the name you would normally use.
You can also have the function detection determine the end point of an existing function. To do so, \verb+_endIt+ must be the same as \verb+_startIt+ for that function. In this case, only the end point will be changed within the function; the name will stay the same.
-Note that the control flow analysis has no way of determining an appropriate name, number of arguments, return value, or metadata. You'll have to fill that in yourself using \verb+postCFG+ in the engine.
+Note that the control flow analysis has no way of determining an appropriate name, number of arguments, return value, or metadata. You will have to fill that in yourself using \verb+postCFG+ in the engine.
If this step is not enabled, and no functions have been defined before the control flow analysis is started, there will still be added a single function covering the entire script. This is done to avoid having a special case in the code, and it will not affect the output of your script in any way.
@@ -73,10 +73,10 @@
Group must end with a conditional jump (i.e., have two outgoing edges). Jump must go to an earlier place in the code.
\paragraph{While detection}
-Group must end with conditional jump. Block must have an ingoing edge from some group later in the code, unless that edge comes from a do-while condition (in which case it's assumed to be an \verb+if+ instead).
+Group must end with conditional jump. Block must have an ingoing edge from some group later in the code, unless that edge comes from a do-while condition (in which case it is assumed to be an \verb+if+ instead).
\paragraph{Break detection}
-Unconditional jump to some place later in the code. That place must either be the group immediately after a \verb+do-while+ condition, or the jump target of a \verb+while+ condition. Additionally, the jump is verified to go to the appropriate loop (so it doesn't exit multiple loops at once).
+Unconditional jump to some place later in the code. That place must either be the group immediately after a \verb+do-while+ condition, or the jump target of a \verb+while+ condition. Additionally, the jump is verified to go to the appropriate loop (so it does not exit multiple loops at once).
\paragraph{Continue detection}
Unconditional jump to a \verb+while+ or \verb+do-while+ condition, unless it is targeting a \verb+while+ condition which jumps to the next sequential group (in which case it is merely the end of the \verb+while+-loop). Just as with \verb+break+s, the jump is verified to go to the appropriate loop.
Modified: tools/branches/gsoc2010-decompiler/decompiler/doc/codegen.tex
===================================================================
--- tools/branches/gsoc2010-decompiler/decompiler/doc/codegen.tex 2010-08-09 18:42:07 UTC (rev 51942)
+++ tools/branches/gsoc2010-decompiler/decompiler/doc/codegen.tex 2010-08-09 19:29:15 UTC (rev 51943)
@@ -1,7 +1,7 @@
\section{Code generation}
\label{sec:codegen}
-Having detected all of the various control flow constructs in the previous phase, it's now time to put that information to use and generate some code from the instructions.
+Having detected all of the various control flow constructs in the previous phase, it is now time to put that information to use and generate some code from the instructions.
Code generation is implemented as a two-step process:
\begin{itemize}
@@ -26,7 +26,7 @@
\subsection{The stack and stack entries}
When generating the code, a stack is used to represent the state of the system. When data is pushed on the stack, a stack entry describing how that data was created is added; when data is popped, a stack entry describing the popped data is removed.
-To manipulate the stack, use the \verb+push+ and \verb+pop+ methods to push or pop stack entries. Unlike the STL stack, \verb+pop+ returns the value being popped from the stack, so you don't have to first get the top element and then pop it afterwards, but you can still call the \verb+peek+ method if you just want to look at the topmost element without removing it. Additionally, it has an \verb+empty+ method to check if the stack is empty.
+To manipulate the stack, use the \verb+push+ and \verb+pop+ methods to push or pop stack entries. Unlike the STL stack, \verb+pop+ returns the value being popped from the stack, so you do not have to first get the top element and then pop it afterwards, but you can still call the \verb+peek+ method if you just want to look at the topmost element without removing it. Additionally, it has an \verb+empty+ method to check if the stack is empty.
Some engines require you to look further down the stack than just the topmost element. You can use the \verb+peekPos+ method to retrieve an element at an arbitrary position in the stack. This method takes an integer containing the number of stack entries to skip, i.e. passing the value 0 will give you the topmost element, while passing the value 2 will give you the third value on the stack.
@@ -72,17 +72,17 @@
If your line of code deals with control flow, you will probably want to do something about the indentation. You can supply two extra boolean arguments to \verb+addOutputLine+ to state that the indentation should be decreased before outputting this line, and/or that the indentation should be increased for lines output after this line. If you leave out these arguments, no extra indentation is added.
-Note: This indent handling is currently considered a temporary solution until there's time to implement something better. It may be replaced with a different form of indentation handling at a later time.
+Note: This indent handling is currently considered a temporary solution until there is time to implement something better. It may be replaced with a different form of indentation handling at a later time.
You will usually need to output assignments at some point. For that, you can use the \verb+writeAssignment+ method to generate an assignment statement. \verb+writeAssignment+ takes two parameters, the first being the stack entry representing the left-hand side of the assignment operator, and the second being the stack entry representing the right-hand side of the operator.
\subsection{Default instruction handling and instruction metadata}
When disassembling, you can store metadata for a given instruction to be used during code generation.
-Default handling exists for a number of instruction types, described below. If the default handling doesn't work for a particular instruction, you can force the instruction to process by your engine specific code by placing the hexadecimal byte 0xC0 at the start of the metadata string. This character was chosen for two reasons: it is unlikely to be used as a byte in a script, and the byte is invalid in UTF-8, avoiding potential encoding conflicts. Note that if you do this, it is your own responsibility to strip off that character during processing.
+Default handling exists for a number of instruction types, described below. If the default handling does not work for a particular instruction, you can force the instruction to process by your engine specific code by placing the hexadecimal byte 0xC0 at the start of the metadata string. This character was chosen for two reasons: it is unlikely to be used as a byte in a script, and the byte is invalid in UTF-8, avoiding potential encoding conflicts. Note that if you do this, it is your own responsibility to strip off that character during processing.
\paragraph{kDup}
-The topmost stack entry is popped, and two duplicated copies are pushed to the stack. If the entry being duplicated was not already a duplicate, an assignment will be output to assign the original stack entry to a special dup variable, to show that the original entry isn't being recalculated.
+The topmost stack entry is popped, and two duplicated copies are pushed to the stack. If the entry being duplicated was not already a duplicate, an assignment will be output to assign the original stack entry to a special dup variable, to show that the original entry is not being recalculated.
\paragraph{kUnaryOp}
The topmost stack entry is popped, and a \verb+UnaryOpEntry+ is created and pushed to the stack, using the codegen metadata as the operator, and the previously popped entry as the operand. Note: currently, a \verb+UnaryOpEntry+ only supports placing the operator on the left side of the operand.
Modified: tools/branches/gsoc2010-decompiler/decompiler/doc/disassembler.tex
===================================================================
--- tools/branches/gsoc2010-decompiler/decompiler/doc/disassembler.tex 2010-08-09 18:42:07 UTC (rev 51942)
+++ tools/branches/gsoc2010-decompiler/decompiler/doc/disassembler.tex 2010-08-09 19:29:15 UTC (rev 51943)
@@ -1,4 +1,5 @@
\section{Disassembler}
+\label{sec:disassembler}
The purpose of the disassembler is to read instructions from a script file and convert them to a common, machine-readable form for further analysis.
\subsection{Instructions}
@@ -20,7 +21,7 @@
Each member of this struct has a specific purpose:
\begin{itemize}
-\item \verb+_opcode+ is used to store the numeric opcode associated with the instruction. This is not used by the decompiler itself, but is for your reference during later parts of the decompilation process. Note that this field is declared as a 32-bit integer; if you need more than 4 bytes for your opcodes, you'll need to figure out which bytes you want to store if you want to use this field.
+\item \verb+_opcode+ is used to store the numeric opcode associated with the instruction. This is not used by the decompiler itself, but is for your reference during later parts of the decompilation process. Note that this field is declared as a 32-bit integer; if you need more than 4 bytes for your opcodes, you will need to figure out which bytes you want to store if you want to use this field.
\item \verb+_address+ stores the absolute memory address where this instruction would be loaded into memory.
\item \verb+_stackChange+ stores the net change of executing this instruction - for example, if the instruction pushes a byte on to the stack, this should be set to 1. This is used to determine when each statement ends. The count can be in any unit you wish - bytes, words, bits - as long as the same unit is used for all instructions. This means that if your stack only works with 16-bit elements, pushing an 8-bit value and pushing a 16-bit value should have the same net effect on the stack.
\item \verb+_name+ contains the name of the instruction. This is mainly for use during code generation.
@@ -45,6 +46,8 @@
Three convenience methods are provided to extract the value, \verb+getSigned+, \verb+getUnsigned+ and \verb+getString+. Please note: if an incorrect method is called, an exception is thrown.
+Although there are only 3 get methods, there are 7 different parameter types. This additional distinction is intended for you to use as you see fit, in case it is useful as metadata somewhere in your engine-specific code.
+
If you need to store different types than those already allowed, add the new type to the list of type parameters for the \verb+_value+ field and add another enumeration value to \verb+ParamType+. You should make the new type \emph{output streamable}--that is, allow it to be used like \verb+std::cout << value+. This allows the value to be output directly to an output stream regardless of its type.
Note: When storing 8 or 16-bit unsigned values in the \verb+_value+ field, cast them to an \verb+uint32+ when doing the assignment, or you will not be able to extract the value using \verb+getUnsigned+. This is a limitation caused by the automatic type conversion algorithm used by C++.
@@ -116,7 +119,7 @@
For the purpose of this example, our instruction set will use little-endian values, and uses byte elements for the stack (so \verb+POP+ changes the stack pointer by 1 and \verb+POP2+ changes it by 2).
\subsubsection{Opcode recognition}
-The first thing to do in the \verb+doDisassemble+ method is to read past any header which may be present in your script file. In this case, we will assume there aren't any.
+The first thing to do in the \verb+doDisassemble+ method is to read past any header which may be present in your script file. We will assume that our bytecode files do not have a header.
You must place your opcodes between two macros, \verb+START_OPCODES+ and \verb+END_OPCODES+. These two macros define the looping required to read one byte at a time.
@@ -127,7 +130,7 @@
\end{lstlisting}
\end{C++}
-To define an opcode, use the \verb+OPCODE+ macro. This macro takes 5 parameters: the opcode value, the name of the instruction, the type of instruction, the net effect on the stack, and a string describing the parameters that are part of the instruction. We'll start by implementing the \verb+POP+ and \verb+POP2+ opcodes:
+To define an opcode, use the \verb+OPCODE+ macro. This macro takes 5 parameters: the opcode value, the name of the instruction, the type of instruction, the net effect on the stack, and a string describing the parameters that are part of the instruction. We will start by implementing the \verb+POP+ and \verb+POP2+ opcodes:
\begin{C++}
\begin{lstlisting}
@@ -163,7 +166,7 @@
\label{tbl:paramtypes}
\end{table}
-To help you remember these meanings, little-endian values are encoded using lower case ("small letters", i.e. little), while big-endian values are encoded using upper case ("big" letters). The exception here is a single byte, since endianness has no effect for individual bytes. Here, the mnemonic is that an unsigned byte ("B") has a larger maximum value. For the other letters, "s" was used because it's the first letter in "short", which is usually a 16-bit signed value in C. Similarly, "i" is short for "int". "w" and "d" come from the terms "word" and "dword", which are terms for 16-bit and 32-bit unsigned types on an x86 platform.
+To help you remember these meanings, little-endian values are encoded using lower case ("small letters", i.e. little), while big-endian values are encoded using upper case ("big" letters). The exception here is a single byte, since endianness has no effect for individual bytes. Here, the mnemonic is that an unsigned byte ("B") has a larger maximum value. For the other letters, "s" was used because it is the first letter in "short", which is usually a 16-bit signed value in C. Similarly, "i" is short for "int". "w" and "d" come from the terms "word" and "dword", which are terms for 16-bit and 32-bit unsigned types on an x86 platform.
Note that strings are not supported by default. To add reading of a string type, you can override the \verb+readParameter+ function to add your own types:
@@ -208,7 +211,7 @@
\end{C++}
\subsubsection{Multi-byte opcodes}
-There's only one opcode left to add, \verb+HALT+. This one is a bit trickier, because it uses multiple bytes for the opcode - and the \verb+OPCODE+ macro only works for one byte at a time.
+There is only one opcode left to add, \verb+HALT+. This one is a bit trickier, because it uses multiple bytes for the opcode - and the \verb+OPCODE+ macro only works for one byte at a time.
To solve this, you can define \emph{subopcodes}. By defining 0xFF as the start of a multi-byte opcode, we can then specify 0x00 as representing a \verb+HALT+ instruction when it follows 0xFF.
@@ -251,7 +254,7 @@
For details, see Section~\vref{sec:codegen}.
\subsubsection{Advanced opcode handling}
-If you have one or two opcodes that don't quite fit into the framework provided, you can define your own specialized handling for these opcodes.
+If you have one or two opcodes that do not quite fit into the framework provided, you can define your own specialized handling for these opcodes.
Instead of using the \verb+OPCODE+ macro, put your code between \verb+OPCODE_BASE+ and \verb+OPCODE_END+. For example, if your opcode has the value 0x40, you would use this:
Modified: tools/branches/gsoc2010-decompiler/decompiler/doc/doc.tex
===================================================================
--- tools/branches/gsoc2010-decompiler/decompiler/doc/doc.tex 2010-08-09 18:42:07 UTC (rev 51942)
+++ tools/branches/gsoc2010-decompiler/decompiler/doc/doc.tex 2010-08-09 19:29:15 UTC (rev 51943)
@@ -14,6 +14,6 @@
\input{cfg}
\input{codegen}
\input{restrictions}
-\newpage\listoffixmes
+%\newpage\listoffixmes
\end{document}
Modified: tools/branches/gsoc2010-decompiler/decompiler/doc/engine.tex
===================================================================
--- tools/branches/gsoc2010-decompiler/decompiler/doc/engine.tex 2010-08-09 18:42:07 UTC (rev 51942)
+++ tools/branches/gsoc2010-decompiler/decompiler/doc/engine.tex 2010-08-09 19:29:15 UTC (rev 51943)
@@ -6,28 +6,28 @@
If you need to store metadata about the script, you can add the necessary fields to your engine class and store the information there, as the same instance will be used throughout the decompilation process.
\subsection{Adding a new engine}
-In order to make the decompiler use the code you write to decompile code for some engine, it must be registered in the program. To do so, use the \verb+ENGINE+ macro defined in \verb+decompiler.cpp+, and add your own use of the macro near the existing registrations.
+In order to make the decompiler use the code you write to decompile code for some engine, it must be registered in the program. To do so, include the header file for your engine in \verb+decompiler.cpp+, and use the \verb+ENGINE+ macro defined there to register your engine with the program.
-This macro takes 3 parameters: the engine ID, a description of the engine, and the name of the \verb+Engine+ subclass used to create the classes used for the various steps of the process. The ID is entered by the user to signify the engine where the script originates from, and the description is a descriptive text which will be shown when the user requests a list of the supported engines.
+This macro takes 3 parameters: the engine ID, a description of the engine, and the name of the \verb+Engine+ subclass used to create the classes used for the various steps of the process. The ID is entered by the user to signify the engine where the script originates from, and the description is a descriptive text which will be shown when the user requests a list of the supported engines. In general, you should place the files for your engine in a folder with the same name as the engine ID you use.
-The methods you need to implement are:
+The methods you need to implement in your \verb+Engine+ subclass are:
\begin{itemize}
-\item \verb+getDisassembler+, which takes a reference to the instruction vector to use for storage and creates a disassembler object and returns it.
-\item \verb+getCodeGenerator+, which takes a reference to the \verb+std::ostream+ to output the code to and creates a code generator object and returns it.
-\item \verb+getDestAddress+, which takes a const iterator to a jump instruction as a parameter and returns the address the instruction will jump to if the jump is taken. Unless you do differently in your engine-specific code, this function will only receive jumps as input, so if you can take a shortcut based on that, you're allowed to.
+\item \verb+getDisassembler+, which takes a reference to the instruction vector to use for storage and creates a disassembler object and returns it. For more on disassemblers, see Section~\vref{sec:disassembler}.
+\item \verb+getCodeGenerator+, which takes a reference to the \verb+std::ostream+ to output the code to and creates a code generator object and returns it. For more on code generators, see Section~\vref{sec:codegen}.
+\item \verb+getDestAddress+, which takes a const iterator to a jump instruction as a parameter and returns the address the instruction will jump to if the jump is taken. Unless you do differently in your engine-specific code, this function will only receive jumps as input, so if you can take a shortcut based on that, you are allowed to do that.
\end{itemize}
Additional methods you can override are:
\begin{itemize}
\item \verb+supportsCodeFlow+ and \verb+supportsCodeGen+, which can be used to stop the decompiler from going any further after disassembly or code flow analysis, respectively. This is helpful when working on a brand new engine, so you can take one step at a time without having to remember to use the right command-line switch. If you do not override these methods, the decompiler will go through all steps.
-\item \verb+detectMoreFuncs+ allows you to tell the control flow analysis to automatically detect functions based on reachability. See~\vref{sec:autofunc} for details. By default, this is turned off; engines must opt-in to this feature.
-\item \verb+postCFG+, which is a post-processing step called after control flow analysis. If you override \verb+detectMoreFuncs+ to return true, you must also override this function to process any newly found functions. A default implementation which does nothing is already provided in case you don't need to do any post-processing.
+\item \verb+detectMoreFuncs+ allows you to tell the control flow analysis to automatically detect functions based on reachability. See Section~\vref{sec:autofunc} for details. By default, this is turned off; engines must opt-in to this feature.
+\item \verb+postCFG+, which is a post-processing step called after control flow analysis. If you override \verb+detectMoreFuncs+ to return true, you must also override this function to process any newly found functions. A default implementation which does nothing is already provided in case you do not need to do any post-processing.
\end{itemize}
-It's important to realize that you don't necessarily need to implement a completely new code generator and disassembler for every engine; for variations on the same engine, you can reuse the existing classes and simply send in any extra information required. In particular, code generators are likely to be reusable without change for different versions of the same engine - e.g., the Kyra2 code generator will likely work for all Kyra games.
+It is important to realize that you do not necessarily need to implement a completely new code generator and disassembler for every engine; for variations on the same engine, you can reuse the existing classes and simply send in any extra information required. In particular, code generators are likely to be reusable without change for different versions of the same engine - e.g., the Kyra2 code generator will likely work for all Kyra games.
\subsection{Game information}
-For some engines, it's not enough to know the engine; some instructions may differ in behavior between talkie or non-talkie versions, while others may require different behavior for different platforms.
+For some engines, it may not be enough to know the engine; some instructions may differ in behavior between different games or variants of a game, for example between talkie or non-talkie versions, or between versions for different platforms.
The \verb+Engine+ class contains a field \verb+_isTalkie+ which is set to true if the user passed in the \verb+-t+ switch on the command line. You can check this flag in your engine-specific code if necessary.
@@ -36,7 +36,7 @@
Note that, at the time of writing, there is no field containing platform information; this must be handled by implementing another engine which passes in relevant information to engine-specific classes.
\subsection{Functions}
-Some engines allow multiple functions in a single script file. Each function must be analyzed separately, but in order to do that, it is of course necessary to know where the functions start and end, and when it's time to actually generate some code, you'll want to know a bit about the function as well.
+Some engines allow multiple functions in a single script file. Each function must be analyzed separately, but in order to do that, it is of course necessary to know where the functions start and end, and when it is time to actually generate some code, you will want to know a bit about the function as well.
This information is stored in the engine, as a \verb+std::map+ of \verb+Function+s, in the field \verb+ _functions+.
@@ -61,11 +61,11 @@
\item \verb+_endIt+ is a const iterator pointing to the instruction immediately after the last instruction, similar to \verb+end()+ on STL collections.
\item \verb+_name+ is the name of the functions.
\item \verb+_v+ is the GraphVertex containing the entry point. This will be automatically assigned in the control flow analysis.
-\item \verb+_args+ is the number of arguments for the function. This is present as a convenience; you generally won't know the names of the arguments in the function, so you can store the number of them here and use this during code generation to generate a method signature containing some default parameter names.
+\item \verb+_args+ is the number of arguments for the function. This is present as a convenience; usually, you will not know the names of the arguments in the function, so you can store the number of them here and use this during code generation to generate a method signature containing some default parameter names.
\item \verb+_retVal+ should be true if your method returns a value, and false if it does not. Again, this is for your own convenience, to make it easier to handle calls.
-\item \verb+_metadata+ contains metadata about the function, so you know how to handle the arguments when the function is being called. It's up to you how you want to use this.
+\item \verb+_metadata+ contains metadata about the function, so you know how to handle the arguments when the function is being called. It is up to you how you want to use this.
\end{itemize}
When you add a function to the map, you must use the address of the first instruction as the key.
-Sometimes, you don't know where all of the functions begin or end. In that case, the control flow analysis can analyze the code for you and automatically detect missing functions or unknown end points. See~\vref{sec:autofunc} for details.
+Sometimes, you do not know where all of the functions begin or end. In that case, the control flow analysis can analyze the code for you and automatically detect missing functions or unknown end points. See Section~\vref{sec:autofunc} for details.
Modified: tools/branches/gsoc2010-decompiler/decompiler/doc/preamble.tex
===================================================================
--- tools/branches/gsoc2010-decompiler/decompiler/doc/preamble.tex 2010-08-09 18:42:07 UTC (rev 51942)
+++ tools/branches/gsoc2010-decompiler/decompiler/doc/preamble.tex 2010-08-09 19:29:15 UTC (rev 51943)
@@ -37,10 +37,9 @@
\usepackage[chatter]{rotating}
\usepackage[usenames]{color}
\usepackage{amsmath, amssymb}
-\usepackage{bbold}
-%\usepackage{ebnf} % For EBNF notation
\usepackage{float} % For better float-support
\usepackage{varioref} % Better citation (includes page)
+\usepackage{hyperref}
%\labelformat{equation}{(#1)} % Correct equation references !!DOESN'T WORK ATM!!
\usepackage{verbatim}
\usepackage{url}
@@ -52,14 +51,6 @@
%% Now actually use the newly defined style.
\urlstyle{leo}
-\usepackage{array} % More flexible table handling
-\newcolumntype{C}{>{\centering\arraybackslash}p{0.75cm}}
-\usepackage{subfig} % Subfloats
-
-%%Algorithms
-% Algorithm2e Write algorithms
-% Seach for algorithm2e for usage
-\usepackage[ruled,vlined,linesnumbered]{algorithm2e}
% Listings, for writing code
\usepackage{listings}
@@ -131,5 +122,4 @@
\newcommand\T{\rule{0pt}{2.6ex}}
\newcommand\B{\rule[-1.4ex]{0pt}{0pt}}
-\usepackage{multirow}
%\setlength{\parindent}{0mm}
Modified: tools/branches/gsoc2010-decompiler/decompiler/doc/restrictions.tex
===================================================================
--- tools/branches/gsoc2010-decompiler/decompiler/doc/restrictions.tex 2010-08-09 18:42:07 UTC (rev 51942)
+++ tools/branches/gsoc2010-decompiler/decompiler/doc/restrictions.tex 2010-08-09 19:29:15 UTC (rev 51943)
@@ -5,6 +5,6 @@
roomObj scripts have a header specifying offsets for various verbs. This is currently ignored, and the script is treated as a single piece of code.
\subsection{KYRA2}
-I have only tested the decompiler with English scripts (.EMC files) from the Kyra 2 demo. It is possible that some scripts from the full version misbehave somehow; as I do not own the game, I cannot be sure of this.
+The decompiler has only been tested with English scripts (.EMC files) from the Kyra 2 demo. It is possible that some scripts from the full version misbehave somehow; as I do not own the game, I cannot be sure of this.
Only "regular" scripts are supported; animation scripts are not supported. It looks like the file names of animation scripts all start with either \_Z or \_IDL, but this is not necessarily an exhaustive list.
This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site.
More information about the Scummvm-git-logs
mailing list