view doc/Readme.txt @ 68:3a737e06dc50

Unittests: fixes and changes. Plus some doc changes.
author Diggory Hardy <diggory.hardy@gmail.com>
date Fri, 04 Jul 2008 18:49:16 +0100
parents c81342b54ef2
children 7fc0a8295c83
line wrap: on
line source

Copyright © 2007-2008 Diggory Hardy
License: GNU General Public License version 2 or later (see COPYING)

--- Some brief info ---

-- Platforms --
Linux: My development platform.
Windows: Poorly tested; dsss.conf needs some adjusting.

-- Dependencies --
Compile-time:
tango (at least r3697)
tango.scrapple (newer than current r58!)
derelict (at least r300)

Run-time:
Sdl
FreeType 2.3.5 (2.3.0 might work; older versions probably won't due to the binding not finding some (unneeded) symbols).
OpenGL 1.3 or higher


Build instructions:
dsss build
Then run the executable (from the current directory unless you install mde and/or use path options):
bin/mde or bin\mde

Testing:
dsss clean		(this is important if a previous build exists!)
dsss build -debug -debug=mdeUnitTest -C-unittest
bin/mde or bin\mde

Credits:
Me (Diggory Hardy) for just about everything in mde as of now.

Also thanks to:
Walter Bright and Digital Mars for D and DMD.
The tango team for Tango.
[derelict]
[sdl]
[opengl]
[freetype]



--- Goal ---

Mde is an attempt to build a game engine.

It is my second serious attempt at a game engine, following on from ge118 (http://diggory.hardy.googlepages.com/ge118). GE118 was written in C++, starting from some basic OpenGL and SDL tests and some of my early ideas about implementing an engine, and was heavily revised over time as I learned more about programming.

Mde − a Modular D (game-oriented) Engine − was started after I discovered D, and decided I wanted to make a clean start. The acronym starts "modular" because, from experience working on ge118, I had discovered that tightly-related module dependancies (and worse, circular dependancies) caused many difficulties while programming and prevented good designs of components; thus I wanted to separate each part of the project in order to enable better design and facilitate developing a replacement for a part of the program (in case someone would wish to do so).

It is not a library, since:
a)  IMO, different games using the same engine should, where possible (which should be the case with an open source engine) share the same executable and only use config/command line arguments to select the different game.
b)  The source is tied together so tightly and is only designed to be used in one way; thus there seems little point organising it as a library and example app.
Anyway, anyone wanting to use it as a library need only remove mde/mde.d and compile it.


--- FAQ (or just a few questions) ---

+ How many lines are there?
# wc -l $(find . -name "*.d")
As of last count, that was 3908.

+ Why is the code so DENSE?
That's just my coding style (I still mostly stick to the D style guide). I like code to look neat, but I don't like spacing it out a lot because then it takes more room (more scrolling) and IMO it becomes harder to visualise what goes on.

+ What toolkits/external libraries are used?
    tango
    tango.scrapple
    SDL (possibly will be replaced)

+ What libraries are planned to be used?
    OpenGL (of course...)
    OpenAL (most likely; however audio support is a LONG way off)
    Schooner: GLD & fonts (or conversions to tango) ?
    GLFW ?