diff --git a/pr-preview/pr-504/examples-engine-events.html b/pr-preview/pr-504/examples-engine-events.html index 5da622fce..225ee5a33 100644 --- a/pr-preview/pr-504/examples-engine-events.html +++ b/pr-preview/pr-504/examples-engine-events.html @@ -49,7 +49,51 @@

Events

Using the cubos::core::ecs::EventReader and cubos::core::ecs::EventWriter.

-

This example shows how the cubos::core::ecs::EventReader and the cubos::core::ecs::EventWriter can be used and configured, in a simple scene, to emit and read events. These are in the core, meaning, you don't need to add them to cubos.

Firstly, we need to create and register the event we want to emit. Here, our event has one variable, however, you can give it any number of variables of any type you want.

To receive these events, we can make a simple system, using the cubos::core::ecs::EventReader and iterating through all the events it has. This will be the layout of all our reader systems (A, C, D).

Now, to emit these events, we will use the cubos::core::ecs::EventWriter. This system will emit 3 events on the first frame and another 3 on the second frame. By setting the value of the ShouldQuit resource to true on the second frame, the engine stops before reaching the third frame.

Lastly, let's set the order we want these system to execute in.

These are the expected results with this order.

There are a couple of things to note here. First, the order in which the systems appear to receive the event. C receives the event, followed by D, this happens because even though A comes before C it also come before B, which is where the event is emitted, this means that C and D can read the event emitted by B on that same frame, while A will only read it on the next frame. This also explains why on the second run, A is never displayed, indeed, the engine quit before A got a chance to receive it's so desired events. This shows how the results of the execution of systems that use events may vary with the order set for them, so special care should be taken when defining this.

+

This example shows how the cubos::core::ecs::EventReader and the cubos::core::ecs::EventWriter can be used and configured, in a simple scene, to emit and read events. These are in the core, meaning, you don't need to add them to cubos.

Firstly, we need to create and register the event we want to emit. Here, our event has one variable, however, you can give it any number of variables of any type you want.

struct MyEvent
+{
+    int value;
+};
    cubos.addEvent<MyEvent>();

To receive these events, we can make a simple system, using the cubos::core::ecs::EventReader and iterating through all the events it has. This will be the layout of all our reader systems (A, C, D).

static void firstSystem(ecs::EventReader<MyEvent> reader) 
+{
+    for (const auto& event : reader)
+    {
+        CUBOS_INFO("A read {}", event.value);
+    }
+}

Now, to emit these events, we will use the cubos::core::ecs::EventWriter. This system will emit 3 events on the first frame and another 3 on the second frame. By setting the value of the ShouldQuit resource to true on the second frame, the engine stops before reaching the third frame.

static void secondSystem(ecs::EventWriter<MyEvent> writer, ecs::Write<State> state, ecs::Write<cubos::engine::ShouldQuit> quit)
+{
+    state->step += 1;
+    if (state->step == 1) // Write 1 2 3 on first run.
+    {
+        writer.push({1});
+        writer.push({2});
+        writer.push({3});
+        CUBOS_INFO("B wrote 1 2 3");
+    }
+    else if (state->step == 2)
+    {
+        quit->value = true; // Stop the loop.
+        writer.push({4});
+        writer.push({5});
+        writer.push({6});
+        CUBOS_INFO("B wrote 4 5 6");
+    }
+}

Lastly, let's set the order we want these system to execute in.

These are the expected results with this order.

    // Should print:
+    // B wrote 1 2 3
+    // C read 1
+    // C read 2
+    // C read 3
+    // D read 1
+    // D read 2
+    // D read 3
+    // A read 1
+    // A read 2
+    // A read 3
+    // B wrote 4 5 6
+    // C read 4
+    // C read 5
+    // C read 6
+    // D read 4
+    // D read 5
+    // D read 6

There are a couple of things to note here. First, the order in which the systems appear to receive the event. C receives the event, followed by D, this happens because even though A comes before C it also come before B, which is where the event is emitted, this means that C and D can read the event emitted by B on that same frame, while A will only read it on the next frame. This also explains why on the second run, A is never displayed, indeed, the engine quit before A got a chance to receive it's so desired events. This shows how the results of the execution of systems that use events may vary with the order set for them, so special care should be taken when defining this.