Logic Blog

Analogue Logic 1 - Fundamentals

Rating: 9 votes, 5.00 average.
Ana.logue Signal Processing
Binary's for n00bs foo'!!!

Part 1 - Concepts and Fundamentals

I’ve decided to kick off Logic Blog 2.0 with our first steps into the world of analogue (or ana.logue in-game because yes, sensible words are still filtered in LBP2, *sigh*) logic. Analogue signal processing is the non-obvious side of LBP2 logic and whilst most creators with some experience with LBP1 logic are going to be comfortable with the digital side of things (basic AND, OR operations, switching things on and off, etc), the analogue system is liable to pass many people by as it’s largely hidden from the user. It’s also very, very powerful.

In LBP1 we didn’t really have that much use for analogue signal manipulation and the tools that were available weren’t very suited to the jobs of producing analogue signals or doing anything much interesting with them, we mostly stuck to boolean operations, except for basic things like gradually increasing the speed of a bolt and very occasionally something a little more complex.

However, now we have movers and rotators and hologram etc., that respond very well to analogue controls for quite subtle effects and also we have processing devices that allow us to do some very interesting operations on these signals and opens up a wide range of tuning and refinement that would be impossible, or at least prohibitively complex, with digital systems. Analogue processing is also where you will find some very subtle effects beyond the boring TRUE / FALSE of digital processing.*


1. Introductions to Analogue Signals
We'll begin with an overview of analogue signals in LBP and some terminology definitions:

1.1. Representations of Analogue Signals in LBP2.
For the sake of the logic blog (and probably in general around the forums), you will likely see me referring to the values of analogue signals in LBP2 in the same terms as they are on he battery device: an signed integer between -100% and +100%, though I’ll often miss of the percent signs, because I’m lazy. In actual fact, I’ve found that analogue signals do (or at least can) have a much finer granularity than that. I can successfully differentiate between 99.93% and 100% - and I believe that the actual game granularity is finer still. I'm not sure how much use this would be, though awareness of this fact may be useful for bug fixing.

Spoiler Spoiler - geekNotes: On Analogue / Digital Duality

1.2. Notes on Negativity
In addition, when dealing with negative values (which we will touch on here, but not in great depth) some switches will not cope with negative values in the way you might expect. Typically this involves taking the magnitude of the value only. That is to say that -55% is considered to be the same thing as +55%, when only considering magnitude. Which, obviously, it isn’t and this fact can cause some problems if you aren’t expecting it – especially when you need to keep track of which devices only deal with magnitude and which use the signed value. And to make matters worse, some devices swap between which values they use, depending on how you’ve tweaked them

1.3. Notes on Inversion
Pretty much every device that has an output in this game can have that output inverted (or NOTted if you like). For the most part, an inverted signal will be 100 – s, where s is the normal, uninverted value. This of course makes no sense with negative values of s, as the result would be out of range. It appears that the LBP way to get around it is to treat all analogue values as magnitude, before inversion, so:

   s   | inverted s  
    0  |    100 
  100  |      0 
   35  |     65 
  -35  |     65
  -70  |     30
To avoid confusion, I’ll be using the terms “Negative” and “negation” to refer to changing a value from positive to negative and vice versa, and the term “inverse” and “inversion” to refer to this characteristic of the NOT function in LBP.

Of course nothing is that simple, there is one exception to this rule. The Combiner device, when set to invert output actually gives the negated value (magnitude equal, but sign changed). Therefore an inverted output on a combiner is not the same as running the output through a NOT gate. It's the same as swapping around the inputs, so one really wonders if this is a bug or not (it has been reported).


2. Analogue Signal Sources

This section covers analogue signal sources, which for the most part are very simple, other than the tag and player sensors, which are surprisingly complex. These signal sources will be the initial inputs to your analogue processing system as they don’t have any explicit inputs themselves. Though many of them are sensors that that arguably should be considered to have an input – what I mean is that there is no wire coming in.

2.1. Grab, Impact Water and Sticker Sensors
There is no real sense in having an analogue outputs for these (except maybe water – indicating depth – but then that’s tricky to quantify into a percentage). So they output 100% if the particular conditions of the switch are met, and 0% if they are not.

