Archive: 14 posts

---

So we can easily compare an 'analogue' signal to a threshold using the sequencer. But the sequencer output is delayed by one frame (1/30s). Is there another way that yields an instantaneous response?

2011-03-04 10:02:00 Author: tameturtle Posts: 150

---

There doesn't seem to be any way. Out of curiousity, what is the application that can't suffer a single frame of delay? If the issue is a race condition (i.e. the comparator output needs to combined with some other signal that is not delayed), then you can simply delay the other signal too. IMO, it's rare that a single frame on final response will impact your performance in a significant way.

2011-03-04 10:29:00 Author: rtm223 Posts: 6497

---

Thanks for the reply! There currently are two applications in development here that would benefit from reduced comparison latency. One is in direct reaction to player input, where of course a more immediate response is always welcome. The other is a movement detection device which compares the current distance to a tag to the one the frame before. (The latter is used in a weight-measuring device. It tries to lift an object repeatedly and adjusts the lifting force based on whether the object could be moved or not. At the moment it takes thirty tries to complete a measurement - one extra frame per try means the complete run takes a full second longer. In addition and more importantly, canceling the lifting operation as soon as movement has been detected means reduced rebound force when the object returns to its rest position, thereby reducing the risk of bouncing that would be detrimental to the measurement accuracy.) Now if you say you don't see a way to do it, I am pretty certain there isn't one. Cheers!

2011-03-04 10:59:00 Author: tameturtle Posts: 150

---

Is there another way that yields an instantaneous response? I was playing with this the other day with Shadowriver, and he came up with a rather ingenious solution, albeit a little strange. If you place a Controlinator on a Sackbot's 'brain', you're able to attach wires to the button inputs, and if you feed a wire into either of the two large shoulder buttons (L2 or R2) the digital output from the same button will be +1 if, and only if, the analog signal is greater than zero. The digital component of the input signal is ignored, and the analog value passes through unaffected. So you should easily be able to combine this with a Direction Combiner to do zero-latency thresholding. Just a shame you need a Sackbot for this to work. :/

2011-03-05 23:20:00 Author: Aya042 Posts: 2870

---

Just a shame you need a Sackbot for this to work. :/ You only need a sackbot to set it up. Wire your whatever into the controllinator's inputs while it's on the bot and then when you remove it from the bot, they'll still be wired.

2011-03-05 23:44:00 Author: Sehven Posts: 2188

---

You only need a sackbot to set it up. Wire your whatever into the controllinator's inputs while it's on the bot and then when you remove it from the bot, they'll still be wired. Awesome stuff - had no idea this worked. Weird thing is, I'm sure I tested this in the beta, and you always lost the connection. Is that something which has changed since then, or is my memory just unreliable?

2011-03-06 00:09:00 Author: Aya042 Posts: 2870

---

Dunno. I happened to be sitting in front of the editor when I read your post so I tried it and it worked. I did a quick test with a battery and a light set to dimmer to confirm that the signal was actually getting through the button alright and it worked just fine. I don't know if it matters, but my experiment had the battery on the controllinator's circuit board--that might be significant, but I can't say for sure 'cuz I didn't try with the battery elsewhere.

2011-03-06 01:10:00 Author: Sehven Posts: 2188

---

Sadly transferring controllinator from sackbots chip will remove wire connection. I just tested it and it will remove it even if you capture it.

2011-03-06 10:24:00 Author: waD_Delma Posts: 282

---

Thanks a bunch, that helps ... somewhat Quick setup to test the switching latency: http://i9.lbp.me/img/ft/229cca89ae1c71fb61607ecfc98823a482a85b79.jpg The timer is set to speed scale and connected to a 0-output battery so it produces a constant 50% / digital zero signal. The controlinator is wired L2 button in, L2 out. The 'XOR' makes sure that if the toggle differs from the controlinator output the audio object is triggered (to make it easier to perceive than a single-frame flash of a wire/tag). And indeed, there is no latency when turning the toggle on. But turning it back off results in a beep, so there's at least one frame of latency before the controlinator switch returns to zero. Unfortunately, copying the entire circuit to a clean microchip causes the controlinator input connections to be cut for me as well. Still happy to have this method at my disposal, cheers again.

