- Generated by
1.9.4
The following is an overview of components which are part of Guiliani's hardware abstraction layer and therefore potentially relevant to porting issues. A typical porting task will not affect all of these components, since most of them are re-usable across various operating systems and target devices.
Each of the following sections names the interfaces which Guiliani expects to be implemented and also references to the respective Guiliani and eC (embedded Components) classes, where these implementations typically occur.
Please be aware that due to the cross-platform character of the framework, not all functions declared within the framework's base class need to be available in all platform-specific implementations.
Hint: In order to ease porting, Guiliani offers Null-Implementations for many components (e.g. CGfxWrapNull or CGUINullInput). Those are useful if you quickly wish to set up Guiliani on a new platform and then successively implement the required abstraction classes one at a time.
List of relevant components:
This class abstracts graphics access. Typically around 30 interfaces need to be implemented. These fulfil graphic tasks such as:
For details on these interfaces and the parameters which they receive, please refer to the documentation of
Guiliani supports various font engines, and allows their combination with various graphic libraries. It is for example possible to use the OpenGL graphics wrapper in combination with FreeType, or with Windows (wgl) Fonts.
User Input is retrieved via classes derived from CGUIInputMedia. An input media implementation has the following responsibilites:
In order to implement your own input media, you will need to implement the CGUIInputMedia::GetEvent() API and the CGUIInputMedia::StopIdle() API. GetEvent must read incoming events from platform dependent interfaces and transform them into Guiliani events. These events (CGUIEvent) are then returned to the framework which forwards them to the correct objects within the user interface.
To avoid permanent polling for input events, it is recommended that GetEvent() sleeps until an event is received, but it MUST NOT block longer than the maximum allowed idle-time, which is handed over as a parameter to GetEvent().
Guiliani will also call StopIdle() whenever it needs to wake up from sleeping, so make sure to implement StopIdle() in such a way, that it interrupts your sleeping code within GetEvent().
While multi-threading is not directly required by Guiliani itself, there are some optional features that require support for thread and semaphore handling. These are for example the loading of images in a background thread, or the CommandObject interface for thread-safe interaction with an external application.
The implementation of the CGUIThread base class in the Guiliani core only provides the platform-independent methods. When porting Guiliani to a new platform, the following methods of CGUIThread have to be implemented:
Guiliani comes with a ready-to-use fixpoint datatype. This will work for all typical use cases. Nevertheless, it might be the case that a given platform offers specialized math routines that allow for optimization of certain operations.
File I/O is used by Guiliani for accessing external resources and for error logging. Note: Guiliani is capable of running on systems without a file system by compiling the respective resources (e.g. images, XML files) right into the application's executable file.
Guiliani uses smart pointers for some classes (e.g. CommandObjects) which keep a reference count of their users, in order to simplify their handling and to avoid memory leaks. For these objects, it is important to have atomic increment and decrement operations to ensure the validity of the reference count, even in multi-threaded use cases.
1.9.4