BG1, PRELOAD BG2, PRELOAD

Logic Blog

Waste Not, Want Not: Part 2

Rating: 3 votes, 5.00 average.
Waste Not, Want Not:
Resource Sharing for Thermofficiency!


- Part 2 -



1. Input Sharing

This week is going to be all about shared inputs in logic networks. It's a really useful technique and has the potential to save a fair bit of thermo in the right circumstances. The idea is that often a signal in a logic network will input to multiple devices. In this case, it can be beneficial to construct our logic in such a way that we use this to our advantage.

One thing to note is that the "inputs" in this case don't have to be the inputs to the network. They are the inputs to individual switches within the network, so could be signals in the middle of your logic network, coming from other logic devices (i.e the output signal of one device becomes the input signal of multiple other devices).





------------------------------------------------------------------------------------------------------



2. Input Sharing with AND and OR Gates

Often, you will find yourself having need for a variety of devices that all share a common input. Often this could be a "player is in a certain area", or an "enable" type signal, but I'll just deal with it in an abstract manner for now.

2.1. Basic Input Sharing
The following is an example of three logical functions that share a common input (s):

a•s (a AND s)
b+s (b OR s)
c•s (c AND s)


If we build some basic, piston-driven, switches for this, we can see that the s signals all move together. As demonstrated by the logic system on the right, sharing that input by having a single moving part with a magnetic key on it is more efficient:



In this case, the way I laid out the logic makes it easy to see that this can be done, in reality it's often less obvious that you have an input that could be reused. The trick, as with all of these techniques, is spotting opportunities to use it when creating your logic for real.


2.2. Comparison with Winch Logic
If we make the same functions with 3 winch-based devices, then we can do a quick comparison of efficiency and decide which is "best":



Note the use of a shared magnetic magnetic key technique, from last week.

Code:
.
  Component     |  Shared Input  |  Winch  |
----------------|----------------|---------|
  Objects       |        5       |    4    |  
  Moving Parts  |        4       |    3    |
  Mag Switches  |        3       |    3    |
  Mag Keys      |        1       |    1    |
  Connectors    |        4       |    6    |
--------------------------------------------
.

As you can see, the component counts work out so that the winches method has less moving parts, but the shared inputs method uses less collected objects. Due to the fact that we have multiple separate thermos, whatever is "best" will depend on what level you are creating and what resources you are likely to need elsewhere. For example, my current project is going to annihilate collected objects thermo before anything else, and I have to copy the logic systems many times. In that case, saving the connectors at the expense of a moving part is clearly preferable.

Often it's not a clear cut as that though, but knowing multiple techniques that optimise thermo in different ways is always a bonus. If you aren’t sure what your level’s requirements are going to be, you could always just alternate techniques you use through the level as resource levelling exercise. The best way to get the most out of the thermo is to max out as many different thermos as possible!

Something else to note here is that if you are sharing inputs between n switches, the rise in moving parts is always 1, the rise in connectors will be (n-1). So the more sharing you can do on that one signal, the more thermo you can save by not using winches and so the more likely that will be the preferable route.





------------------------------------------------------------------------------------------------------



3. Sharing Inputs with XORs

The example above kind of saves us thermo, but because of the efficiency of winch ANDs and ORs it's a bit iffy. There are a few examples where such techniques will always save us thermo and one of those is the XOR.

Spoiler Spoiler - geekNotes: On the XOR Function


I make my XORs like the image below and I currently have no design that is more efficient (if anyone does, then feel free to wing it my way ):



If we had multiple XORs sharing an input, then we could put a magnetic key on the shared input and magnetic switches on the non-shared inputs. This is scalable to (pretty much) as many as you like, such as the example below of 8 XORs all sharing a input signal (useful if you want to conditionally invert a whole bank of signals):

a s (a XOR s)
a s (a XOR s)
....
h s (h XOR s)


Again, we configure the logic so that the magnetic key is on the shared input and we get the following:




3.2. XORs Sharing with Other Devices
Of course, you don't have to share between XORs and other XORs. You will also find that sharing an input between an XOR and a number of AND / OR gates will also save thermo against using a winch-based OR. Consider the following:

a s (a XOR s)
b • s (b AND s)


We have a 2 input AND and a 2 input XOR. Below is the shared input configuration for this:



It should be clear that this saves resources over the alternative of a separate XOR and a winch-based AND.

Spoiler Spoiler - geekNotes: On Human Error






------------------------------------------------------------------------------------------------------



4. Sharing inputs with Inversion:

Another configuration where we can definitely save thermo is using ANDs and ORs with inversion. I've actually got a practical example of this one: in Setbacks, when you get to the elevator and use the console, a magic mouth tells you you need to turn on the generator. Once you have activated the generator, you come back and the console initiates the elevator movement. This is quite a common gameplay device IMO and also a very nice little example. Using the symbols c (for console) and g (for generator on), we have the following logic system to design:

(c • !g) -> mouth
(c • g) -> elevator


We can share c quite easily, as before, but that g is harder to share, because in one case we need to invert the piston, so we would end up treating g and !g as different signals, within the switch:



An alternative to this is to create a weird perpendicular configuration of an AND gate. In the animation below, c is moving vertically and g is moving horizontally. If c is FALSE, then both of the magnetic switches will be FALSE. When c becomes TRUE, one of the magnetic switches will become TRUE, depending on the value of g.



It should be clear from inspection that, in this case, the collected objects and connectors thermos are reduced vs a winch-based design (two winch ANDs) and all else is equal. Personally I find this one very useful - it's a common thing I'd use in actual gameplay logic, even if it is normally for magic mouths and camera control.

Of course this could be used with ORs, or if you are careful with your inversions, any combination of ANDs / ORs / NANDs / NORs on the two signals and their inverses.





------------------------------------------------------------------------------------------------------



5. Summary

So that's input sharing. This is far from an exhaustive list of where it can be applied, just a subset of the possible scenarios that I thought were most likely to come up / easy to demonstrate. It's far less easy to implement than the ideas from last week as you have to really make decisions on when it's applicable / useful within your own levels.

5.1. The downsides:
The more savvy amongst you will have noticed that some of these techniques are impossible (or nearly impossible) to use together. I'd love to be able to just give you a run down of rules to follow that would automatically turn your logic networks into optimal designs, but I can't One thing to bear in mind is that having the absolutely bestest design ever is not entirely needed. Simply by incorporating more techniques into your existing repertoire will give you more options and that alone will lead to more thermo-efficient designs.

There is one time where getting the absolute lowest thermo design is important: When the logic must be duplicated many times. Saving one winch on a logic system is nothing major - probably not worth the time for a rebuild from the ground up. Saving one winch in a logic system that you are going to use 20 times probably is.


5.2. Next Week:
Next week might be a stretch for me I'm afraid. Things look busy and I have none of the blog exists outside of my head yet So expect the next installment shortly after Christmas.

The next blog will be wrapping up this "Waste Not, Want Not" with some really big thermo savers. For example I'll be showing you how to make an AND gate that has no magnetic components and an OR gate that uses negative thermo. Yeah, you heard right! Intrigued?

OK, so calling the OR gate "negative thermo" might be a little bit misleading, but it's still darn cool


.

Updated 12-18-2009 at 11:44 AM by rtm223

Categories
Logic Blog

Comments

  1. comphermc's Avatar
    Thanks, rtm. Great read, as usual. I honestly haven't done much work with resource sharing, since the idea of putting the switches on the moving parts is new to me. Very useful!

    And I am very intrigued. Color me interested (I think that's close to Cyan, but I'm not sure. Either way, I prefer crayon).
  2. rtm223's Avatar
    If we're talking crayons, it's somewhere near Jazzberry Jam, with a hint of Razzmatazz. God I love wikipedia.

    Crayola Colours




    .
  3. Rogar's Avatar
    Cool wobble tech!
  4. rtm223's Avatar
    Yeah I don't use Wobble Bolts very often - not for particular technical reasons - I just don't like 'em much. But sometimes rotational movement has distinct advantages over linear.
  5. Coxy224's Avatar
    Holy Logical Craziness Batman!!
  6. rtm223's Avatar
    I'm gonna go ahead and assume that was a compliment coxy
  7. Tamland's Avatar
    Nice blog post!!
    Some pretty good info there!

    My XORs are very similar, the only difference is that i don't invert my magnetic-key-swith. I invert one of the pistons instead.. I like it when the outputs are TRUE when activated.

    A question: The 8 XOR that's in your post, wouldn't you need an 8x OR to control the mag key?
    Or is it something I'm missing?
  8. rtm223's Avatar
    No, the magnetic key is driven by s - the shared input. That could be anything.

    The only proper example I have is an adder subtracter, where all bits of the second operand are inverted when subtract is selected.

    Think of the [b]s[/s] as a control signal that inverts all the other signals if it is asserted.
  9. Thegide's Avatar
    Yes, and now it's glaringly obvious just how much I need to scrap my old logic gates.

    Excellent read, thanks!
  10. rtm223's Avatar
    I wouldn't do that just yet. Most logic switch designs, even the inefficient ones, can find a place in an implied logic system (as per the new blog)