Castle Game Engine: Introduction

# Introduction Table of contents: Author About this documentation Examples Compiling Compiling these units with FPC Requirements Libraries Units map Multiple OpenGL contexts ## Author 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]. ## Examples 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 `make examples`. There are a lot of examples, for 3D game examples look e.g. at examples/3d_rendering_processing/fps_game.lpr examples/lazarus/model_3d_viewer/model_3d_viewer.lpr ## Compiling ### 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'). Currently, `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. You can also recompile the engine along with your own programs if you use our build tool, see [https://sourceforge.net/p/castle-engine/wiki/Build%20tool/]. 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 `xxx_compile.sh` scripts, `fpmake.pp` etc. All my programs and units must be compiled with FPC using this configuration. ## Requirements ### Libraries `libpng` and `zlib`. 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 gzip-compressed files. `OpenAL`. 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 any sound. `vorbisfile`. To load sounds in OggVorbis format. `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. `FreeType`. Used by TTextureFont to read font files. For Windows, you can get the required DLLs easily from [http://svn.code.sf.net/p/castle-engine/code/trunk/external_libraries/]. 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. See [http://castle-engine.sourceforge.net/macosx_requirements.php] for details. ## 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 "`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. `base` Basic utilities and classes. Uses: Nothing. These units do not depend on units from other groups. `audio` 3D sound support based on OpenAL, processing of sound files. Uses: `base`. `images` Image, textures, videos processing. Not OpenGL-specific. Uses: `base`. `fonts` Font support, including some embedded fonts in CastleOutlineFont_* and CastleBitmapFont_* units. Not OpenGL-specific. Uses: `base`. `castlescript` Parsing and executing expressions and programs in CastleScript language [http://castle-engine.sourceforge.net/castle_script.php]. Uses: `base`, `images`, X3D parts also use `x3d`. `ui` 2D user interface of the engine. First of all, unit CastleUIControls with basic control class TUIControl and basic container interface IUIContainer. Concepts: "Containers" are classes that implement IUIContainer interface. We have two containers right now: A window, by our TCastleWindow class (see `window` directory). 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. Uses: `base`, `images`, `3d`. `3d` 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. Uses: `base`, `images`. Subdirectory `opengl` contains OpenGL-specific stuff, that uses also `opengl` units. `opengl` OpenGL utilities. Uses: `base`, `images`, `3d`, `fonts`. `window` 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. `x3d` 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. Uses: `base`, `images`, `3d`, `fonts`. As an exception, CastleSceneManager also depends on CastlePlayer unit from the `game` group. Subdirectory `opengl` contains OpenGL-specific stuff, that uses also `opengl` units. `game` 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 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. Generated by PasDoc 0.13.0 on 2015-06-15 04:43:19