-
Notifications
You must be signed in to change notification settings - Fork 1
Core Components
This page provides an inside look into the core components of the framework. This section mostly includes explanations of various types references throughout the framework, error-handling, and the core component interface.
Since the "Types.hpp" header is included in some way by every single other component of the framework, this component can process various options that will toggle functionality elsewhere.
ZEN_DEBUG_BUILD — If not manually set, the file will attempt to detect any presence of debugging enabled by the compiler. This #define allows for much more detailed logging (allowing for messages with the util::LogMode::ZEN_DEBUG mode set to appear), string identifiers instead of hashed IDs, and potential for further flags to be enabled.
ZEN_API — This identifier is a remnant of the days when I wanted the framework to be exported as a DLL. This caused a lot of problems, mostly because C++ doesn't play very nice with Windows DLLs, but it has been left in there in case some other need should arise for it, such as building as a static library.
Note for Compilation with G++/MinGW: This file will create barebones implementations of various string conversion functions that should be available with the C++11 standard, but aren't for whatever reason. If you are confident that your implementation provides these functions, feel free to remove this block.
There are quite a bit of boilerplate types necessary for a graphical framework. Some of these are defined in the Core Graphics Overview, but there are a few here, as well.
real_t — This is a floating-point precision type that allows for single or double precision based on a preprocessor macro. Defining ZEN_DOUBLE_PRECISION will make this a double, whereas it is a float by default.
string_t — This is currently a shortcut for std::string, but allows versatility should the need arise to create an optimized string class specifically for this framework.
color[3|4]f_t — These structures hold RGB[A] color information. They are used generically throughout the high-level GUI Components, but are also critical to low-level vertex data management. They are intended to range from [0, 1], as is typical in computer graphics, but can have whatever values you want for your own purposes.
Zenderer is split into a number of different components. Some of these require explicit initialization and destruction to utilize, and typically last the length of a program. In order to facilitate automatic initialization and cleanup of these components (which include things such as asset::zAssetManager, gfx::zWindow, and others), there is an abstract base class known as zSubsystem underlying all of these.
Similarly to creating your own asset types, it's possible to register and create your own subsytems. Of course, there is much less functionality provided by doing so, but the ability is there if you should need it. The subsystem will automatically be registered with a global subsystem list, and will log appropriate state to the engine log. There are only a few requirements for implementing your own subsystem object:
- It must have a name.
- It must accurately store initialization state in the
m_initmember variable. - It must be initializable through
zSubsystem::Init(). - It must be destroyable through
zSubsystem::Destroy(). - It must be able to be initialized and destroyed multiple times.
Error handling in Zenderer comes in two forms: pretty – which isn't implemented yet – and ugly. Pretty error handling uses the graphical API to show the user a window with appropriate error text and captioning in a cross-platform and unified fashion. Ugly error handling occurs only when pretty error handling fails, such as an uncreatable window or a non-existent font (for displaying the error text). Ugly error handling is platform-specific, and will show a Message Box on Windows, but only output to stderr on *nix-based systems.