2011-03-06 10:25:00 Author: tameturtle Posts: 150

---

Hi guys, I just joined because of this fascinating, maddening topic! As rtm pointed out, there might not usually be a huge practical need for zero-latency ADC, but just knowing it was seemingly impossible made me a little... focused. I spent...more time than I care to admit thinking and messing with this. I was working with a sackbot solution, but going through the analog sticks and manipulating the analog input values to instantly jump between 80 and 0 when crossing a threshold. I'm pretty sure that, within 60 seconds of confirming that it worked, the other solution was posted. The L2 solution is great! As far as the wiring goes, what I've found in my game is that if you forcibly move (not copy) the controlinator from the sackbot, the wiring will remain, but only temporarily. The game will "fix" it and disconnect the controlinator input wire when you save/load again. Keeping it on the sackbot chip will survive a save/load, but obviously that's ugly, a pain in the butt, and introduces the latency that tameturtle found. About that latency - if you change the controlinator to be a remote receiver, it seems to go away. I am suspicious of this, though. I have this feeling like the game is just introducing some additional, compensating latency somewhere when you do this. I'm not even sure if this matters, or how to test it, but I remain suspicious. There's another sketchy way to stop the latency, which I came across through my own sloppiness, and it makes no sense to me yet: connect the output of the L2 button to the controllinator eject input. This is just another reason why I'm suspicious of the remote receiver solution: if this works, is it because a wiring loop was created, and the game is now forcing a delay somewhere? tameturtle, I tried your awesome latency detector (much easier than creating 30 different units and wiring them up ), and took the toggle and the XOR off the sackbot chip to see if the game was just delaying them as well. But it kept working when I did this. Cool... I think?

2011-03-06 16:55:00 Author: JRootabega Posts: 2

---

Sadly transferring controllinator from sackbots chip will remove wire connection. I just tested it and it will remove it even if you capture it. Capturing/copying will always break it, but moving it doesn't. The 'XOR' makes sure that if the toggle differs from the controlinator output the audio object is triggered (to make it easier to perceive than a single-frame flash of a wire/tag). This isn't always the best way to detect latency - sometimes merely connecting two outputs into an XOR can affect the results, as can the order in which the inputs are wired to the XOR - see this post (https://lbpcentral.lbp-hub.com/index.php?t=49984-Comparing-4-analog-signals-to-find-the-strongest&p=786106&viewfull=1#post786106) for more details. In this instance, that's not the problem, however. And indeed, there is no latency when turning the toggle on. But turning it back off results in a beep, so there's at least one frame of latency before the controlinator switch returns to zero. I recreated your circuit verbatim, and got the same results, but there was one difference with my initial tests. Since I didn't want the Sackbot to move around while testing, I'd set the Controlinator settings "Remote Control" to "Receiver" and "Override Sackbot" to "No". Making the same change to your circuit eliminates the latency. Unfortunately, copying the entire circuit to a clean microchip causes the controlinator input connections to be cut for me as well. What seems to be occurring here is, any time you create a new instance of a Controlinator with wires connected to the inputs, regardless of where you place it, you'll always lose the input wires. This issue was reported during the beta, but never addressed. However, even if you move a working version off the Sackbot, the connection will break the next time you rewind, so I don't think it's gonna be practical to make circuits which exploit this behaviour of Controlinators without leaving it on the Sackbot. If you need it for a level idea, you can always hide the guy offscreen somewhere, and transmit the signals wirelessly if need be. So, yeah, it's not quite as neat as I'd hoped, but it's the only zero-latency method of doing ADC that I'm currently aware of.

2011-03-06 17:55:00 Author: Aya042 Posts: 2870

---

Nice, I stumbled upon something similar earlier today that is probably worth knowing if you don't already: R1 on a sackbot override controlinator will activate for analogue signals greater than 0, meaning it will grab as soon as a timer starts to fill, rather than waiting for a slight delay before grabbing (which is what I wanted to happen, thinking it would respond to the digital component). I was gonna try seeing if there was anything else I could do with this, but it seems people beat me too it. I guess you could probably force a number of comparators through a single controlinator if this behaviour is consistent across the buttons

2011-03-07 01:04:00 Author: rtm223 Posts: 6497

---

There's another sketchy way to stop the latency, which I came across through my own sloppiness, and it makes no sense to me yet: connect the output of the L2 button to the controllinator eject input. I'd think that's because the controlinator circuit is switched off entirely once the eject is triggered. (Just guessing, I'm only beginning to work with controlinators and sackbots.) This isn't always the best way to detect latency - sometimes merely connecting two outputs into an XOR can affect the results, as can the order in which the inputs are wired to the XOR - see this post (https://lbpcentral.lbp-hub.com/index.php?t=49984-Comparing-4-analog-signals-to-find-the-strongest&p=786106&viewfull=1#post786106) for more details. In this instance, that's not the problem, however. Thanks, that is rather handy to know! Situation- or even ordering-dependent behaviour like this can keep you debugging for hours if you're not aware of the possibility. I'd set the Controlinator settings "Remote Control" to "Receiver" and "Override Sackbot" to "No". Making the same change to your circuit eliminates the latency. Thanks again, another brilliant discovery. Although the high thermo cost of a sackbot seems to stick, this completes a perhaps specialised but very handy tool to have. As it happens, both of the applications I'd use it in need exactly one pair of such comparators. And I'm already looking for possible uses for that extra sackbot, perhaps he could talk the player through the controls or something. Cheers!

