4.1 Az  alapok

A Crystal Space olyan komponensek és könyvtárak gyűjteménye, maik hasznosak lehetnek számítógépes játékok írásakor. Bár a csomagok némelyike leginkább 3D játékok írására készült, nincs ilyesféle megkötése a csomag használatának. Az olyan komponesnsek, mint a hang driver remekül haszánlhatóak egy 2Djátékban is, és a virtuális fájlrendszer (lásd Virtual File System (VFS)) használható nemgrafikus alkalmazások esetén is. Ez rávilágít a Crystal Space egyik leglényegesebb tulajdonságára: a komponensek és könyvtárak többé-kevésbé függetlenek egymástól. Hanem akarsz “igazi” fizikát”, egyszerűen ne használd  a fizikai plugint. Ha nem akarsz szkriptelni, ne építsd be. Minden csomag úgy lett tervezve, hogy önmagában is működjön, vagy legalábbis a lehető legkevesebb egyéb csomag segítségével. Természetes létezik néhány függőség. Például a 3D engine igényli a 3D renderert, hogy képes legyen megjeleníteni a tartalmát, és egy renderer igényel egy vászont, maire rajzolhat. A másik oldalon remekül haszánlhatod a 3d renderert a 3d engine nélkül is.

A nagyfokú függetleség mellett jelen van a nagyfokú  integrálás is. A komponensek és könyvátrak úgy lettek megtervezve, hogy együtt haszánlhatóak legyenek és rugalmas integrációs sémát nyújtásanak.

Ha érdekel a programfejlesztés a Crystal Space segítségével, akkor fontos, hogy megértsd, a Crystal Space nem egy monolitikus könyvtár, hanem több könyvtárból és plugin modulból áll. Ez a kézikönyv a modul kifejezést használa a könyvtárakra és a pluginokra is, mivel a kettő közti különbésgek nem fontosak.

Aplugin modul hasonlít a könyvtárra, de van néhány előnye a könyvtárral szemben. Minden plugin elérhető ugyanazon a módon. Tiszta interéfszük van (pure interface) , és képesek ezt az interfészt akkor is nyújtan, ha egy dinamikusan etöltehtő könyvtárban helyezkednek el. Szóval jobb megoldást nyújtanak akkor, ha a sebesség nem diktál, mint például a matematikai könyvtárban (a plugin függvények virtuális metódusokat használnak). A fő különbség  a könyvtár interfészek és pluginok között az, hogy a könyvátrak haszánlhatájk az SCF-et (lásd Shared Class Facility (SCF)) és a C++ osztályokat, a pluginok  pedig csak az SCF-et.

• Mi az SCF?

