[Guide] 1 Tick Logic Gates

[inomanoms]

Putting together @Thiner's discovery of dummy ghosts and @z26's use of them as hoiking agents, @DicemanX's explanation of terrarian logic gates, and @ZeroGravitas' insights on event orders within a game tick, I would like to present to you a method of creating gates that execute within one game tick.

​

http://www3.zippyshare.com/v/6Dkdnz2v/file.html


The above is the add3 function of Joe's binary to BCD converter. If you look at the green wiring, you will almost see the tree as it is shown in Joe's updated logic gates thread, at least on the left side of this TEdit screen shot. The difference between the gates presented in that thread and this one, is that instead of teleporting a signaling agent from node to node, here, multiple ghost dummies are first initialized and teleported to/captured inside the nodes. Then, when the mechanism is executed, the game goes through the nodes in the order the dummies were initialized, and depending on the input switches, passes on a signal down the hierarchy of nodes; a process which repeats until the bottom of the tree is reached.

This method is "faster" than passing a hoiking actor, since within a game frame, a single hoiking actor can only perform a single hoik step, while many actors, each performing a single hoiking step, perform together more actions within a game frame. This method is limited only by the number of hoiking actors available to you (dummies a max 100). I say "faster" in quotations, because while more work is done in a game frame with this method, more work with in a game frame means that single game frame can last longer than 1/60th of a second and result in lag. For this reason, it is important to initialize the hoiking actors to relatively stationary positions, where, with quick and short movements (no teleportation), they can work efficiently. Despite the warnings, this method is powerful and results in significant cuts to latency.

Let us look at one of the nodes:

After the player runs the gauntlet of tele-hoiks in the bottom portion of the build in order to establish a hierarchy of action order among the dummy ghosts (left to right), all the dummy ghosts are teleported into one of these, all identical looking nodes. The dummy is teleported in on the left side of the teleporter where the rightmost of the pair of uphoiks on the left (A) arrests the ghost against the a ceiling. The pair of up hoiks (A), together, are the execution blocks, since their toggle state dictates whether the dummy ghost is stayed in the node (state as shown) or moved over to the right side of the node (inverse of currently shown activation states). Hoiking block B is controlled by an input switch. It dictates whether, when the dummy is hoiked to the right by the execution blocks, the lower or higher of the two pressure plates on the right is activated. It is also what necessitates the "catch block" in A; without it, a change of hoiking block B could prematurely execute the node. When hoiking block B is actuated, the higher, right-most pressure plate is activated, and when deactuated, the lower left pressure plate. The pressure plates determine which next node in the tree will be forced to execute, and at the same time feed back to hoiking blocks A so that when the ghost is rebounded by hoiking block C, it is again caught.

I hope this is enough information for anyone who is interested to be able to make inroads on understanding my build. If you have any questions, please ask.

-inomanoms

 

[DicemanX]

Nice work! It's great to see the synthesis of so many ideas as we progress towards better operation times. It'll be interesting to see how we could implement the multi-agent approach to the shifter, because with a single signaling agent it contributes the most to operation time (N+3xBCD ticks per cycle, and N cycles for N bits; so in my example build with 9 bits and 3 BCD displays a single agent uses 21x9 ticks for just the shifting alone). I tried using the shark approach to do simultaneous shifting with 21 dummies but got some inconsistent results so I've put it on hold for the moment.

One question though - what exactly is the limit to the dummy ghosts? Does the limit only apply to the number that can be in operation at any one time? Could I put down, say, 500 dummies in a world and have a small portion in operation at any one time? In my digit input machine I'm already using 35 dummies just to be able to input a 3 digit number calculator-style, and to make a calculator I'd need to append a number of converters and the ripple-carry adder (along with other machines that can carry out other arithmetic operations still to be created).

 

[inomanoms]

One question though - what exactly is the limit to the dummy ghosts? Does the limit only apply to the number that can be in operation at any one time? Could I put down, say, 500 dummies in a world and have a small portion in operation at any one time?