2.2. Batteries
Batteries will always output the value you set them to, which is an integer between -100% to +100%. This may seem a little pointless, but in analogue signal processing it can often be useful to define offsets and thresholds that are fixed in the system – batteries provide this and they are give convenient system tuning.

2.3. Score and Projectile Sensors and the paintswitch.
The analogue output for these devices can be described as the percentage complete they are. So for the score sensor, the analogue output is:

(target score – current score) / target score

2.4. Player Sensors
Much like when you used to use the sensor switches with speed output in LBP1, the value of the signal from a player sensor is greater the closer the player is to the sensor. It’s quite hard to quantify, as placing sackboy accurately is basically impossible, but it seems that the relationship is roughly linear, except for the fact that there is a smallish area close to the switch that will always give 100%, meaning that you don’t have to be slap bang on top of the sensor for it to read 100%. Of course if the angle is smaller 360 then you will read zero if outside that angle. However, that’s not the whole story, as the player sensor now has a couple of new tweaks, both of which give interesting results if you analyse the analogue outputs.

Firstly, the minimum range tweak, which gives you a dead zone in the centre of the detection area. It should be clear that if you are in the dead zone then the signal output will be 0. However, on the edge of the dead zone, the analogue signal outputs 100%, so the scale is modified to accommodate for this. In addition, you also lose the 100% zone on the sensor if your minimum radius is greater than zero. As this is a bit confusing, I made a graph to demonstrate both the effects of the 100% zone and the size of the deadzone on the signal value:

fig 2.4.1. The Effect of Minimum Radius on Player Sensor Outputs

Secondly, there is the new “Number of Players Required” tweak. Obviously, if you don’t have the correct number of players in the sensor area, then output is zero, however, if you do have the right number of players (or more), it bases the value on the distance of the nth player. So if you select “require 2” on the sensor, it will tell you the distance to the second closest sackboy. Which is nice.

2.5. Tag Sensors
These work in almost the same way as the player sensors do, with 100% zones and dead zones, with detection of the nth closest matching tag (remembering that tag labels exist, so if labels do not match, neither do the tags). The tag sensor also has one other useful tweak, Output Value. The default, “closeness” will output a value similar to the graph in fig 2.4.1., whereas “signal strength” will output the value of the signal that is input to the tag - including the sign.

This means that it is possible to wirelessly transmit analogue values in the full range (+/- 100%) by simply using a tag and sensor. which is quite a significant feature when you remember that emitted objects cannot be wired to anything that is not emitted with them.

Apologies for the misinformation in the original text, it seems I didn't do my research well enough on this particular aspect. Thanks to Rogar for pointing out my failures. What can I say, I am only human, despite what you may have heard rumoured....


3. Analogue Signal Processing
Following on from analogue signal sources are the devices that are used to do the processing. Some of these aren't actually analogue processors, as they can't utilise analogue inputs and I suppose if used in an analogue system they are sources, but I've split it this way because it seemed like a good idea at the time and renumbering sections is a pain. Deal with it.

3.1.Toggles, Randomisers and Select Switches
These have no concept of analogue input and will only respond to the digital aspect of the input signal(s). The outputs do have an analogue component, however this will take a value at 0% or 100%, nothing in between.

3.2. Counters
The counter, like the devices above, doesn’t have an concept of analogue inputs, however, as with the projectile sensors etc. its analogue output is the ratio of maximum value to current value. This makes the counter (amongst other things) a very useful tool for debugging analogue signal processors – much like the battery allows easy tuning through tweak settings, the counter allows quick modification of test data from a Controlinator test harness (I am now almost exclusively using Controlinators for component - level testing in LBP2). It's also quite useful if you wish to adjust offsets and thresholds to modify your system at runtime - for example, to modify difficulty automatically each time the player fails, or to increase difficulty as you go up a level.

3.3. ANDs ORs XORs and NOTs
These are our basic digital processing components, but they also have analogue processing abilities that are likely to be rather unexpected. The NOT simply passes the signal through, inverting it if required (remembering the inability to invert negatives above), but the others have some interesting properties when you look at the analogue component of their outputs.

