Castle Game Engine
Classes, Interfaces, Objects and Records
Functions and Procedures
Table of contents:
- About this documentation
- Compiling these units with FPC
- Units map
- Multiple OpenGL contexts
This is a reference for Castle Game Engine, see [http://castle-engine.sourceforge.net/]. Developed by Michalis Kamburelis.
All comments, bug reports, questions, patches and everything are welcome. See [http://castle-engine.sourceforge.net/forum.php].
About this documentation
This reference was generated by PasDoc (see [http://pasdoc.sf.net/]). The online version of it is available on [http://castle-engine.sourceforge.net/reference.php].
Besides this reference, there is also a tutorial and other useful engine documentation on [http://castle-engine.sourceforge.net/engine.php#section_docs].
As a programmer, you probably want to jump straight into the action, so take a look at the examples in
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
There are a lot of examples, for 3D game examples look e.g. at
Compiling these units with FPC
Latest stable version of FPC is always advised. See [http://castle-engine.sourceforge.net/sources.php#section_fpc_ver] for more comments about FPC versions allowed.
Compile programs using the
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
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
castle_game_engine/packages/README.txt in sources for more information.
If you don't use Lazarus, you should compile engine units using
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').
make simply uses
castle_game_engine/fpmake.pp. If you're familiar with FPMake (see [http://wiki.lazarus.freepascal.org/FPMake]), you may as well just compile
fpmake.pp and run it yourself.
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
fpmake.pp etc. All my programs and units must be compiled with FPC using this configuration.
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 requires also zlib installed.
CastleZLib unit (required by CastleZStream unit and used by X3DNodes) requires zlib installed.
Some additional libraries are required for sound playing: OggVorbis stuff requires
vorbisfile library, OpenAL stuff naturally requires the OpenAL library. But all sound units are implemented in such way that even if the user doesn't have OpenAL/vorbisfile installed, programs using these units can still run fine (e.g. units will not raise any exception at unit initialization just because some library cannot be loaded; instead, appropriate boolean variable will be set to
False, and higher-level code can always check this).
For Windows, you can get some of the required DLLs easily from my site, [http://castle-engine.sourceforge.net/miscella/win32_dlls.zip]. Inside this archive there are also pointers where the "upstream" versions of these DLLs can be found on WWW.
On Mac OS X there are some additional requirements, since Mac OS X port is done much like any other Unix right now. So some units require some typical Unix libraries, like X11, GTK, GTKGlExt etc. See [http://castle-engine.sourceforge.net/macosx_requirements.php] for details.
Here's a short map of the important units documented here. Units are divided into a couple of groups. Group's name (like "
base") is also the name of subdirectory where unit's source code is placed. The "Uses:" notes below say which units are allowed to be used by units in specific group.
Basic utilities and classes.
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. Not OpenGL-specific.
Parsing and executing expressions and programs in CastleScript language [http://castle-engine.sourceforge.net/castle_script.php].
images, X3D parts also use
2D user interface of the engine.
First of all, unit CastleUIControls with basic control class TUIControl and basic container interface IUIContainer.
"Containers" are classes that implement IUIContainer interface. We have two containers right now:
A window, by our TCastleWindow class (see
A Lazarus component, by our TCastleControl class (see
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.
"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
ui/opengl/ subdirectory. We also have camera classes (CastleCameras unit with TCamera descendants), they are used by scene manager.
3D graphics stuff, not X3D-specific.
Note: CastleVectors unit is considered by me as something more general and useful — so it's in
base group, not here.
opengl contains OpenGL-specific stuff, that uses also
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).
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
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.
fonts. As an exception, CastleSceneManager also depends on CastlePlayer unit from the
opengl contains OpenGL-specific stuff, that uses also
High level units implementing game mechanics for 3D games. They build on top of other units.
Uses: everything except
window, as this must be suitable for both TCastleWindow and Lazarus TCastleControl.
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.
TODO: It is not implemented yet for TCastleWindow correctly yet. Be careful when you use more than one TCastleWindow with anything that uses cache (like textures inside TCastleScene). And please let us know on forum that you would like to see this fixed — it's simply a matter of time to finish it.
Generated by PasDoc 0.12.1 on 2013-01-26 17:37:20