alt="Castle Game Engine icon"
Table of contents:
@section(1 SectionAuthor Author)
This is a reference for @italic(Castle Game Engine),
see [http://castle-engine.sourceforge.net/]. Developed by
All comments, bug reports, questions, patches and everything are welcome.
@section(1 SectionDocumentation About this documentation)
This reference was generated by PasDoc (see [http://pasdoc.sf.net/]).
The online version of it is available on
Besides this reference, there is also a tutorial and other
useful engine documentation on
@section(1 SectionExamples Examples)
As a programmer, you probably want to jump straight into the action,
so take a look at the examples in @code(examples/) subdirectory
of the engine. You can compile them from Lazarus (install
castle_base and castle_components packages first, and then just open examples
.lpi files), or by @code(make examples).
There are a lot of examples, for 3D game examples look e.g. at
@section(1 SectionCompiling Compiling)
@section(2 SectionCompilingFPC Compiling these units with FPC)
Latest stable version of FPC is always advised.
for more comments about FPC versions allowed.
Compile programs using the @code(xxx_compile.sh) script
prepared in directory of each program.
In summary, this script just calls fpc with proper command-line options.
Or open the @code(xxx.lpi) file in Lazarus, and compile from Lazarus.
To use the engine in your own programs, there are a couple of options:
If you use Lazarus, the most comfortable way to use engine units
is to use Lazarus castle_base and
castle_components packages. Just install them in Lazarus.
See @code(castle_game_engine/packages/README.txt) in sources for more information.)
If you don't use Lazarus, you should compile engine units using
@code(castle_game_engine/Makefile) file. GNU make is required
(under Linux this is the default `make',
under Windows you have this already bundled with FPC
(you can also get this from Cygwin or MinGW),
under FreeBSD this is called `gmake').
Currently, @code(make) simply uses @code(castle_game_engine/fpmake.pp).
If you're familiar with FPMake (see [http://wiki.lazarus.freepascal.org/FPMake]),
you may as well just compile @code(fpmake.pp) and run it yourself.)
You can also recompile the engine along with your own programs
if you use our build tool,
If you need more control over compilation process then
you can also directly use castle-fpc.cfg file. This is my configuration
file for FPC. It's used by and by all @code(xxx_compile.sh)
scripts, @code(fpmake.pp) etc. All my programs and units must be compiled with
FPC using this configuration.)
@section(1 SectionRequirements Requirements)
@section(2 SectionLibraries Libraries)
@item(@code(libpng) and @code(zlib).
@link(CastleImages) unit requires libpng (libpng.so under UNIXes,
libpng12.dll under Windows) installed if you want to load/save
PNG images. Otherwise you will get ELibPngNotAvailable exception
when trying to load/save files in PNG format.
Note that libpng depends on zlib.
CastleZLib unit (required by CastleZStream unit and used by
X3DNodes) requires zlib installed. This is used to open and save
To play 3D sound. If OpenAL is not installed, everything will stil
run just fine (we will not raise any exception), you will just not get
To load sounds in OggVorbis format.)
@item(@code(GtkGLExt) (on Unix).
Used by CastleWindow on Unix to create a window with OpenGL context.
There is an alternative CastleWindow backend that doesn't use GtkGLExt
(uses directly Xlib), although it doesn't show native manu or dialog boxes.)
Used by TTextureFont to read font files.)
For Windows, you can get the required DLLs easily
Be sure to get DLLs matching your architecture ---
32-bit (i386-win32) libraries only work with 32-bit binaries,
64-bit (x86_64-win64) libraries only work with 64-bit binaries.
On Mac OS X there are some additional requirements.
@section(1 SectionUnitsMap Units map)
Here's a short map of the important units documented here.
Units are divided into a couple of groups.
Group's name (like "@code(base)") is also the name of
subdirectory where unit's source code is placed.
The "@italic(Uses:)" notes below say which
units are allowed to be used by units in specific group.
Basic utilities and classes.
@italic(Uses:) Nothing. These units do not depend on units
from other groups.)
3D sound support based on OpenAL, processing of sound files.
Image, textures, videos processing. Not OpenGL-specific.
Font support, including some embedded fonts in CastleOutlineFont_* and CastleBitmapFont_* units.
Parsing and executing expressions and programs in CastleScript language
@italic(Uses:) @code(base), @code(images),
X3D parts also use @code(x3d).)
2D user interface of the engine.
First of all, unit CastleUIControls with basic control class
TUIControl and basic container interface IUIContainer.
@item("Containers" are classes that implement IUIContainer interface.
We have two containers right now:
@item A window, by our TCastleWindow class (see @code(window) directory).
@item(A Lazarus component, by our TCastleControl class
(see @code(components) directory).
This descends from the base TOpenGLControl provided by Lazarus,
inheriting it's functionality.)
Container is tied to a particular windowing library, like GTK or WinAPI
or something higher-level like Lazarus LCL.
Container is responsible for initializing and managing OpenGL context.
Container handles a list of controls, that is a list of
instances of the TUIControl class. For our two current containers
this list is TCastleWindow.Controls and TCastleControl.Controls.
Container passes to them key events, mouse events and much more.)
@item("Controls" are classes that descend from TUIControl class.
They may be tied to a particular rendering library,
in practice --- all current controls use OpenGL rendering.
The controls are not concerned with how you initialized the OpenGL
context, so all controls are useful with all containers.
For example you can use the same TCastleOnScreenMenu class
inside TCastleWindow, or inside Lazarus TCastleControl component, etc.)
We have many OpenGL controls (like TCastleOnScreenMenu and things
like buttons inside CastleControls) in @code(ui/opengl/) subdirectory.
We also have camera classes (CastleCameras unit with TCamera descendants),
they are used by scene manager.
@italic(Uses:) @code(base), @code(images), @code(3d).)
3D graphics stuff, not X3D-specific.
Note: CastleVectors unit is considered by me as something more general and
useful --- so it's in @code(base) group, not here.
@italic(Uses:) @code(base), @code(images).
@italic(Subdirectory @code(opengl)) contains OpenGL-specific stuff,
that uses also @code(opengl) units.)
@italic(Uses:) @code(base), @code(images), @code(3d), @code(fonts).)
CastleWindow unit, to easily create a window with OpenGL context.
This directory also contains various user-interface stuff usable only
together with CastleWindow, like progress bar display in OpenGL window
(CastleWindowProgress), messages (CastleMessages).
@italic(Uses:) potentially everything. For comfort, TCastleWindow
has a ready link to SceneManager, so it depends on TCastleSceneManager
and other 3D classes.
What is important is that no other engine units may depend on
CastleWindow units. So every OpenGL code outside @code(window)
directory is usable with OpenGL context initialized in any way,
like with Lazarus OpenGL control.)
VRML/X3D rendering and processing. This is the core of our engine rendering,
classes to handle and render 3D stuff are here.
X3D file reading, writing and processing (X3DLexer, X3DFields,
X3DNodes), building and using octree based on X3D model (CastleShapeOctree, CastleTriangleOctree),
ray-tracer based on X3D model (CastleRayTracer),
loading animations (CastlePrecalculatedAnimationCore),
load 3D model formats as X3D (X3DLoad).
CastleScene unit provides the complete class
for dealing with 3D models and displaying them in OpenGL.
CastlePrecalculatedAnimation also provides a special way
of animating models by interpolating between a set of 3D files.
@italic(Uses:) @code(base), @code(images), @code(3d), @code(fonts).
As an exception, CastleSceneManager also depends on CastlePlayer unit
from the @code(game) group.
@italic(Subdirectory @code(opengl)) contains OpenGL-specific stuff,
that uses also @code(opengl) units.
High level units implementing game mechanics for 3D games.
They build on top of other units.
@italic(Uses:) everything except @code(window), as this must
be suitable for both TCastleWindow and Lazarus TCastleControl.
@section(1 SectionMultipleContext Multiple OpenGL contexts)
If you use more than one OpenGL context (TCastleWindow or TCastleControl)
in a single program, they will share OpenGL resources (like textures).
This happens automatically for TCastleControl and TCastleWindow.
TODO: sharing contexts is not implemented yet for WinAPI backend of
CastleWindow (it is implemented OK for backends GLX, EGL, GTK).
Please report on forum if you need it.