Differences
This shows you the differences between two versions of the page.
Both sides previous revision Previous revision Next revision | Previous revision Next revisionBoth sides next revision | ||
en:toolworks:docs:apparatus:architecture [2021/06/07 17:40] – vladius | en:toolworks:docs:apparatus:architecture [2021/09/03 13:39] – [Low-Level Traits] vladius | ||
---|---|---|---|
Line 1: | Line 1: | ||
====== Apparatus Architecture Overview ====== | ====== Apparatus Architecture Overview ====== | ||
- | Apparatus is a complex tool. It's more of a framework with its own ecosystem then some simple plugin. In order to use it effectively and consciously you have to understand how it actually works. We're not talking about the very specifics of the implementation however but the main top-level architectural concepts. | + | Apparatus is a complex tool. It's more of a framework with its own ecosystem then a simple plugin. In order to use it effectively and consciously you have to understand how it actually works. We're not talking about the very specifics of the implementation however but the main top-level architectural concepts. |
===== Machine ===== | ===== Machine ===== | ||
- | Machine is the main system of Apparatus. It's a manager for all the things global and thereby is a global singleton itself. It's actually a UObject but its lifespan is defined by its internal state, not the standard garbage collecting procedures. If the Machine has some Mechanicals | + | Machine is the main system of Apparatus. It's a manager for all the things global and thereby is a global singleton itself. It's actually a UObject but its lifespan is defined by its internal state, not the standard garbage collecting procedures. If the Machine has some Mechanisms |
- | + | ||
- | Within the Machine in particular and inside Apparatus as a whole, two relating " | + | |
The [[appi> | The [[appi> | ||
+ | |||
+ | ===== Mechanisms ===== | ||
+ | |||
+ | // | ||
+ | |||
+ | Mechanisms are bound tight to their (Unrelean) World counterparts. If there are some Mechanics or Subjectives within your '' | ||
+ | |||
+ | Within the Machine/ | ||
===== Low-Level Traits ===== | ===== Low-Level Traits ===== | ||
- | Let's start with the lower layer first. The //Traits// subsystem was actually developed later in time, but it's now at the core of the framework and provides the needed functionality for the upper layer to work properly. | + | Let's start with the lower layer first. The //[[en: |
ECS was once developed with performance in mind. Packing and storing the data linearly in memory, what could be simpler? While it's actually not that easy to implement this for dynamically structured entities and requires some sophisticated bookkeeping, | ECS was once developed with performance in mind. Packing and storing the data linearly in memory, what could be simpler? While it's actually not that easy to implement this for dynamically structured entities and requires some sophisticated bookkeeping, | ||
Line 21: | Line 27: | ||
Traits are primarily based on [[ue> | Traits are primarily based on [[ue> | ||
- | Traits are in turn assembled into collections (or it wouldn' | + | Traits are in turn assembled into collections (or this wouldn' |
- | The whole design maximizes the performance of the Mechanics running on the Subjects, but it actually has some limitations comparing to the higher-level | + | The whole design maximizes the performance of the Mechanics running on the Subjects, but it actually has some limitations comparing to the higher-level |
===== High-Level Details ===== | ===== High-Level Details ===== | ||
- | Unlike Traits, Details are not Structs. They are " | + | Unlike Traits, Details are not Structs. They are high-order |
- | Details are always stored in their respective *Subjectives* - this is a special type of container that is directly associated with an Unreal Actor or User Widget. Subjectives are not iterated directly however but through a special caching storage called | + | Details are always stored in their respective *Subjectives* - this is a special type of container that is directly associated with an Unreal Actor or User Widget. Subjectives are not iterated directly however but through a special caching storage called |
- | Please note, that all of the Subjectives are actually Subjects internally. They all have a Subject [[appi>struct_f_subject_handle.html|Handle]] in them. This means you can add traits to them. You can interchangeably utilize the both worlds together when/if needed. It's all up to you. | + | Please note, that all of the Subjectives are actually Subjects internally. They all have a Subject [[appi>lass_i_subjective.html# |
===== Enchaining ===== | ===== Enchaining ===== | ||
- | One of the main technical goals of Apparatus is to effectively process some very large amounts of subjects | + | One of the main technical goals of Apparatus is to effectively process some very large amounts of Subjects |
- | Enchaining is a process of collecting all of the currently available | + | Enchaining is a process of collecting all of the currently available |
- | Instead you have to use a global (static) | + | Instead you have to use Mechanism' |
===== Locking ===== | ===== Locking ===== | ||
- | During iterating the chains and their respective chunks and belts we have to guarantee a certain level of immutability for them. We don't want to process the same subject twice, for example, as it may be tossed around | + | During iterating the chains and their respective chunks and belts we have to guarantee a certain level of immutability for them. We don't want to process the same subject twice, for example, as it may be tossed around |
- | When the chunk or belt becomes enchained, its internal locks counter is incremented | + | When the Chunk (or Belt) becomes enchained, its internal locks counter is incremented, making it somewhat frozen to the evaluating |
===== Filtering ===== | ===== Filtering ===== | ||
- | *Filtering* is an essential part of the ECS paradigm | + | //Filtering// is an essential part of the proper |
Apparatus uses all sorts of different optimization schemes and caches to make the filtering process as fast as possible. You shouldn' | Apparatus uses all sorts of different optimization schemes and caches to make the filtering process as fast as possible. You shouldn' | ||
[[appi> | [[appi> | ||
- | |||
===== Iterating ===== | ===== Iterating ===== | ||
Line 60: | Line 65: | ||
Once you have your Subjects spawned and set. Belts or Chunks enchained you're ready to iterate on them to deliver the necessary logic of the game or application. This is done through a very common concept of // | Once you have your Subjects spawned and set. Belts or Chunks enchained you're ready to iterate on them to deliver the necessary logic of the game or application. This is done through a very common concept of // | ||
- | Both Belt and Chunk have their own types of Iterators, but you would rarely use them directly. Instead you'll almost always use Chain Cursors. They are essentially Iterators with a naming chosen to eliminate some possible ambiguity. For now you should only use the default (implicit) Cursor as the threading is still a planned feature and you would rarely need to iterate a Belt (or a Chunk) with multiple different Cursors. | + | Both Belt and Chunk have their own types of Iterators, but you would rarely use them directly. Instead you'll almost always use the Chain Cursors. They are essentially Iterators with a naming chosen to eliminate some possible ambiguity. For now you should only use the default (implicit) Cursor as the threading is still a planned feature and you would rarely need to iterate a Belt (or a Chunk) with multiple different Cursors. |
The API documentation for [[appi> | The API documentation for [[appi> | ||
+ | |||
+ | ===== Afterword ===== | ||
+ | |||
+ | This overview is of course just an overview of what Apparatus really is but we hope it helps you to grasp the main idea of the toolset. We will continue to elaborate on the specifics of the implementation in some separate articles of the Turbopedia. Stay tuned. | ||