Differences

This shows you the differences between two versions of the page.

--- en:toolworks:docs:apparatus:architecture [2021/09/01 17:48] – vladius
+++ en:toolworks:docs:apparatus:architecture [2022/01/05 12:55] (current) – [Iterating] add TODO jispar
@@ Line 11: / Line 11: @@
 ===== Mechanisms =====
-Mechanisms to Apparatus are what Worlds to Unreal Engine. They provide a somewhat global state, a "scenery" context.
+//[[en:toolworks:docs:apparatus:mechanism|Mechanisms]]// to Apparatus are what Worlds to Unreal Engine. They provide a somewhat global state, a "scenery" context, comprising Subjects (Subjectives) and the Mechanics operating on them.
-Mechanisms are bound tight to their Worlds. If there are some Mechanics or Subjectives with a World, a Mechanism is created automatically, but you can also create it manually like you would any other ''UObject'' (''[[ue>API/Runtime/CoreUObject/UObject/NewObject|NewObject<UMechanism>(...)]]'').
+Mechanisms are bound tight to their (Unrelean) World counterparts. If there are some Mechanics or Subjectives within your ''UWorld'', a Mechanism is created automatically. Of course, you can also obtain it manually or even create a separate (transient) Mechanism instance.
-Please, see the corresponding [[appi>class_u_mechanism.html|API reference]] for more details.
 Within the Machine/Mechanisms in particular and inside Apparatus as a whole, two relating "worlds" exist. These are two levels of ECS data processing with their own unique features and optimizations.
@@ Line 21: / Line 19: @@
 ===== 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:toolworks:docs:apparatus:trait|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.
 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, the whole notion is correct. The hardware layer of CPUs and RAM is really tailored towards this memory organization. Modern-day CPUs have some large cache capacities which are utilized more efficiently when used with the data pieces stored next to each other.
@@ Line 57: / Line 55: @@
 ===== Filtering =====
-//Filtering// is an essential part of the proper ECS implementation. It lets you select specific Subjects and Subjectives to work apon. Using the word "select" in this context is not by chance as the term could be very familiar to a database programmer. Technically it's quite the same. You define a "WHERE" clause with a set of conditions to meet. These can be both inclusive (positive) and exclusive (negative).
+//[[en:toolworks:docs:apparatus:filter|Filtering]]// is an essential part of the proper ECS implementation. It lets you select specific Subjects and Subjectives to work apon. Using the word "select" in this context is not by chance as the term could be very familiar to a database programmer. Technically it's quite the same. You define a "WHERE" clause with a set of conditions to meet. These can be both inclusive (positive) and exclusive (negative).
 Apparatus uses all sorts of different optimization schemes and caches to make the filtering process as fast as possible. You shouldn't worry too much about that.
-[[appi>struct_f_filter.html|API documentation]] for filters.
 ===== Iterating =====
-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 //Iterators// and //Cursors//.
+Once you have your Subjects spawned and set. Belts or Chunks enchained you're ready to //[[en:toolworks:docs:apparatus:iterating|iterate]]// on them to deliver the necessary logic of the game or application. This is done through a very common concept of //Iterators// and //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.
+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. /* TODO - update this line for current Apparatus version - 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>struct_f_chunk_chain.html#a81fe6a135e15ca00736cdd6ef527c3f3|Begin]] and [[appi>struct_f_belt_chain.html#a8552c76ac87bcafb0a8077bbea5ade90|Advance]] methods is provided accordingly.