A fő SCF objektum az interfész. Az interfész megoldást nyújt arra, hogy szorosan elválasszuk az objektumok nyilvános metódusait azok megvalósításától. Te csak egy pointert veszel egy olyan absztrakt osztályra, aminek csak virtuális metódusai vannak, ezt hívják interfésznek, és így a progrmaod semit sem tud az pointer mögött lévő tulajdonképpeni objektumról.  Te, mint Crystal Space felhasználó függvényeket hívsz majd, hogy mgalkosd az objektumokat, de azok csak egy interfszzel térnek vissza. Ezután azinterfészt úgy használod, mint bármilyen más C++ objektumot. Hamárnincs szükséged rá, ne töröld azt (‘delete’), csak hívd meg a Decref(9 függvényét. Ha kell egy pointer rá valahol, hívd meg az IncRef() függvényt rá,és a DecRef(9 –et, ha már nincsen szükséged rá többé.

A Crystal Space 0.95-ös verziójától kezdve vannak gyors pointereink is. A gyors pointer egy csRef osztály példánya. az osztály az Incref() és a ecRef() tafüggévnyeket nyújtja neled, lásd a Correctly Using Smart Pointers szekciót)- Nagyon fontos mostmár használni a gyors pointereket. Könnyebbé teszik az életet és később kötelező a használatuk ( értsd: többé már nem opcionális).

Mint felhasználó, neked csak azt a fejállományt kll beépítened, ami az interfészt definiálja, de az megvalósítást már nem. E nyilvánvaló tény ellenére, hogy ezzel a nagyon tiszta kódstruktúrát valósíthatsz meg, van egy másik előnye is, méghozza áz, hogy az interfészhez a megfelelő implementációt futási időben is hozzálinkelheted, de erről majd később.

• Milyen jellemzőkkel bír egy könyvtár?

Egy könyvtár egy ugyanolyan C++ könyvtár, mint amilyeneket már ismersz. A könyvtár opcionálisan nyújthat SCF interfészeket. Ebben az esetben a könyvtár csak egy út arra, hogy viágos kódot alkoss. De mint a fő interfészük, a könyvtárak C++ osztályokat nyújthatnak.

• Milyen jellemzőkkel bír egy plugin?

Egy plugin egyrészről mindig Scf interfészt szolgáltat, nem normál C++ osztályokat. a pulgin maga mindig SCF osztályként viselkedik. Ez csakegy része a plugin definíciójának. Egy plugint lehetséges statikus könyvtárnak vagy DLL-nek szervezni, kevés különbség van aközött, hogy hogyan használaod fel a programodban.

Mint Crystal Space felhasználó, a következő lépéseket kell tenned egy plugin használatához:

• -Elsőként hajtsd végre ezeket a lépéseket azoknak a függőségeknek (más pluginok), amiket igényel a plugin.

• -Regisztárld a könytárat, ami a plugint tartalmazza.

• -Töltsd be plugint! Ez inicializániis fogja plugint. Ez nem fog sikerülni, ha elfelejtetted a függőségeket.

• -Kérdezd le a plugin interfészt. Ez egy SCF interfész, ígymost már elérheted a plugin függvényeit.

• Hogyan tudok regisztrálni egy plugin könyvtárat?

A regisztrálás azt jelenti, hogy megmondod az SCF-nek a pluginnak azt a nevét, amit a szerzője adott neki, és egy osztály vagy egy dinamikus könyvtárat rendelsz hozzá. Például a szoftveres grafikus renderelő SCF -nek tudnia kell, hogy az `crystalspace.graphics3d.software a 'soft3d.dll' (Windows) vagy a 'soft3d.so' (Unix) -bantalálható. Az SCF dinamikusan határozza meg, hogy melyplugin könyvtárak mely SCF osztályokat tartalmazzák. A plugintól függően a hozzárendeltmetainformáció a pluginban magábantalálható meg, vagy egy külön fájlban 'csplugin' kiterjesztéssel áll.

Az,hogy hogyan regisztrálj egy könyvtárat, függ attól is, hogy ez egy statikus vagy dinamikus könyvtár, ('.dll' vagy '.so') Egy statikus könyvtár számára, vagyis abban az esetben, amikor azt közvetlenül az alkalmazáshoz linkeled a futásidejű linkelés helyett, helyezd a következő makrót a C++ fájlaid tetéjre egyszer minden egyes SCF oszátly el, amit tartalmaz a könyvátrad:

How you register a library depends on whether it is a static library or a dynamic library (`.dll' or `.so'). For a static library, that is, one which is linked directly into the application rather than loaded dynamically at run-time, put the following macro invocation at top-level in one of your C++ files once for each SCF class contained in your library:

SCF_REGISTER_STATIC_CLASS(
 cxx-class,
 scf-name,
 description,
 dependencies)

Itt a cxx-class annak a C++ osztálynak a neve, ami megvalósítja az SCF osztályt. Az cxx-class -szalmegegyező nevet kell adnod

Here, cxx-class is the name of the C++ class which implements the factory for this particular SCF class. cxx-class is the same name given to the SCF_IMPLEMENT_FACTORY() macro. scf-name is the SCF class name corrsponding to cxx-class, description is a human-readable string describing the purpose of the class, and dependencies is a comma-separated list of other SCF class upon which this class depends.