I am not sure on these points. I assume the 100 (@Thiner?) dummies is the cap on the number of ghosts spawn-able within the 200 by 200 tile square around the player after which the game starts ignoring any new dummies it comes across for ghosts until the number of in game ghosts is reduced by a ghost passing into the despawn range, 10000 tiles away from the player.

I'm guessing spawning all the dummy ghosts before entering a mechanism and moving them around as needed is the way to go since this informs you the action order of the ghosts which is important. Either that, or generously spacing the parts of the build away from each other and moving the player from part to part to as the mechanism executes and teleporting unused ghosts far away to force despawn them (they can't be killed). Usually though, the player needs to stay in one place to service input switches and the like.

 

[Buckybomb]

This looks impressive. It runs completely over my head and you and DicemanX are speaking some alien language (as in I'm still learning how to work this. Any links about logic gates I can read up on? Thanks )

 

[inomanoms]

This looks impressive. It runs completely over my head and you and DicemanX are speaking some alien language (as in I'm still learning how to work this. Any links about logic gates I can read up on? Thanks )

Well, I can point you to Joe's recently updated Logic Gate thread which shows how to create "logic gates" in Terraria, but if you are looking for a more "basics" of logic, I don't know if I can help you. The most I know about them is what I learned in high school: AND, OR, XOR and NOT gates. Mostly, I take what Joe knows and does and try to modify it to make it more efficient. Sorry...

 

[Buckybomb]

Well, I can point you to Joe's recently updated Logic Gate thread which shows how to create "logic gates" in Terraria, but if you are looking for a more "basics" of logic, I don't know if I can help you. The most I know about them is what I learned in high school: AND, OR, XOR and NOT gates. Mostly, I take what Joe knows and does and try to modify it to make it more efficient. Sorry...

Thanks anyways! I'll look into it.

 

[ZeroGravitas]

This is looking mightily impressive. You've brought so many principles together here very neatly. Applying full understanding of terraria wiring, dummy initialisation priority and block physics detection priority for a newly nuanced approach to captive actor hoiktronics, circumventing the practical limitations of teleporter use and such. Then applying it to real logic problems. I'd say you're leading the field of understanding here.

So your setup does the whole operation in a single tick? (I've use 'tick' rather than 'frame' because frame rate varies or skips depending on graphics settings.) So that means my old binary counter could ripple through it's update in a single tick too. Although it's max count rate would still be limited to 60acts/s, as far as I understand things, since the input actor can only be hoiked once per tick.

So it looks like the only hard limit to this in-game computational approach will be dummies...

dummies a max 200

Unfortunately it is only 100, unless you have a different experience than me (the 101st dummy had no soul).
It will still be mightily impressive if we (you guys) push up against this limit, because it represents a hard limit of the amount of 'parasitic computing' available from the game; translating and exploiting individual "if, then" checks per operation. Madness. Even if we were able to start exploiting (up to) 1000 projectiles per tick in a similar way, thanks to a future update (hard to imagine working), it wouldn't be much of a step up in comparison to the leap already made from blundering birds. I think you'd have to somehow start hacking the graphics engine to get any better than this...
[DOUBLEPOST=1440047871,1440047466][/DOUBLEPOST]

Could I put down, say, 500 dummies in a world and have a small portion in operation at any one time?

Yes, but as far as I know you can't despawn them without breaking the dummy stand, which you could do by actuating the blocks underneath, but it's a one time thing. You'll probably have to juggle the same set of 100 dummies; keep recycling them, while keeping them in order and such. Should be fairly do-able. Even if you did lump them all together for some reason, you can 'deal them out' again by feeding them through one of my old launcher mechanisms (since they launch in priority order when the first actor out de-actuates the tooth that kicked it).

 

[Full Metal Kirby]

-snip-
[DOUBLEPOST=1440047871,1440047466][/DOUBLEPOST]
Yes, but as far as I know you can't despawn them without breaking the dummy stand, which you could do by actuating the blocks underneath, but it's a one time thing. You'll probably have to juggle the same set of 100 dummies; keep recycling them, while keeping them in order and such. Should be fairly do-able. Even if you did lump them all together for some reason, you can 'deal them out' again by feeding them through one of my old launcher mechanisms (since they launch in priority order when the first actor out de-actuates the tooth that kicked it).

Haven't actually tested this, but wouldn't dropping them off of the bottom of the world (after removing any blocks beyond the screen boundary) despawn them?

 

[inomanoms]

This is looking mightily impressive. You've brought so many principles together here very neatly. Applying full understanding of terraria wiring, dummy initialisation priority and block physics detection priority for a newly nuanced approach to captive actor hoiktronics, circumventing the practical limitations of teleporter use and such. Then applying it to real logic problems. I'd say you're leading the field of understanding here.

These are the kind of glowing remarks you are proud to take home to mom and dad on a report card.

So your setup does the whole operation in a single tick? (I've use 'tick' rather than 'frame' because frame rate varies or skips depending on graphics settings.) So that means my old binary counter could ripple through it's update in a single tick too. Although it's max count rate would still be limited to 60acts/s, as far as I understand things, since the input actor can only be hoiked once per tick.

Sort of. The mechanism actually operates in two game ticks, as is easily evidenced from the example animation of the node. One tick is required to pass the hoiking actor to the right and another one to pass the hoiking actor back left. The point is though, that within the game tick that the execution lever is pulled, the entire logic of the tree and the output matrix following it, as well as the state of the display torches and the internal reset of the input hoiking blocks is processed. An additional tick is only needed to ready the mechanism for the next execution.

So it looks like the only hard limit to this in-game computational approach will be dummies...
Unfortunately it is only 100, unless you have a different experience than me (the 101st dummy had no soul).

I had originally written 100 dummies, but a conflict of statements between z26 and you in the Faster Memory thread lead me to change it to 200. If I had wanted to know, I should have probably tested this myself. I will amend the OP to 100.

100 ghosts is indeed not many if you use them promiscuously. In the build above, over half of the dummies are used in the output matrix on the right, which was necessary since the input/output wires to each of the digits is same colour (red). You could, instead, send out the results via short 4-step hoik tracks, similarly to as how Joe did in his original build. This would translate to a tick per bit. However, I wanted to prove being able execute the mechanism in a single tick. Incidentally, if you made this modification, the gate would be Terraria 1.2 viable, since the number of required hoiking actors (six) would be below the skeleton spawn cap.

So, as powerful as the above method is (it needs a name), you have to weigh in the benefits of speed it provides against the number of dummy ghosts you are sacrificing in its use. I wouldn't use the above mechanism, for example, in creating a calculator. Joe has identified the shifter as a bigger source of latency. Maybe it will be useful there?

 

[DicemanX]

Yes, but as far as I know you can't despawn them without breaking the dummy stand, which you could do by actuating the blocks underneath, but it's a one time thing. You'll probably have to juggle the same set of 100 dummies; keep recycling them, while keeping them in order and such. Should be fairly do-able. Even if you did lump them all together for some reason, you can 'deal them out' again by feeding them through one of my old launcher mechanisms (since they launch in priority order when the first actor out de-actuates the tooth that kicked it).

Yes, recycling the dummies for use in other mechanisms is a solution, but only if we get more wire colors. I'm in the middle of constructing a simple calculator with decimal inputs and outputs and just an addition function so far, and the thing uses about 72 dummies because of wire limits - I simply cannot reach certain existing dummies with wires from pressure plates.

Of course we could just request more dummy souls for the 1.3.1 update...

 

[ZeroGravitas]

within the game tick that the execution lever is pulled, the entire logic of the tree and the output matrix following it, as well as the state of the display torches and the internal reset of the input hoiking blocks is processed. An additional tick is only needed to ready the mechanism for the next execution.

So 1 tick execution time, 1 tick refractory period. 30 calculations per second is still pretty high for an in-game machine, heh. It also shifts the wiring paradigm subtly towards being synchonous, don't you think? (Provided gates are chained in dummy priority order.)

we could just request more dummy souls for the 1.3.1 update...

I'm sure you'll figure something out... (But you're also free to ask , although it seems a little heavy handed.)

dropping them off of the bottom of the world

Very clever thinking. I can almost imagine this working.... slowly (if they have to fall 10000 tiles at 51mph?). Obviously the screen bounds stopping player don't stop regular mobs (or statue mobs, presumably). But they must surely be stopped by the hard limit of the real edge of the world file's dimensions (not much further below). Otherwise it would surely just crash the game? What happens to town NPCs (where do their face icons show up, etc)? [Edit: weirdly coincidental note.]

 

[inomanoms]

The following is an example of how the Add 3 function of Joe's calculator could be combined with the Shifter to the effect of reduced latency:

​

How it works:

Shifter and Add3 function work in tandem in a 4 tick cycle. The colours of the flow chart represent actions that occur within the same game frame. The mechanism starts on green with the right-most dummy of the binary digits. At the end of the first shift of the digits through the a block of BCD, the add 3 function to that BCD block is engaged. For the Add 3 function to be able to supply inputs in the same game tick as the Shifter uses them to shift left, it is imperative that the action order of the dummies is correctly defined. Shifter dummies are of first tier action order with dummies to the right having precedence over those to the left. Add 3 dummies are of second tier action order, dummy priority left to right. I haven't thought through how you would stop this thing. Once started, it just "runs" like a motor.

This build underscores the point I made earlier to Joe in PM about how uniform execution times are key to reducing latency by providing a means to orchestrate the synchronous execution of different parts of a mechanism (I hope I use the term synchronous correctly here, @ZeroGravitas) without the need for any ready signals between those parts of the mechanism. The development of my type 3 hoiking node as presented above is the gateway to synchronous behavior since now any logic gate that would otherwise be executed in varying amounts of ticks (due to missing or abridged logic tree branches) can be reduced to single tick execution. It also provides for a general design principle: create functions single tick with C(aptive) A(ctor) S(ingalling) nodes. In the interest of dummy economy, iterate these functions with T(ele-) H(oiking) A(ctor) nodes.

We had this argument before @DicemanX, but I feel the last step to--not reducing latency but to--better maintain our supply of hoiking actors is to know how to formulate reoccurring functions recursively. When you define functions single tick, that's a lot of dummies wasted if you tie a copy of that function to every input iteration of its use.

 

[DicemanX]

This is definitely the next step in our progression towards reduced latency - concurrent instead of sequential operations. There are still some pontentially difficult problems to solve with the converter:

1) The last step of the conversion would have to be the left shift alone, without the +3 function at each BCD storage unit. This would mean having to somehow "decouple" the shifter from the +3 function and shut down the +3 function while the shift occurs one last time. Not sure yet how this can be done effectively.
2) The converter cycles N times, and N corresponds to the number of bits in binary storage (9 bits in the example above). A separate component has to give instructions to the shifter how many cycles need to be completed.

We can probably address both of these issues by having two separate counters - one for the shifter and one for the +3 function (the counter dictates how many times an action will be repeated). Set the count for the shifter at N, and set the count for the +3 function at N-1. Should be doable unless the 3 wire color limit creates a major obstacle.

It'll be interesting if this can be hooked up to the other components in the entire mechanism. I hope we have enough wire colors to do it! I'm currently hooking everything up with the initially-designed sequential converter to see if I can make it all work, and then we can focus on whether it's feasible to run concurrent operations instead. The entire set-up couples the decimal input machine to the BCD-to-binary converter to the ripple carry adder to the binary-to-BCD converter to a BCD-to-decimal converter.