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 with the source or online at:
The web page generally has the most up to date documentation (sometimes even current with the Beta version) which can be useful or somewhat confusing, if it discusses features that aren't in the version you are using. The documentation is brought from the web page at the time of release, so what's on your disk should be in sync with the source.
The important exception is the release notes, which describe issues or problems identified after release. Be sure to check there if you have any problems.
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.
Method and Parameter Names
Method and parameter are not fully standardized and have errors. (Regrettably.) The desired convention is as follows:
For methods that return pointers:
Generally no prefix is used for queries that return a simple value.
Kyra uses the following directories:
One of the joys of doing a project like this, is that there isn't a time line, and you can choose particular courses of action on a fun factor as well as prudence.
Hence the lack of use of STL (except string).
Kyra has its own container, utility, and iterator classes. They were fun to write, but have no real advantage over the STL. (Well, portability. STL is still a bit flakey.) As a Kyra user, you will probably never even notice them.
But under the hood they lurk.