inomanoms
Eye of Cthulhu
So... I had promised this thread quite some ago. Despite having the general idea of how to build a multiplex in Terraria thought through, I kept running into snags, so that I hadn't been able to post with a working build until now. As a disclaimer, I am by no means computer or logics savy individual, so my understanding of what a multiplex is hinges mostly on what was explained to me in high school Comp. Sci. regarding how numerous phone calls were communicated over overseas landlines in the early days of telecommunications. Wikipedia tells me, this is what would be specifically called a Time Division Multiplex (?). I welcome the more knowledgable of you out there to explain or teach me in what ways what I present here is a multiplex, or not.
This build deals (again) with the subtract 3 function of Joe's @DicemanX calculator. For clarification's sake, it is not a full BCD to binary converter. All this build does, is take three digits of BCD and evaluate them once, taking values of 12 to 8 and converting them to the values 9 to 5. The build does this, however, without a copy of the subtract 3 function for each digit of BCD. Basically, what I am attempting to demonstrate here, is how to share a function among a set of data.
http://www2.zippyshare.com/v/6VuT32Xc/file.html
As with my 1 Tick Logic Gates guide, this build utilizes multiple dummy ghost actors, which are given an event order by running the player through a tele-hoiking track to initialize the dummy ghosts and send them into the mechanism (see bottom left corner of any of the wiring thumbnails). Event order is crucial to having the mechanism work right. Within a game frame, Terraria considers the actions of one actor after another, and if we know the order in which the game considers these actors, we can begin orchestrating sub-tick level executions. There are four actors in total; three dummy ghosts and the player himself. Each of the actors is responsible for a particular part of the build, and these are (as shown in the first full image):
Let's dive into a play-by-play of the build.
After the player has run through the tele-hoiking track to establish event order among the dummy ghosts and send them into the mechanism, the ghost dummies are all run through delays in order to introduce them with a desired timing to their respective parts of the build. The ghost dummies to memory and the logic gate of the sub 3 function arrive first and within the same game tick, but with the ghost dummy sent to memory having a lower (earlier) event order than the ghost dummy sent to the logic gate. For the next three game ticks, the ghost running memory sends impulses to the logic gate, which are read by the ghost in the logic gate in order to determine its path down the logic tree, and reset. The simultaneous reading and resetting of an impulse on the reading end of an impulse sent by another part of the mechanism is key to how this multiplex works. Notice how all parts of the build are connected to each other by one communicating wire. When one part of the mechanism sends out a signal intended for only one other part of the mechanism, this signal is broadcasted to ALL parts of the build. Who this signal is intended for, is determined purely by the event order of the hoiking actors and their position in their hoiking tracks. In order to prevent this signal from being incorrectly utilized by a wrong part of the build, the reading end needs to reset the signal, or clear the communications line.
At four ticks, all the memory to a digit of BCD has been read, and the ghost in the logic tree comes to the end of its branching. The dummy ghost responsible for the output table of the subtract three function is now called up by the dummy ghost running the logic tree to the correct output row of the output table, and the player, who is responsible for facilitating the demux to memory, enters his track. The logic output table dummy ghost and the player running the demux of the memory bank enter a partnership similar to that of the dummy reading memory with the dummy transversing the logic gate: the dummy ghost in the logic output table is of lower (earlier) event order than the player actor (or, actually, it is of higher event order, but in the sense that the player actor immediately follows the logic output table dummy ghost in the game tick cycle, the logic output table dummy ghost is of "lower" event order). The ghost dummy of the logic output table sends a signal to the player in the demux, and the player in the demux uses this signal to overwrite memory and change the display before resetting the broadcast signal. And thus we have a cycle where: memory is read in order to; advance a step through the logic gate tree and; the output of the logic tree in a previous digit of BCD; is written to memory and changes the display. This is the basic explanation of how the multiplex works.
Two things are left to be mentioned. Firstly, in order to be able to synchronize the logic gate with the rest of the build, it is necessary for the logic tree to have a uniform execution time. The logic tree cannot shortcut dead ends, so where the hoiking actor would run into dead ends in the logic tree, the actor needs to be sent to an idle track which, in this build, is the bottom left row of the subtract three function. Secondly, once in their parts of the mechanism, the ghost dummy running the logic tree and ghost dummy in the logic output table are stuck in an infinite loop. In order to eject them, the first node of the logic gate tree and the holding bay of the ghost dummy to the logic output table need to be formulated as junctions that can receive an impulse from the ghost dummy in the memory track and player actor in the demux track respectively, to signal that the latter hoiking actors have reached the ends of their tracks.
Since Terraria 1.3, the introduction of dummy ghosts has broken down the barrier to mechanisms that employ multiple, simultaneously executing hoiking actors. As we progress towards Terraria 1.3.1, many aspects of mechanical engineering will change, especially in regards logic gates since the developers will be adding these as actual items to the game. Hoiking, however, will remain relevant and a deeper understanding of actor event order crucial if we want achieve faster, low latency builds. Please leave any comments, criticisms, suggestions for improvement to this thread below. Also likes. I appreciate the recognition.
-inomanoms
This build deals (again) with the subtract 3 function of Joe's @DicemanX calculator. For clarification's sake, it is not a full BCD to binary converter. All this build does, is take three digits of BCD and evaluate them once, taking values of 12 to 8 and converting them to the values 9 to 5. The build does this, however, without a copy of the subtract 3 function for each digit of BCD. Basically, what I am attempting to demonstrate here, is how to share a function among a set of data.
http://www2.zippyshare.com/v/6VuT32Xc/file.html
As with my 1 Tick Logic Gates guide, this build utilizes multiple dummy ghost actors, which are given an event order by running the player through a tele-hoiking track to initialize the dummy ghosts and send them into the mechanism (see bottom left corner of any of the wiring thumbnails). Event order is crucial to having the mechanism work right. Within a game frame, Terraria considers the actions of one actor after another, and if we know the order in which the game considers these actors, we can begin orchestrating sub-tick level executions. There are four actors in total; three dummy ghosts and the player himself. Each of the actors is responsible for a particular part of the build, and these are (as shown in the first full image):
- the binary values of the BCD digits stored in memory
- the logic tree of the subtract 3 function
- the output table of the subtract 3 function and
- the demux for the output of the subtract 3 function sent to memory
Let's dive into a play-by-play of the build.
After the player has run through the tele-hoiking track to establish event order among the dummy ghosts and send them into the mechanism, the ghost dummies are all run through delays in order to introduce them with a desired timing to their respective parts of the build. The ghost dummies to memory and the logic gate of the sub 3 function arrive first and within the same game tick, but with the ghost dummy sent to memory having a lower (earlier) event order than the ghost dummy sent to the logic gate. For the next three game ticks, the ghost running memory sends impulses to the logic gate, which are read by the ghost in the logic gate in order to determine its path down the logic tree, and reset. The simultaneous reading and resetting of an impulse on the reading end of an impulse sent by another part of the mechanism is key to how this multiplex works. Notice how all parts of the build are connected to each other by one communicating wire. When one part of the mechanism sends out a signal intended for only one other part of the mechanism, this signal is broadcasted to ALL parts of the build. Who this signal is intended for, is determined purely by the event order of the hoiking actors and their position in their hoiking tracks. In order to prevent this signal from being incorrectly utilized by a wrong part of the build, the reading end needs to reset the signal, or clear the communications line.
At four ticks, all the memory to a digit of BCD has been read, and the ghost in the logic tree comes to the end of its branching. The dummy ghost responsible for the output table of the subtract three function is now called up by the dummy ghost running the logic tree to the correct output row of the output table, and the player, who is responsible for facilitating the demux to memory, enters his track. The logic output table dummy ghost and the player running the demux of the memory bank enter a partnership similar to that of the dummy reading memory with the dummy transversing the logic gate: the dummy ghost in the logic output table is of lower (earlier) event order than the player actor (or, actually, it is of higher event order, but in the sense that the player actor immediately follows the logic output table dummy ghost in the game tick cycle, the logic output table dummy ghost is of "lower" event order). The ghost dummy of the logic output table sends a signal to the player in the demux, and the player in the demux uses this signal to overwrite memory and change the display before resetting the broadcast signal. And thus we have a cycle where: memory is read in order to; advance a step through the logic gate tree and; the output of the logic tree in a previous digit of BCD; is written to memory and changes the display. This is the basic explanation of how the multiplex works.
Two things are left to be mentioned. Firstly, in order to be able to synchronize the logic gate with the rest of the build, it is necessary for the logic tree to have a uniform execution time. The logic tree cannot shortcut dead ends, so where the hoiking actor would run into dead ends in the logic tree, the actor needs to be sent to an idle track which, in this build, is the bottom left row of the subtract three function. Secondly, once in their parts of the mechanism, the ghost dummy running the logic tree and ghost dummy in the logic output table are stuck in an infinite loop. In order to eject them, the first node of the logic gate tree and the holding bay of the ghost dummy to the logic output table need to be formulated as junctions that can receive an impulse from the ghost dummy in the memory track and player actor in the demux track respectively, to signal that the latter hoiking actors have reached the ends of their tracks.
Since Terraria 1.3, the introduction of dummy ghosts has broken down the barrier to mechanisms that employ multiple, simultaneously executing hoiking actors. As we progress towards Terraria 1.3.1, many aspects of mechanical engineering will change, especially in regards logic gates since the developers will be adding these as actual items to the game. Hoiking, however, will remain relevant and a deeper understanding of actor event order crucial if we want achieve faster, low latency builds. Please leave any comments, criticisms, suggestions for improvement to this thread below. Also likes. I appreciate the recognition.
-inomanoms
Last edited:
