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 @@
Using the cubos::
This example shows how the 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::
Now, to emit these events, we will use the cubos::
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::
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::
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::
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.