diff --git a/content/interference-fixes.typ b/content/interference-fixes.typ index cf896d3b..ef32e72f 100644 --- a/content/interference-fixes.typ +++ b/content/interference-fixes.typ @@ -1,4 +1,4 @@ -#import "/lib.typ": example, todo +#import "/lib.typ": todo = Preventing Interference @@ -8,104 +8,35 @@ measurement item with too much delay, and some unexpected entity (or entities) s mitigate interference, then, we need that window to be *as short as possible* while still allowing us to spawn transmission entities in that window. -== Tilesets +== Tilesets -The fundamental principle here is to use tile-tick priority (TTP) to set a global order. See -Charlie's great video on TTP for details. #todo[link video] +A _tileset_ is a sequence of redstone components which update in the tile tick phase. We diagram +them so the data signal flows through the sequence right-to-left, which makes the significance of +the components match our left-to-right reading convention and makes it easier to read them. -#todo[fix tileset naming. the tileset is the *structure*. the particular sequence is just one instance of that tileset] +The core principal is that repeaters have higher priority than other components. For example, if a +repeater and comparator are scheduled to activate in the same tick, the repeater always (with one +exception, if the comparator faces into a diode and the repeater does not) activates before the +comparator does. By choosing a regular building pattern, we can avoid this exception entirely. -A *tileset* is a sequence of redstone components which all update in the tile tick phase. Components -later in the sequence have greater significance. To make the significance match our left-to-right -reading convention, we diagram them so the signal flows right-to-left. For example: +// Among repeaters, they activate in the order in which they were scheduled. And among comparators, +// they activate in the order in which they are scheduled. But every repeater activates before any +// comparator (aside from that one exception). This gives us a *stable sort* which we can use to +// globally define update order with arbitrary precision. -#todo[screenshot of the same arbitrary tileset] +=== Lexicographic Tilesets -``` -cmp 1rep 2rep obs 1rep -<--------------------- -``` - -This section will cover how to read and construct tilesets that enforce a *global* ordering for -wireless redstone. - -=== The Tile Tick Priority Queue - -The game schedules tile updates through a priority queue; different components have different -priority, so each stage of the tileset iteratively refines the global order. Across the full -tileset, we can enforce an arbitrary global ordering. - -#todo[the priority table - - call out here that basic comparators and all other components, so from here on out we're just - going to use comparators for simplicity. -] - -Components with different priority always update in priority order, but components with equal -priority update in scheduled order. - -#todo[rephrase or remove - - The core principal is that repeaters have higher priority than other components. For example, if a - repeater and comparator are scheduled to activate in the same tick, the repeater always (with one - exception, if the comparator faces into a diode and the repeater does not) activates before the - comparator does. By choosing a regular building pattern, we can avoid this exception entirely. - - // Among repeaters, they activate in the order in which they were scheduled. And among - // comparators, they activate in the order in which they are scheduled. But every repeater - // activates before any comparator (aside from that one exception). This gives us a *stable sort* - // which we can use to globally define update order with arbitrary precision. - -] - -#example[ - #todo[this explanation is so janky] - - Say these three tilesets are started in the same gametick, `t=0`. - - ``` - <------ - 1 rep cmp ab - 2 cmp rep cd - 3 2rep e - <------ - ``` - - Once `b`, `d`, and `e` are scheduled, the priority queue looks like this: - - ``` - t=2 [d] [b] - t=4 [e] - ``` - - Now at `t=2`, we process the queue in order. - - - `d` activates and schedules `c`. - - `b` activates and schedules `a`. - - ``` - t=4 [e a] [c] - ``` - - Now at `t=4`, the end of the tileset, the lanes will always update in order `3 1 2` - -] - -So the full picture involves arbitrary components and priorities. As long as all the tilesets have -the same total delay and end at the same time, we can determine a global ordering. However the -general picture is hard to reason about, we basically have to simulate the priority queue to make -predictions. If we restrict the design of the tilesets a bit, there are two simplifications we could -take to make things easier to reason about. +#todo[I think remove this, and just make it inline. It shouldn't really be called out.] === Permutation Tilesets -#todo[describe the mixed delay permutation tilesets and the alphabetization procedure] +=== Binary Tilesets === Binary -The simplest tilesets are made entirely of comparators and 2gt repeaters (alternatively: observers -and 2gt repeaters). Repeaters activate before comparators, so if we think of it like sorting words -alphabetically, we can identify repeaters with "A" and comparators with "B". +The simplest tilesets are made entirely of comparators and 2gt repeaters. Repeaters activate before +comparators, so if we think of it like sorting words alphabetically, we can identify repeaters with +"A" and comparators with "B". So, suppose we have a "binary tileset" that is 2gt long. There are two options, A and B. If we alphabetize these, we see the A (repeater) always executes before the B (comparator). With such a @@ -113,8 +44,8 @@ short tileset, that seems trivial; things get more interesting as we add more el ``` <-- -cmp (B) rep (A) +cmp (B) ``` Now let's use 2 components for a 4gt tileset. There are now four options, AA, AB, BA, BB. We can @@ -122,10 +53,10 @@ alphabetize these and see the order. ``` <------ -cmp cmp (BB) -cmp rep (BA) -rep cmp (AB) rep rep (AA) +rep cmp (AB) +cmp rep (BA) +cmp cmp (BB) ``` To break this down: the bottom two (AA, AB) end in repeaters, so they must come first. Among those, @@ -174,7 +105,7 @@ cmp rep rep cmp cmp rep rep === Lexicographic -=== Jamming +=== Mixed Priority Jamming == Block Event Delay