For a dynamic library, SCF will discover the plugin and register the contained classes automatically by consulting the associated meta-information.

• How can I load the plug-in?

To load a plug-in, you must tell the plug-in manager the name of the plug-in as it was registered in the previous step. In the most common case you will probably use the plug-in loader to load the plug-in. This is a convenience class that is able to load plug-in as specified in a config file, from the commandline, or as requested by the application programmer. In addition to loading the plug-in (the plug-in loader will use the plug-in manager to do that), the plug-in loader will optionally also register the plug-in with the Object Registry.

The object registry is a central location in the Crystal Space framework where any module can register SCF objects. The object registry is not only for plug-ins. It can contain any SCF object. Objects in the object registry also have a tag name associated with them. By convention the default object for a given SCF interface will be added to the object registry with the tag name equal to the interface name. For example, a 3D renderer is a plug-in module that implements (among others) the `iGraphics3D' interface. At the same time there can be multiple 3D renderers in memory (for example, for procedural textures). But the default 3D renderer will be registered with the tag name `iGraphics3D'.

Note that the decision which graphics driver you use (e.g. Software or OpenGL) is done at the time you load the plug-in by passing the name of that driver. At the time you ask for the plug-in interface and use it in your program, this does not make a difference anymore. This makes it possible to exchange the driver simply by loading another driver, but without changing your main program.

The Crystal Space modules themselves will use the standard plug-ins with the default tag name as explained above. For example, the 3d engine looks for the graphics driver by looking in the object registry for an object with the tag `iGraphics3D'.

Now how can you actually load the plug-in? You can either load them manually in the code using the CS_LOAD_PLUGIN() macro or else you can use the plugin loader. As explained above, the plugin loader can load plugins specified on the commandline, a config file, or else explicitly requested in the code. This is done in a specific way: The commandline has highest priority. i.e. if the user specified the OpenGL video driver on the commandline then this will be the plugin that is loaded on the `iGraphics3D' tag. The config file and plugins requested from the code are ignored then (for that tag at least). The plugins requested from the code have lowest priority and only serve as a default if neither the commandline nor the config file specified a plug-in for the given tag.

There is a class called csInitializer() which contains various convenience routines to help initialize a Crystal Space application. This class also contains a routine (RequestPlugins()) which will use the plugin loader automatically.

There are several advantages to using the plugin loader as opposed to manually loading plug-ins using CS_LOAD_PLUGIN():

• - The plugin loader will sort all plug-ins based on dependencies. For example, the engine depends on a 3D rasterizer so the plugin loader will make sure that the engine is loaded later. If you manually load plugins you risk that the loading will fail because a plugin that it needs is not yet present.

• - The user is able to override the plug-ins loaded by the plugin loader. He or she can modify the config file or specify an alternative plug-in on the commandline. There is no way to change what plugin is loaded using CS_LOAD_PLUGIN() unless by recompilation (unless of course you use some other way to read the config file and find out what plugin to load).

• How can I query the plug-in interface?

This is the last step before you can use the plug-in. It means that inside your program you ask the object registry for an object registered with the desired tag. The easiest way to do this is as follows: CS_QUERY_REGISTRY(object_reg,iInterface). This macro will search the object registry for the default object implementing the given interface (i.e. the object registered with the tag equal to the interface name). Alternatively you can also use CS_QUERY_REGISTRY_TAG() to get an object with a specific tag.

• Conclusion

To sum it up, SCF is mainly used to provide common interfaces for DLLs, but it can also be used by statically linked libraries. If you want to know how to write a plug-in yourself, you should read the complete SCF documentation. See section Shared Class Facility (SCF).

For further information about modules and plug-in drivers, see the sections on using Crystal Space (see section Using Crystal Space).

Now that you have learned some basics about the Crystal Space environment, you can try writing your first program.

This document was generated using texi2html 1.76.