2011-03-07 09:31:00 Author: tameturtle Posts: 150

---

R1 on a sackbot override controlinator will activate for analogue signals greater than 0, meaning it will grab as soon as a timer starts to fill, rather than waiting for a slight delay before grabbing (which is what I wanted to happen, thinking it would respond to the digital component). Looks like it starts grabbing at anything over zero, but its behavior for outputting a digital 1 seems to be the same as every other button except L2 and R2, i.e. digital goes high above +75, and low below +25, staying the same for values inbetween. I also did a few more tests. For starters, the single frame of latency that tameturtle was seeing on the on->off transition only occurs when the Controlinator's "Remote Control" setting is set to "No" or "Transmitter" - the "Override Sackbot" setting has no effect. Also, I got rather strange results with L2/R2 in cases where the latency is extant - it always flipped to digital 1 when the analog went above zero, but when the analog signal drops back down to zero, the digital doesn't always drops back to zero, although the exact conditions are unclear. Not really worth any further investigation, since everything works fine as long as "Remote Control" is set to "Receiver" I was gonna try seeing if there was anything else I could do with this, but it seems people beat me too it. I guess you could probably force a number of comparators through a single controlinator if this behaviour is consistent across the buttons I've tested most of the buttons out, but only L2 and R2 seemed to work consistently enough to be of any use, so at the very least, you can use both L2 and R2 on each Controlinator. Situation- or even ordering-dependent behaviour like this can keep you debugging for hours if you're not aware of the possibility. Well, I'd been aware there was an issue with this for some time, although I'm still not 100% on how the component ordering algorithm works. So I figured the safest way to do latency tests was to chain several copies of the circuit, and look for a visible ripple in the output. Although the high thermo cost of a sackbot seems to stick... Really? I never considered one Sackbot to cost that much thermo, bearing in mind you can dump an arbitrary number of Controlinators on a single Sackbot.

2011-03-07 12:39:00 Author: Aya042 Posts: 2870

Posts: 1077139    Threads: 69970    Members: 9661    Archive-Date: 2019-01-19

Aus dem Archiv wurden alle persönlichen Daten wie Name, Anschrift, Email etc. - aber auch sämtliche Inhalte wie z.B. persönliche Nachrichten - entfernt.
Die Nutzung dieser Webseite erfolgt ohne Speicherung personenbezogener Daten. Es werden keinerlei Cookies, Logs, 3rd-Party-Plugins etc. verwendet.