Dagor (langname) battle script
Supported by the rest of group sw406f12
Folder Structure
The repository is filled with now-defunct folders, but these are the interesting ones:
- Compiler/NeoCompiler
-
Contains the code for the Dagor compiler itself.
- engine/BattleEngine
-
Contains the run-time environment that is linked with a generated scenario from the compiler.
- report
-
Contains the LaTeX source files for the report.
Report
Prerequisites
preamble.tex contains all the package references you’ll need to succesfully compiler the report. On typical Windows (MikTex) setups, pdflatex will either ask you to install missing packages, or do so automatically. On .deb-based Linux distributions installing your local flavours "recommended" package should be sufficient (texlive-full on Debian, Ubuntu and derivatives).
Compiler
The langname compiler is implemented in C++ and considered complete for the language as defined. It is not completely bug-free, and several scenarios have been identified that should not be possible.
Building
Prerequisites
The Compiler uses boost’s regex library, and has been succesfully compiled down to version 1.46. Also, a reasonably new C++ compiler is recommended - any compiler with C++11 support since 2011 should be sufficient.
Compilation
In a sane Unix-style building environment (Linux/MSYS/Cygwin), cd into the Compiler/NeoCompiler directory and simply type make.
Running
The executable neocompiler (or neocompiler.exe on Windows) takes one or more langname files in pure text format as input and generates two files, generated.h and generated.cpp as its output. The program takes no further command line arguments.
Engine
The engine is built as a stand-alone library that can be linked with files generated by the compiler, or as an executable with a test scenario to run through the implementation.
Directories
The following directories are of interest in BattleEngine:
- Headers
-
Contains all header files for the core engine and frontends.
- Source
-
Contains all source code files for the core engine and frontends.
- User
-
Contains all headers (in User/Headers) and source code files (in User or User/Source) for the rule set specified for this version of Dagor.
- vs2010
-
Contains project and solution files for Visual Studio 2010 to build the engine.
Building
BattleEngine is supported through GNU make (the recommended method) or Visual Studio 2010. Any build environment should be possible (Eclipse has been done), but not supported.
Prerequisites
The base engine requires the template containers from boost. The experimental ncurses frontend furthermore requires ncurses and panel (typically bundled with ncurses) as well as the program_options library from boost.
The engin is written with several newer C++ features, so the newest version (at least with TR1) of C++ must be supported by the compiler. The engine has succesfully been built with gcc 4.6 and Microsoft’s C++ compiler included with Visual Studio 2010.
GNU make
To build the test scenario, simply run make without arguments. This is equivalent to make all. An executable, engine, will be created.
To build the standalone library, run make libbattle_engine.a. This implies make all. A file libbattle_engine.a will be created.
To build a scenario with files from the compiler, make sure that generated.h and generated.cpp are in the BattleEngine directory, then run make generated. A file, generated_game, will be created.
To build with the experimental ncurses frontend, use Makefile.curses instead. In all the previous examples, add the switch -f Makefile.curses.
Visual Studio 2010
Open the solution file and build. The solution may not be fully updated with the requisite soruce files, and you may have to simply add them to the solution from the directories.
By default, the vs2010 build only compiles the test engine. To build a generated scenario, replace the program.cpp source file with generated.cpp and main.cpp - make sure that the directory User is passed as an include dir to the compiler.
Running
None of the default executables take any arguments. The experimental ncurses frontend takes one argument, --framerate|-r, that denotes the desired number of screen updates each second.
The executable should be run in an environment where the output from stdout is visible (this is where messages are displayed).