The AND gate is effectively a min() function - it’s output is equal to the smallest value input. So for signals of 10, 63 and 42, the output would be 10. To compliment this, the OR gate is a max() function, so the output value from the same three signals would be 63. Note that these definitions make sense in terms of using binary (0 / 1) inputs for the same gates, which is probably why this happened.

Spoiler Spoiler - geekNotes: on Handling of Negative Values

The XOR is a strange beast and seems to do something along the lines of a max() function on the analogue inputs, but then combines this with it’s binary output. Which means that to understand the complete behaviour you have to keep track of both analogue and digital inputs, which as described in the geekNotes above, and as we will find out at a later date when we dig deeper into the duality of signals, are generally divergent if any processing has been carried out on them. I’m sure we can utilise this to our advantage at some point but for now I’m struggling to find genuine uses and I don’t like it, so we shall move swiftly onto something I do like:

3.4. Combiners and Splitters
The Combiner works out as a simple subtraction device and output is equal to the difference between the two inputs. It’s definitely worth noting that the inputs on these are taken to be magnitude only so you can’t use negative numbers within a subtraction and achieve the correct arithmetic result. The output can be negative and will be arithmetically correct, assuming that both inputs are positive. This might be a bit confusing, so here are some examples:

     Inputs   | Correct | Combiner
   +   |   _  | Answer  | Output
  100  |   35 |    65   |    65
   50  |   65 |   -15   |   -15
   50  |  -10 |    60   |    40
  -50  |   30 |   -80   |    20
When including negative values in the subtraction, as either operand, the result is incorrect. 50 – (-10) should give 60, however the actual calculation performed is 50 – 10, to give 40.

The splitter is pretty simple – if the input is negative it outputs the magnitude of the signal through the negative output, if the signal is positive then it outputs the magnitude through the positive output. In both cases the signal output is a positive value. Splitting signals is very useful given the caveats associated with manipulating negative values and can also be used for simple things like checking "is this signal positive or negative?".

3.5. Timer
If any device is the king of analogue processing, it’s the timer. Simple enough to just trigger an event every few seconds, yet powerful enough to be used at the core of a data storage device or even integration (yes, LBP2 has calculus) of analogue signals against time and a whole bunch of stuff in between. It can also be quite neatly geared up as a signal source, to produce periodic waveforms (natively triangle and sawtooth, but with a couple of bits of extra logic, square waves, trapezoids and possibly sine and cosine – though I’ve not quite got as far as achieving true sine and cosine yet, but I think I know how).

The output of the timer is, much like some of the other tools, the ratio of max value to current value. However, in addition to binary inputs (of which there are a few nice things such as “start counting up / down” and “forwards / backwards”) the timer also has a speed setting, which is fantastic. Basically, if you put a 50% analogue signal into a timer with speed inputs, then the timer will fill up half as fast as normal, change it to 25% and the rate of change halves again, drop it to 0% and it stops. But this also works for negative values as well, and a negative input will reduce the value of the timer, at a rate proportional to the input value.

3.6. Sequencers
I’m not actually going to go into the usage of sequencers here, I'll save that for a later date, as they has a very specific and unique role in the world of analogue signal processing, when we get around to turning it from a technical curiosity into a powerful decision-making tool.


4. A "Simple" Example

So far, all we've done is look at the basic tools and their functions and it doesn't seem like much could be done with them - really we've only got a few sensors to detect the state of the world, and a few basic operations we can carry out and that's all there is to our analogue toolset... But when you think about it, this is actually more functionality than the individual components we used to use for logic in the old game and look what we achieved with that.

Next instalment I'll actually put together a couple of neat microchips that will allow us to expand this toolset with more functions, but as this is a bit long and technical so far, I don't want to do any in-depth examples, so I'll finish off with a simple waveform manipulation circuit I dreamt up, which is shown below (click for higher res):

fig 4.0.1. Wavform Filtering Circuit

4.1. Signal sources
In this case, we're using the timer (labelled 1 in fig 4.0.1) and some batteries (2, 4, 6) as the signal sources. The timer is configured with the following settings:

Target Time: 2s (note, this is arbitrary)
Input Action: Forwards / Backwards
Invert Output: Yes

