|[ < ]||[ > ]||[ << ]||[ Up ]||[ >> ]||[Top]||[Contents]||[Index]||[ ? ]||[ Search: ]|
This section is intended to explain the general CS directory structure. Crystal Space consists of the following directories:
The main directory for Crystal Space. You can choose any path for it, as long as it is supported by your operating system. If you choose to build the project within this directory, then this is where the built applications and plugin modules are deposited. The file ‘vfs.cfg’ also resides in this directory.
This directory is used by the build process if you build the project using “make” or “jam” within the source tree. It is also possible—indeed recommended—to build the project in some other location. This directory will contain all object files, static link libraries, and other generated files needed for building the project.
Contains the source code for applications shipped with Crystal Space. See section Applications Overview.
Applications for testing specific features of the project reside here.
Various tutorial applications can be found here.
Miscellaneous scripts used by the project maintainers.
Location of data files and maps distributed with Crystal Space.
Configuration (‘.cfg’) files for applications in Crystal Space.
Configuration (‘.cfg’) files for plugins in Crystal Space.
Description of the render layers of the render managers that are available within Crystal Space.
This important directory contains shaders and other related information which is used by the Crystal Space engine.
This directory contains the shaders that are defined using the shader weaver, by combining shader snippets.
This directory contains the snippets that are combined by the shader weaver, in order to create more complex shaders.
This directory contains the shaders that do not use the shader weaver.
The root of the Crystal Space documentation hierarchy. There are several subdirectories.
Texinfo is the master format for all Crystal Space documentation. This directory and its subdirectories contain all of the Texinfo source and images which comprise the Crystal Space manual. Most users need not concern themselves with this directory since the Texinfo documentation is automatically converted to HTML which is more accessible to the general user. Documentation writers and maintainers, however, may be interested in this directory.
This directory contains the HTML conversion of the Texinfo Crystal Space manual. Most users will want to browse the file ‘CS/docs/html/manual/index.html’.
This directory contains the Crystal Space SDK's public API reference manual. Most users will want to browse the file ‘CS/docs/html/api/index.html’.
This directory contains support scripts and templates for automatically generating documentation.
These are the public Crystal Space header files. These headers will be installed as part of the SDK when you invoke ‘make install’ or ‘jam install’.
Here is where the utility-like modules reside which you can link into your applications or plugins. There are relatively few such libraries since most of Crystal Space's functionality is provided in the form of plugin modules.
The geometry module. Various geometry related functions and classes can be found here: matrices, vectors, transforms, clipper, planes, etc.
The graphics module. Here you will find bumpmapping, mipmapping, quantizers, and routines to support loading an image file (through the various image loading plug-ins).
This module contains high-level utility functions which rely upon the other modules, and possibly upon plugin modules. It is possible to write programs without utilizing this module, but it does provide several convenience classes for common cases and is, therefore, quite valuable.
This module contains various low-level utilities. The utilities include an archiver, configuration manager, virtual clock, scheduler, strings, hash tables, SCF (see section Shared Class Facility (SCF)), MD5 algorithm, command-line parser, event structures, and many others.
Generic implementations of possibly platform-specific functionality.
A collection of convenience modules which eliminate much of the drudgery associated with implementing SCF interfaces in certain types of common plugin modules. For example, the ‘csGraphics2D’ class in ‘csplugincommon/canvas’ implements the ‘iGraphics2D’ interface and provides much of the functionality common to most canvases. Likewise, the ‘csGraphics3D’ class in ‘csplugincommon/render3d’ implements the ‘iGraphics3D’ interface and provides much functionality common to renderers. You are not required to utilize these implementations when authoring your own plugins, but they are available for your convenience and may prove to be handy time-savers.
Common canvas functionality.
Common Direct-X functionality.
Common image loader functionality.
Common MacOS/X functionality.
Common OpenGL functionality.
Common particle system functionality.
Common renderer functionality.
Common render-loop functionality.
Common shader functionality.
Common sound loader functionality.
Common sound renderer functionality.
Common Microsoft Windows functionality.
This directory contains support facilities for the configuration and build systems.
Handy Autoconf utility macros which may be of use to external projects based upon Crystal space.
Handy Jam rules which may be of use to external projects based upon Crystal Space.
Component for automatic generation of Visual C++ project files based upon information gleaned from Jamfiles project-wide.
Project files for Microsoft Windows using MSVC 6.0 and 7.0.
Dynamically loaded plug-ins. Communication with these modules is performed strictly via SCF interfaces. See section Shared Class Facility (SCF).
Crystal Space debugger.
Collision detection plugins.
This is the Opcode collision detection plugin which is based upon the Opcode library.
Various console plugins for input/output. A console is often overlaid atop the 3D display.
The Crystal Script plugins. Crystal Script plugins allow programmers to interact with the Crystal Space engine via a scripting language.
A plugin which parses structured map files and imports the map into the 3D engine. The standard map file format is XML, however the parser can parse any structured document which can be represented by an ‘iDocument’ interface.
Crystal Space format loader services.
Visibility culling plug-ins.
Dynavis visibility culling system.
Frustvis visibility culling system (default culler if no other is selected).
Hardware device plugins.
The 3D engine which drives Crystal Space.
The 3D engine plugin.
Virtual filesystem, VFS. See section Virtual File System (VFS).
Collection of font servers.
Standard (bitmapped) Crystal Space font server.
FreeType (version 2) font server.
Font server multiplexer.
Various mesh object implementations (see section Mesh Object Plug-In System). For every mesh object there is typically one implementation in ‘object/’ and one or more loader/saver plugins in ‘persist/’. ‘persist/standard/’ is the loader in Crystal Space format.
Plug-ins relating to the physics of motion.
This is the sequence manager which is useful for managing timed sequences of events such as for demos.
All sound-related plugins (see section Sound System).
Standard reporter listener.
All rendering- and graphics-related plugins.
The 2D driver component which manages creation of the Crystal Space window used for rendering and also supports limited 2D drawing capabilities (including 2D pixmaps).
Common code for 2D drivers.
MacOS/X OpenGL graphics driver.
A do-nothing 2D canvas.
OpenGL 2D driver for Windows.
OpenGL 2D driver for X11.
X-extension driver (X11).
X-window X11 driver.
Loaders for various graphics file formats.
The 3D rasterizer component is required by the 3D engine but may also be used in a standalone environment. It requires a 2D canvas.
Common code for 3D rasterizers.
A do-nothing renderer (required when working only with 2D graphics).
This directory contains scripts that are used for several different purposes: exporting data from 3D editors, creating skeleton of projects based on Crystal Space, packaging Crystal Space, or using the script bindings of the API.
Export script for the “Blender” 3D modeling editor.
Generation of the ‘cs-config’ configuration tool that can be used to detect the presence of Crystal Space on a given system.
Generation of the OpenGL extensions.
Generation of the skeleton of a project based on Crystal Space and using the “jam” build system.
Example of an application written using the Java bindings (although these are currently no more supported...).
Generation of the skeleton of a project based on Crystal Space and using the “make” build system.
Export script for the “3ds Max” 3D modeling editor.
Export script for the “Maya” 3D modeling editor.
Generation of packages for the distribution of Crystal Space.
Example of an application written using the Perl bindings (although these are currently no more supported...).
Tools for the generation of the Python bindings, along with application examples using those bindings.
XML schema of the Crystal Space map file format. This is unfortunately mostly obsolete...
|[ < ]||[ > ]||[ << ]||[ Up ]||[ >> ]||[Top]||[Contents]||[Index]||[ ? ]|
This document was generated using texi2html 1.76.