The engine source code is compatible with Microsoft Visual Studio™ versions 2003, 2005 and 2008.

As an alternative compiler GCC version 3.4.5+ or 4.1.1+ might be used.

For the Windows platform we are using MinGW (http://www.mingw.org).

An alternative distribution of the MinGW system is located at: http://nuwen.net. This package contains a lot of precompiled libraries. It is missing the GNU Debugger (gdb), but the debugger can be easily downloaded from main MinGW repository.

Class Factory
Introduction

In order to instantiate objects using symbolic class names Linker is used.

The interface is simple :

iObject *Linker::InstantiateClassByName(const LString& ClassName);

This simple function is wrapped into the template function

template T* Linker::Instantiate(const LString& ClassName);

to allow constructions like this

iGUIView *button = linker->Instantiate(“GUIButton”);

If someone uses the original function InstClassByName() he has to downcast iObject to iGUIView manually :

iGUIView *button = dynamic_cast(linker->InstantiateClassByName(“GUIButton”));

Even more, the templated wrapper checks if ClassName is actually a descendant of T. (i.e., GUIButton is derived from iGUIView)
Meta-classes

Technically linker is a simple collection of so-called meta-classes. These metaclasses provide interface to instantiate objects and retrieve information about class members and methods.

MetaClass
{ // method information int GetMethodCount(); MetaMethod GetMethod(int i);

// field information int GetFieldCount(); MetaField GetField(int i); // object instantiation iObject *Instantiate(); // symbolic information string ClassName(); }

Metaclasses which correspond to “native” classes (declared in C++) are easily implemented using templates :

template class NativeMetaClass : public MetaClass
{ iObject *Instantiate() { return new T(); }
}

If the class is abstract then another form of metaclass is used

template class NativeAbstractMetaClass : public MetaClass
{ iObject *Instantiate() { FATAL_MESSAGE(“Unable to instantiate abstract class”); }
}

The instance of each metaclass is then registered in a collection (which we call Linker)

// registering classes :
linker->RegisterMetaclass(new NativeAbstractMetaClass);
linker->RegisterMetaclass(new NativeMetaClass);
// and so on

Serialization

Each class may have its own set of properties (speaking in C++ these are fields). These properties may be grouped into some logical subsets.

XML-like markup language provides a simple way to store groups of parameters.

Object()
{ Field1

Section1() { Subsection1() { Param1 } } }

Almost any complex OO-system requires some kind of object hierarchies. These are for example GUI systems or hierarchical SceneGraphs. Such hierarchies are easily mapped to the proposed ML syntax :

Object()
{ Field1 Field2

Object() { Object() { } } Object() { } }

Proposed ML SyntaxTree is directly mapped into C++ classes :

mlNode (interface), mlSection and mlParameter.

For the example above the tree is

mlSection(name = “object”,param = “classname”)
{ children: mlField(name = “Field1”,value = “SomeValue1”); mlField(name = “Field2”,value = “SomeValue2”); mlSection(name = “object”,param = “classname1”) { children: mlSection(name = “object”,param = “classname2”); }; mlSection(name = “object”,param = “classname3”);
}

Last Updated ( Friday, 21 September 2007 )

This software is copyrighted by the Sergey Kosarevsky, Viktor Latypov (the Authors) and other parties. The following terms apply to all files associated with the software unless explicitly disclaimed in individual files.

The Authors hereby grant permission to use, copy, modify, distribute, and license this software and its documentation for any purpose, provided that existing copyright notices are retained in all copies and that this notice is included verbatim in any distributions. No written agreement, license, or royalty fee is required for any of the authorized uses.

IN NO EVENT SHALL THE AUTHORS OR DISTRIBUTORS BE LIABLE TO ANY PARTY FOR DIRECT, INDIRECT, SPECIAL, INCIDENTAL, OR CONSEQUENTIAL DAMAGES ARISING OUT OF THE USE OF THIS SOFTWARE, ITS DOCUMENTATION, OR ANY DERIVATIVES THEREOF, EVEN IF THE AUTHORS HAVE BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.

THE AUTHORS AND DISTRIBUTORS SPECIFICALLY DISCLAIM ANY WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, AND NON-INFRINGEMENT. THIS SOFTWARE IS PROVIDED ON AN “AS IS” BASIS, AND THE AUTHOR AND DISTRIBUTORS HAVE NO OBLIGATION TO PROVIDE MAINTENANCE, SUPPORT, UPDATES, ENHANCEMENTS, OR MODIFICATIONS.

Last updated: February 28, 2007

1. What is a Linderdaum Engine?

The Linderdaum Engine is an open source purely object-oriented 3D gaming engine written in C++. It is designed to be not only the class library, but also an integrated out-of-the box solution for the development of interactive 3D games.

2. Is it a “Linderdaum Engine” or a “Linderdaum 3D Engine”?

Formerly it was named the “Linderdaum 3D Engine” accentuating that one is able to use it as a library for 3D games development. Now it is not just a rendering engine, but a set of different components (Audio, GUI, File system, Renderer, Resources manager, Scene graph, XLML, LinderScript) designed to interoperate together. They are called the “Linderdaum Engine”.

3. What are the system requirements of the engine?

You will need at least a GeForce6×00 class or higher video hardware with OpenGL 2.0 (2.1. is better) support to use the engine without limitations. There’s a special mode to run the Engine on older boards (like GeForce 2), but a lot of visual functionality will be disabled. The processor and memory requirements depend on what exactly you are going to do with the engine. For example, the Airplane demo runs at about 100FPS on my P4-2.0GHz with 512Mb of RAM and an AGP GeForce 6600 card. New Fighting Chess 0.5.70 demo with HDR enabled runs at about 20 FPS on that system. On an Intel Core Duo powered laptop with a Radeon X1600 on board it blows up to 50 FPS (widescreen 1280×768). Consider 1GHz CPU as a minimal requirement.

4. What operating systems and platforms are supported? Is the engine portable?

At present only the Win32 platform is supported. All the OS-dependant components of the engine are well localized and it should not be much pain in porting it to other OSes with OpenGL and OpenAL implementations. If necessary IJL library could be dropped easily.

5. In what projects Linderdaum Engine is used?

Fighting Chess is a game project targeted to show different features of the engine. It is available for downloading from here. Also, a couple of other projects are on the way and they will be announced as soon as they are ready. If you have a project to submit – don’t hesitate to contact me at support@linderdaum.comThis e-mail address is being protected from spam bots, you need JavaScript enabled to view it

6. What about a scripting system? Why did not you integrate Lua/Python/etc? How deeply is it integrated into the engine?

The scripting system of the Linderdaum Engine is called LinderScript and it has far more advanced features than usual standalone scripting systems could provide. Let’s start from the last question – the LinderScript Run-Time is the heart of the Linderdaum Engine and provides a metaclasses management facilities. It is inseparable from the engine and as a plus we have a bunch of features which any standalone scripting system is unable to provide: purely object-oriented solution where one can derive scripted classes from native C++ ones, there is no difference for the engine if some class contains scripted methods or not, in derived classes you can override some methods with LinderScript or leave them as inherited C++ methods at your own will. All this stuff is handled at the lowest level inside the engine so any engine’s class could be extended or rewritten using LinderScript. At the same time the performance of the LinderScript is comparable to Python.

7. What is the XLML?

XLML stands for eXtended Linderdaum Markup Language. It has much in common with XML and was implemented to provide a more “plain text editors”-friendly way to describe different resources – shaders, GUI, worlds, actors and even compiled LinderScript classes.

8. What is the LSS?

LSS is the Linderdaum Surface Shader and it is an abstraction of how a single geometry buffer data is rendered. More technically: it specifies a state of the underlying rendering API (OpenGL), like what textures are used, how they are combined (via the fixed pipeline or a shader program), if depth writes and color writes are enabled or disabled, blending, etc.

9. Why are there RAR archives as pack files? Why not ZIP?

RAR archives could be integrated seamlessly into the engine’s file system, because it is very simple to implement a memory-mapped archive files. The second benefit is that files are stored in a linear fashion inside the archive (in ZIP archive files are stored in a folders hierarchy).

10. What development tools do I need?

To compile the engine you will need Visual Studio .NET 2005 or GCC 3.4+ compiler. For different resources of the engine the following file formats are used: – Meshes: ASE, MD3, LCM (created by the engine itself after the caching procedure), STL (Stereolithography – could be exported from various CAD/CAM graphics systems) – Textures: BMP (uncompressed RGB only), TGA (uncompressed RGB only), HDR RGBE (RLE encoded) and JPEG as 2D textures or cube maps; DDS as 3D textures and cube maps – Shaders: SHADER, SP (both are ASCII text files) – Audio: WAV (uncompressed PCM only), OGG – User interface: GUI (ASCII text file)

No any particular tools are recommended to create these file types for the engine. For additional information about mesh files requirements see an appropriate tutorial.

11. What are you going to do better then the competitors? The goal is to implement an agile classes infrastructure capable of being tuned to handle many types of game genres. The flexible architecture of the engine serves this purpose. Most other engines are targeted to a small number of game types or even designed only to be used as a solution for some certain type of game (i.e. indoor FPS only. e.t.c.). The Linderdaum Engine is extendable enough to be useful in any type of an interactive 3D project.

API reference (Updated: September 28, 2007)