This set-up will produce a triangle wave, as looping the inverted output back to the forwards/backwards input causes the timer to fill up linearly, then empty linearly, then repeat. I don't want to go too much into exactly why this is, but that is what it does, as per the graph below:

fig 4.1.1. Triangle Wave (System Input)

Note that the period of the signal is twice the Target Time setting (as the timer must fill up for 2 seconds and then empty for 2 seconds).

4.2. Signal Limiting
As discussed above, some of the simplest operations we can do on analogue signals is min() and max(), using ANDs and ORs. We can use this to achieve some boundary limiting on the signal, preventing the signal going above 80% or below 20%.

So taking the output of the timer and using an OR gate (labelled 3) with a battery (2) set to output constant 20% will give us a max function, which leads to a lower boundary. To clarify: if the timer output is greater than 20, the output of the OR gate is equal to the timer, but if the timer drops below 20, then the OR gate will output 20.

After this we do the same thing with an AND gate (5) to do a min() with an 80% battery (4), to give an upper limit, and the resulting output of the AND gate is shown below (with the original wave in dotted lines). You can see that the timer's output is ignored when it exceeds the minimum and maximum bounds that we have set for it:

fig 4.2.1. Trapezoid Waveform (triangle with boundary limiting)

Conceptually it is a little confusing that we use a min() function to create a maximum value, but that is the way of the world, I'm afraid - it's certainly not my fault!

4.3. Removing the DC Offset
Sometimes, especially with waveforms, it's useful to have them centred around 0, and to do this we need to shift the whole wave down by 50 (the point at which it is currently centred - its average value). This is a simple subtraction operation using a combiner (7) and a battery set to 50% (6) and results are as shown:

fig 4.3.1. Trapezoid Waveform with DC component removed

4.6. Extending the concept
The advantage of centring the signal around zero is that over time, the value averages to zero - if you were to put that signal into a mover, it would move forwards a bit, then backwards a bit, then repeat, but it wouldn't drift from its original location. The same is true if you put the signal into a timer with speed input.

The timer with speed input actually works out as being an integration of the input signal against time. I'm not going to explain why - those of you with enough calculus to understand why can probably work it out on your own. One reason integration is good is that it can quite often give us curvy waveforms, and curvy is nice, for all manner of reasons

Integrating our trapezoidal waveform (fig 4.3.1) actually turns out to be a rough approximation of a sine wave, as shown below:

fig 4.3.1. Trapezoid Waveform Integrated to Approximate Sine

Note: This is only an approximation of a sine wave, I think it's possible to produce completely accurate sine and cosine signals, in the range -100% to 100%, but I haven't tried out that mechanism yet as it's a weird complex loopback system, that makes my head hurt to think about it.

To achieve this result I have actually fed the signal into timer starting at 50% and then deducted 50% from the output value, to recentre the signal around zero. This is shown below as an extension of the original image (components 8 and 9 provide this extra processing - the 50% battery at 6 is reused as shown):

fig 4.4.1. Extended Waveform Filtering Circuit

Spoiler Spoiler - geekNotes: More on Analogue / Digital Duality


5. Summary

