- Main Page
- Classes
- Files
- Directories
- Related Pages

# Kyra Documentation

### 2.1.3

A Sprite Engine...from a Slightly Different Point of View

Kyra is a simple, fully featured, industrial strength Sprite engine written in C++. It is built on top of SDL for cross platform compatibility. It is Open Source and provided under the GPL.

The API that is documented here is intended to be accessible and easy to use. It is created with you the user in mind.

Note, however, that the API documented here is the details of how the engine works. For the big picture, you should start with the HTML documentation, available online at:

www.grinninglizard.com/kyra

Brief API overview:

The KrEngine is a class that aggregates important components as well as providing some API calls as well. Kyra applications begin by creating a engine. The KrEngine::Draw methods renders the current sprites to the screen and updates the screen. The Tree method returns a pointer to the KrTree, a data structure where all the objects (drawable and otherwise) are stored. The Vault method returns a pointer to the engine's dictionary, where resources live.

The tutorial and tests files give an overview as to how these peices fit together.

Memory Management

Generally speaking, objects are handed over to kyra components by ownership: that is, the client program 'new's an object, and then it is handed to the kyra object which will later delete it at the appropriate time. (An obvious exception is the engine itself, which you must create and destroy.)

For example, you would create a canvas resource by calling 'new KrCanvasResource' with the appropriate parameters. Rather than memory manage this yourself, you should add it to the Vault, which can be retrieved via the KrEngine::Vault() method. You should not, in the future, delete the canvas resource since it is now owned by the vault. Likewise, when you create canvases by calling 'new KrCanvas', these will be added to the Tree (accessed via KrEngine::Tree() ) and will be deleted by the tree when appopriate.

Names and Namespaces

Method and parameter are not fully standardized and have errors. (Regrettably.) The desired convention is as follows:

For methods that return pointers:

- Create Allocates memory. Returns something to you that you should delete or delete [].
- Get Returns something that is owned by the object. Do not delete.
- To A conversion method. Will return an address if the object can be downcast to "ToThing", null if not. This is a cast, so nothing is created by calling this method.

Other methods:

Generally no prefix is used for queries that return a simple value.

- Calc Implies more work is involved. A slower operation that a typical accessor, and should be used accordingly.
- Query Used when memory is passed in and it is written to. No memory is new'd or deleted by the callee.

Organization

Kyra uses the following directories:

- spriteed Sprite Editor files.
- encoder Encoder files.
- tests Test and demo files.
- engine The files for the main engine and library.
- util Utility and container classes.
- gui User interface widgets.
- guiExtended User interface widgets by external authors.

The following class prefixes:

- Kr Kyra classes.

Nampspaces:

- Kyra itself doesn't use a namespace. (It is old code.) All Kyra classes start with Kr.
- grinliz namespace contains the grinning lizard utilities. General programming utilities and math classes (both 3D and 2D).
- TinyXml also doesn't use a namespace. TinyXml class start with TiXml.