IceShard 1
A personal game engine project, with development focused on 2D/2.5D games.
Loading...
Searching...
No Matches
Welcome to IceShard's API Documentation

Note
This page currently under construction, and the currently generated documentation only consists of files found under source/code/core. I hope to provide the full documentation as soon as possible! - Dandielo

Project Structure

Due to the amount of code this engine already had and predictably would end up with, the codebase was early on separated into multiple categories. Each category has a general purpose and set of (still) unwritten rules that I try to follow to ensure some conformity.

The categories are:

  • Core - Holds libraries that provide most common types, collections or core functionality like logging or native file APIs.
  • Systems - Holds libraries that define system APIs (often with basic implementations) that abstract away large chunks of logic.
  • Platforms - Holds implementations of all supported platforms and their supported features.
  • IceShard - Holds implementation of IceShard which is separated into a public API project and the dynamically loaded implementation of it.
  • Modules - Holds implementations of various systems, like Rendering or DevUI. (If some modules are missing the engine can run without them)
  • Framework - Holds logic commonly seen in games and can be used to quick-start a project.
  • Examples - Holds examples for each supported platform.
  • Tools - Holds additional tools that are used by the project. (ex.: Packaging tool for the HailStorm format)

Core libraries

All libraries in this category provide a specific set of types or functionality for a single simple topic. All are either statically linked or header only. In some cases the APIs' are designed with C like APIs' focusing on free functions, while some libraries are now utilizing C++ concepts and explicit this features to utilize member syntax, while allowing to extend types with common functionality. (See Collections library for examples)

Some libraries utilize global state is some form, however, unless explicitly initialized from the final binary the API's fallback to implementations that do not require a global state, which might result in reduced functionality. For example:

  • The logger will not resolve custom tags nor attach additional information like timestamps.
  • The DevUI is fully disabled until a runtime DevUI module is loaded.

Currently the following libraries are part of this category:

  • Core - Provides most basic type aliases / defitions, constants, build defines based on the targeted platform.
  • Math - Provides types for basic math functions and vector arithmetic.
  • Memsys - Provides API interface for memory allocation and allocation tracking.
  • Collections - Provides access to basic container types, including but not limited to String, Array, HashMap, and others.
  • Modules - Provides utilities to load and initlize API's across all runtime loaded modules.
  • I18N - Provides API interface for internationalization features.
  • Logger - Provides API interface and implementation for advanced message logging.
  • Tasks - Provides API interface and implementation for multi-thread processing. (built around C++ coroutines)
  • DevUI - Provides API interface for registering of widgets and ImGui utility functions. (requires runtime implementation)
  • Utils - Library for various utility functions that are too small for their own projects yet, but require a place in Core.