So, this was an overview of the basics of analogue processing, and whilst the end bit of that example may have seemed a little unbasic (that's a word, right?), all I've done is some of the standard analogue processing tools. The logic network in question has 9 components in it, and most of those were humble batteries. If we can transform a triangle wave into a sine wave using only 9 components, this should highlight how powerful this analogue signal processing is.

Obviously, generating a sine wave is not the most practical of examples and I'm sure for many of you, periodic waveform manipulation is not the first thing you think of when considering useful gameplay logic. But it's worth noting that there are entire fields of engineering that rely upon waveform manipulation to keep our lives ticking along in the cushty way that they do, so don't be turning your nose up at the lovely, lovely sine waves

Anyways, the logic blog has always been about technique and methodology, expanding or improving the toolsets available in an application agnostic manner. The little bits of signal limiting and subtraction presented here are useful techniques to know and will lead onto many applications once you become comfortable with solving problems in an analogue manner.

I'm not entirely sure what I'm doing next time, but it's likely to be some extensions of this analogue signal processing, including addition and signal sampling. Hopefully, for all our sakes, it'll work out a little shorter than this one.

*Note to Digital Systems: I didn't mean what I said there, I still love you

LBP2, at time of writing, is still in beta and it's possible that some of the techniques described here will not work 100% in the final release, and so any of this information is subject to change.


Updated 10-06-2010 at 08:51 PM by rtm223

Logic Blog


Page 1 of 3 1 2 3 LastLast
  1. Fishrock123's Avatar
    Wow that's long! Well, time to start reading. *concentrates*

    Ah! Why cant the beta come sooner! (I think I comprehended everything except the negatives thing..)

    Speed based logic (LBP1) logic has always clicked with me. So I can't wait to experiment with this stuff!

    Say.. I can imagine some platforming elements that could use this.
    Updated 10-06-2010 at 12:22 AM by Fishrock123
  2. rtm223's Avatar
    Yes it is long, waay longer than I intended and so I apologise. I did add some extra just now though, to the final geekNotes about the binary signals being garbage:

    "Also, when designing analogue systems, the wires are not your friend. If you've played the game or studied any videos closely, then you may have noticed that the wires light up as the signals active within them. Well, irritatingly, these visual effects are only a representation of the binary signals, which we know are garbage in your analogue device and it's actually quite hard to ignore them when you are debugging."

    The negatives thing is a pain to explain, but it becomes quite apparent when you see it. An example from LBP1 might help out here.

    If you use the three way switch set to speed and wire it into a motor bolt and a piston, you will see the bolt change from +100% speed to -100% speed, whereas the piston will go from +100% speed, down to 0, then back up to +100% again.
  3. Fishrock123's Avatar
    Pssssh....Your underestimating me!

    I get the problems with negatives, but not the conversions.

    Also, your blog was to short.

    no. rlly, I'm serious, it was. I could spend all day reading this stuff!
    Updated 10-06-2010 at 02:00 AM by Fishrock123
  4. rtm223's Avatar
    Oh ok, sorry, I'm not 100% sure what you mean, can you just copy and paste the passage you want clarifying and I'll do my best. In fairness, some of the stuff in here I'm struggling to find the words to explain the concepts coherently.

    And really, I could spend all day researching and writing this stuff, at least at the moment when it's all so new and there is so much to find out.... Sadly, it doesn't pay the bills as well as proper work
  5. Syroc's Avatar
    Logic, what is it good for?

    Seriously though what can you do with this in particular?
  6. Fishrock123's Avatar
    Quote Originally Posted by rtm223
    Oh ok, sorry, I'm not 100% sure what you mean, can you just copy and paste the passage you want clarifying and I'll do my best. In fairness, some of the stuff in here I'm struggling to find the words to explain the concepts coherently.

    And really, I could spend all day researching and writing this stuff, at least at the moment when it's all so new and there is so much to find out.... Sadly, it doesn't pay the bills as well as proper work
    I say we hire rtm. XD

    I just don't *fully* get the entire magnitude signal vs negative signal/etc thing. Atleast not on paper.
    Should make more sence when I actually get using it.

    I can see myself getting stuck a few times trying to use combiners with negatives. (then again, it could be useful at some point.)

    @syroc I think it has it's biggest use in lighting/sound, but I can see some platformy stuff using movers as possible.
  7. comphermc's Avatar
    Thumping good read. I haven't had time to play with any of the an.alogue signals yet as they pertain to using the [assumed] digital logic components, but now I don't need to! Well, I still will anyways, it's just nice to have a basis for why this stuff is behaving the way that it does.

    I was lost a bit on the integration as per your description, but seeing the picture, it now makes sense. Simple time derivatives/integrals, and all that, for the win.

    Thanks for the efforts. I will need to go back and look over the combiners step, as I feel that one might be on the midterm.

  8. Rogar's Avatar
    Useful stuff, you saved me a lot of testing!

    A few things I noticed: You say tag sensors set to output signal strength just output 100%. But actually they output the analogue value of the input signal of the tag, if the digital counterpart of the input signal is on/true.

    And surely the min of 100 and 35 is 35, and the max is 100, are they not?
  9. rtm223's Avatar
    Fixed the max and min issue and I'll check that thing with the tag sensors, which if it's true is absolutely awesome - means wireless transmission of analogue values is a piece of cake and it also explains why it's the only switch to have this feature and why the naming doesn't make any sense - It's all so obvious now
  10. Fishrock123's Avatar
    If that tag thing is true....
  11. Rogar's Avatar
    It is, I use it in my tractor beam logic. You may have noticed I asked on the beta forum how to compare two speed inputs, so I could stop an object at the same distance as a previous object. Well, one of those speed inputs was the tag strength from the previous object, coming through a tag sensor. You can pry the logic from the portable tractor beam I give away in the level (BCC02 - Flying Saucer with Tractor Beam), if you want to have a look.
  12. rtm223's Avatar
    Yeah I believed you rogar, I just like to verify everything myself if it's to go in the logic blog. I guess I never actually got around to testing the analogue signal into tag.

    But it's verified now and it works, it even encodes negative values properly
  13. Fishrock123's Avatar

    I'm not in the beta! /ihasasad

    Could you please get some one to video it in play+/create?
    Updated 10-06-2010 at 08:34 PM by Fishrock123
  14. mattman111's Avatar
    Why exactly MM hasnt hired you from the community still blows my mind. You seem like a born pro- Logicgrammer
  15. napero7's Avatar
    I actually understood pretty much all of this, yay.
    Maybe because I played around with almost the exact same things today (without the geeky stuff, jus seeing how stuff works)
    Thanks for this, made me understand this stuff better.
    For your next blog, try to figure how to change the pitch and volume of a sound effect at the same time

    EDIT: Oh btw, is it possible to set the score sensor to a target score of 0? Because in that case we might have a problem
    (target score – current score) / target score
  16. comphermc's Avatar
    Napero, I can imagine that it's possible, in which case there would just be a "check" in the logic within LBP2's code along the lines of:

    If score is zero --> 0
    Else Use the expression [that rtm posted].

    Yeah, I don't do coding, I just get the logic of it. Get off my back!
  17. napero7's Avatar
    Yeah lol, I didn't really say that too seriously, because there can't even be any percentage with the score set to 0
    But it would be cool to have some epic explosions in create mode if you did that and a flashing red text "you divided by zero" and then Stephen Fry saying "Oh nooooo what have you done!?!?!?"
  18. Ragnarok's Avatar
    Wow, this is really incredible, going a bit off topic, the inclusion of logic gates to lbp will open a lot of opportunities to not only good creators but programmers as well, reminds me a bit of C# programming or Q-Basic (even if I have only used it very briefly), maybe some programs, with a bit of practice could be replicated on lbp2, Ive always wandered if it could be possible to make a word processing software in lbp, (I could start from the 8 digit binary as a start!, but that would take too much time, this would involve passing data into an output to be displayed which in theory could be made through the use of holograms)
    Updated 10-07-2010 at 06:55 PM by Ragnarok
  19. rtm223's Avatar
    well, with regards to basic programming, I've created something approximating a while() loop for processing ordered actions in a sequencer (pretty simple really - just reset the sequencer at a given moment in the sequence if a condition is met.

    I don't really tend to see logic gates as being particularly akin to programming though, and I still don't consider real-world electronics as a particularly good analogy for LBP logic - despite the new kit being named "electronics".

    As for word processing software, you could put something basic together in LBP1. In LBP2 you could easily set a up a physical model, that would be far more effective and efficient than dropping into binary encoding of characters.
  20. Ragnarok's Avatar
    lol yeah, but i was just trying to encompass the whole power of lbp that is enough in theory to create a operative system, or programs from scratch using a binary system (after all, almost all computing is based on the binary isn't it?), and about logic gates, well it opens a lot of different choices, the IF or NOT, if used correctly can pretty much make almost anything, (I don't remember the other commands! its been like 2 years since i took a C# programming class, hopefully ill re-study all that when I take C++ programming next year! ), this is the great wonder about lbp, its amusing for all, from artists to programmers! its really very versatile.
Page 1 of 3 1 2 3 LastLast