How to buffer events (and use it with a counter)

http://i.imgur.com/PeQLy.jpg

Hi there again! Remember that previous tutorial, How to make a simple counter? Today we are turning that into a reliable dead body counter.

N.B.: this tutorial covers the logic that I am using for my new level's custom score counter, but I think a death counter is a much less abstract example. For reader's convenience.


http://i.imgur.com/Si1Ux.jpg

Here we have a dirty commie sackbot. The pests come in droves and it is best to heat up the cold war a bit and turn them into dust! As you can see, we are using a simple bullet hit detection that triggers a 0.1s timer which in turn kills the bot through a destroyer. Nothing fancy. At the same time it gets hit, it triggers a 1-shot counter connected to a tag. The counter is to make sure that the signal we are creating by activating the tag lasts as short as possible.


http://i.imgur.com/pn8Iq.jpg

DIE COMMIES!!!


http://i.imgur.com/FeZwT.jpg

Here we have our counter logic again and this time not a button but a tag sensor - registering the death of a dirty commie sackbot - triggers the counting mechanism to add up. (N.B.: in the screenie, the sensor is supposed to go into the positive input of the signal combiner, not the negative)

But these commies won't stop coming and we might just shoot two at once occasionally... Now our tag sensor will fail, because it does not distinguish between one tag active and multiple tags active. What we need to do, is pick up such an exceptional event and fire off multiple pulses into our counter caused by this event.


http://i.imgur.com/jyEY2.jpg

Here we are setting up one way to do it. Replace the tag sensor by a new microchip and put two tag sensors on it; one registering (at least) ONE sackbot death tag and one registering (at least) TWO sackbot death tags. In case two die, the first sensor is also triggered and we want to make sure it is either the one or the other. You see that setup demonstrated above.


http://i.imgur.com/iWnKP.jpg

Here we've added some more logic. When only one red dog dies, that signal goes out the other side of the chip as one pulse into the counting system. When two traitors of freedom die simultaneously, it triggers the reset of an inverted 2-shot counter. When this counter is reset it activates a small microchip that contains a pulser (a NOT gate feeding itself, creating a very rapid pulse). During a brief moment this pulser increases the counter with two pulses until it is full again and shuts the pulser down. During that time the pulser will have given off two quick pulses into the counting mechanism.

So, when two stinking commies die simultaneously, it creates two rapid pulses inside the system.

Perfect, right? NJET!!

I used to think this would work, but it is an unreliable setup; when after a simultaneous death, during the short moment that the system is giving off two pulses, if another bot dies, this pulse will coincide with the double-pulse going in at the same moment, causing one to get lost.

Awful commies! Freedom must prevail!!


http://i.imgur.com/EAcDs.jpg

Yikes!! What's this thing? It's freedom, baby.

Again, this is a bit complex, but stay with me, okay? This is multi-channel buffer that stores a single and double death event separately and unloads these events into the counting system whenever there is something to unload; on its own pace, even moments after the dirty commie rightly so bit the dust.

Two tag sensors, one for one, one for two death tags. They each up a counter of their own through a signal combiner. The counter goes into a positional sequencer that has a battery across its entire canvas. When the counter is empty, the cursor on the sequencer will be on the 0 position and the battery will not give off a signal; however, when the counter is of value 1 or higher, the battery gets activated. Thus the sequencer detects whether a counter's value is not 0. These batteries lead to a 3-gate AND gate.

On the other side of the chip we have a pulser (the purple NOT gate), leading into each AND gate. This pulser also passes through a red AND gate into the cycle input of a 2-gate selector. Each output of the selector goes to another AND gate. What will happen now is that the pulser causes the selector to rapidly switch between buffer channels; if a channel has a counter set to 1 or greater, it will activate the channel's AND gate.

An active AND gate goes to the negative input of the signal combiner, causing to count down the channel's counter. When the counter reaches 0 again, the channel stops passing on pulses. But as long as the AND gate is active, pulses will go to an OR gate where all channels send their pulses to; the output of that OR gate goes into the counting system. Also, separated by another OR gate and a NOT gate, these pulses go into the red AND gate, causing the cycling between channels to halt and unload that channels counter. When unloaded, the cycling continues until another filled channel is detected.

Freedom prevails!!


http://i.imgur.com/M1BYZ.jpg

Oh no!! Invasion!! Blow up the truck.

In this last example we'll be blowing up a truck and kill ten commies at once. Our system cannot really deal with ten simultaneous death events. We can extend the buffer logic to include ten channels, but there is another way. We know that a truck carries 10 kremlin dwellers and they will all die at once. So, why not increase our counting system with 10 instantly?


http://i.imgur.com/bZzdj.jpg

Here we have such a setup. A dedicated tag sensor registers the destruction of a truck (same logic as with a bot), goes to an OR gate and into the signal combiner that goes into the second selector on our counting logic, upping the count with 10 instantly.

But what if a truck dies at the same moment that a single bot dies who is causing the count to go up from 9 to 10? Then the truck event and the pulse from the red chip arrive at the OR gate at the same time and one of them is lost.


http://i.imgur.com/XRTzM.jpg

Same buffer, but instead of two tag sensors, the two pulses go into their own channel. Enjoy your rock-solid commie corpse counter!


http://i.imgur.com/Z646j.jpg

I love the analogies. Great tutorial!

Nice tutorial, tho your "commie" hatred baffles me!

Relying on one shot signaling bit me several times, though. I can't document it ever being missed (I think it happened once or twice), but I definitely know for sure that the signal may sometimes not be caught "in time". Actually, I was planning to make a video about those "asynchronous" tags and tag sensors. That's why, instead of one shot signaling, you may want to use verified signaling to make sure of the time that your receiver end received the signal, then go "boom" on the commie-bot. This "circular" signaling as I'd like to call it has been outlined in my own counter tutorial (the technique should work with any counters, not to compete with yours, your counter does something else, but the stress is on signaling), tho it may need heavy modification for parallel signaling, which you have already solved here. I may get onto that sometime myself. Just a warning for one shot signaling.

Quote:

---

Originally Posted by hesido

Nice tutorial, tho your "commie" hatred baffles me!

---

Hey, it's Rambo. :)

Quote:

---

Originally Posted by hesido

Relying on one shot signaling bit me several times, though. I can't document it ever being missed (I think it happened once or twice), but I definitely know for sure that the signal may sometimes not be caught "in time". Actually, I was planning to make a video about those "asynchronous" tags and tag sensors. That's why, instead of one shot signaling, you may want to use verified signaling to make sure of the time that your receiver end received the signal, then go "boom" on the commie-bot. This "circular" signaling as I'd like to call it has been outlined in my own counter tutorial..

---

I'll take a look at that. At the moment, my one-way signaling appears to work, but I have been telling that myself several times over the course of months only to find out later that the score didn't add up with the targets killed. It'd be a severe test of your circular system however; this tutorial only shows 4 buffer channels, while I use 18 in my score counter. I kill a pile of enemies and I see the buffers unload themselves for the next 2 seconds after. If the feedback to the signal's source has to be behind that buffer, then it'd take ages before an enemy blows itself up.

Your circular system has the same goal as my buffers: to try and make event registration reliable. It is too soon to say, I have to dive into your tutorial first, but we might have built two completely different ways to tackle the same problem.

great tutorial Kris! as ever it was as informative and clear as it was funny :)

keep em coming !

In your setting, the one shot signalling may *not* cause problems indeed. In the setting that I had problems with position was also important, basically what happened was, the one-shot signal was being given at a specific location, and then the signaler moved on right afterwards. The signal receiver looked for the signal in that specific spot, and normally, it could catch it. But some objects *always* missed it, although the signal was given in that location, it received no signals.

Took quite a while to figure out, but it turned out that these objects (exact emitted copy of other objects that worked normally) received the signals 1 frame later than others. The one-shot signal was not actually being missed, it was received 1 frame later, but at the new position! The signal was missed because the receiver did not look for it in the new location. So I had to change the system so that the signaler didn't move on until it makes sure the signal is received by the signal receiver.

I'm assuming, these objects that "live one frame later", are objects that are emitted at times of high complexity to reduce cpu load (probably assigned to a different thread?), but they keep on living one frame later even when you reduce that complexity. If you highlight them and clone them, the cloned objects still live 1 frame later. If you capture them objects, and place them from your goodies bag, they re-sync back to the world!

I should stress that your system may not have any problems. But I wanted to share my experience with one shot signaling :) Sorry for diluting your nice tutorial.

great tutorial...what happens if you kill said commies faster than said buffer can unload?

Quote:

---

Originally Posted by BabyFace

great tutorial...what happens if you kill said commies faster than said buffer can unload?

---

Then the buffer will keep unloading the events for a while. The only limit is the size of the channel's counters. The buffer will unload stuff as fast as a pulser frequency can unload it, with the only significant latency being the switching between channels; it is not noticeable with two channels, but try 10 and worst case scenario it takes up to 1 second until the buffer starts to unload the stored events.

So, it can lag behind sometimes, but the upside of all of this is that it is extremely reliable: you kill it, you get rewarded for it. For one-way systems like score or body counters the lag doesn't matter much, but if you are feeding the results of these systems back into other logic that is timing critical, you may want to reconsider.

i guess what i meant to say was what will happen if you fill the counter before it gets to unload. will the nxt kill then be missed? i know its farfetched but it could be possible with heavy action

Quote:

---

Originally Posted by BabyFace

i guess what i meant to say was what will happen if you fill the counter before it gets to unload. will the nxt kill then be missed? i know its farfetched but it could be possible with heavy action

---

Yes. Set the counters to 100 max, drop 201 sackbots in your level and blow them all up at once. You will miss one kill.

That is where the truck option comes in.

EDIT: actually, it will fail to work anyway if you do this; the system is designed to take rapid pulses of single and double kills, not a single blast of more than 2 bots at once. That is indeed what the truck solution is to illustrate.

Now I need to step off this kill counter example and explain the original purpose of all of this logic: a score counter that receives tag pulses. My system takes 10, 20, 40 and 80 points buffered and also double-10, 20, 40 and 80. It unloads these as pulses of 10 points into the counter (first selector). Then next we have the same setup for 100, 200, 400 and 800 in unloads of 100 (second selector). The truck tag sensor illustrates the 100's score count and how subsystem needs to be buffered with the 10's subsystem as well in order to not fall behind 100 points occasionally.

The limits of this score system are clear: cannot buffer more of any unit than the size of its counter; cannot detect and buffer triple (or more consecutive) occurences of an event; does not support score event pulses that go beyond the sensors used (max. 100+200+400+800 = 1500 points in one go). Of course, an event can go on pulsing 1500 points 10 times to add 15000 points, but that is not what this system is for; I have separate sensors for high numbers (10k, 20k, 50k boss score bonuses), but they occur on tightly controlled moments (unlike blasting away hordes of enemies) so they don't require a rigid buffering system.

I must say, this is fantastic. I had to read through it a couple times before I understood, but it looks great.

Here is my buffer + score counter in action, pushing it to its limits.
http://www.youtube.com/watch?v=EctHfonqCts

thats the tv you use?

Awesome. This tutorial came at just at the right time for my newest creation :)

here is another way you could do the same thing, i'm not good at explaining how things work so i'll just post a pic and give a brief run through.
http://ib.lbp.me/img/ft/9bb490ec08c0...5fb83cc237.jpg
basicly it adds the simultaneous points/deaths together then adds them to a feedback loop. it then checks to see if there is 10% or more in the loop, if there is it pulses the 10 output(if you still want to use selectors for final count), subtracts 10% then checks again. when there is less then 10% it checks for 1% or more, if there is it pulses the 1 output and subtracts 1%, then checks again till there is nothing left.
this setup can handle up to 9 at once, but it's easy to extend the setup to handle as many as you want, if you want more than 100 at once you will need to use custom batteries so you can add/subtract values less than 1%
in the pic blue batteries are 1%, green are 5%, and yellow are 10%.
the green ONE chip is just a one-shot counter, and the green chip with the [=] outputs an on signal when both inputs are equal.
Edit: you may need a one shot counter or a 2 port selector after each sensor to dump the analog signal

Quote:

---

Originally Posted by evret

http://ib.lbp.me/img/ft/9bb490ec08c0...5fb83cc237.jpg

---

Your one of the few people I know who label there logic. But that is a good way aswell :)

if your referring to the PLUS, MINUS, EQUALS, and ONE chips, i made them and and hearted them coz i use them all the time, it gives me quick access and it saves re-making the same things everytime. i gave a few to robbit10 so you can get them in the creators toolkit if you want them. the other colour coding and stickers on the chip were to make things easier to understand for this thread

Very detailed and understandable. Thanks and well done. :)

Your FBL setup has me intrigued. Before I read your reply something like this was going through my head after I watched compher's FBL tutorials.

I might give my level's buffer another iteration, using this, but other things take priority right now.

i had to make a couple of changes since i posted the pic. turns out the XOR in the subtraction part wasn't quite doing the trick, i changed it so the one's part didn't even try to check untill the there was nothing left for the tens part to take (did that make any sense? :P)
i sent you a friend request so i can show/send it to you if you wanna check it out with rebuilding it yourself

also the setup in the pic was based on you still wanting to use the selector setup to store/display your total count, however you could use lower values for the FB loop to have it store your total count as well, or you could wrap past 100%, or use both.........
for example if you use values of 00.1% you could have a count up to 1000, but if you were to wrap it into a second FB loop you could have a total of up to 1,000,000. or a third would be 1,000,000,000 etc etc.

by wrapping past 100% i mean using logic to make it so when 2 numbers add to more than 100%, say 45 and 90, it can carry the 1 over to a second FB loop and leave the 35% in the 1st FB loop

Quote:

---

Originally Posted by evret

i had to make a couple of changes since i posted the pic.

---

Like removing the awesome sticker work :p

This works really well and is something I was thinking about adding to my current learning exercises. Thanks for the help!

You lost me evret, and since I allready have to use this for a feedback-based meter I'll use Antikris' one. Thanks!

actually, because you are already using a feedback loop my way is much easier, just ignore the minus side of things in the pic and change the plus's to minus's (coz you would b losing health) then u could have this directly wired into your feedback loop, it's just adding all the hits that occur within the single frame together and adding (in your case subtracting) the total to/from the fb loop within the same frame

hum, actually, all I need is 10 damage chips and tag sensors all set to a different amount. the end. If there's one, it will activate one damage chip. If there's two, it will activate two damage chips. Then I add the damage signals together. The end. This allows to keep the % value of each signal, so I can make multiple hits of various values at the same time. that was way too easy, I guess I was tired. And I don't really understand XOR gates (yeah, it takes me 10 minutes to figure out what they do each time I try).

I built a system using feedback loops which works with both positive and negative and also doubles as a sampler. now I can store any signal and lower-increase it. (oh, only the % value actually, increasing/decreasing may not work with digital)

the XORs in the pic are only to have upto 9 hits at once without having to have 9 adders, completely unnecessary but just added to show how it could be done

O_O.. evret, you make everything look easy...

http://ie.lbp.me/img/ft/91e5b03c0d27...dd250d5585.jpg

Inspired by CompherMC's logic in his latest tutorial on sound effects, I simplified this buffer setup. The logic to cycle through the buffer channels was needlessly complex. The screenshot above is centered around a 3-channel selector - one channel more than there are buffer channels, set to 3 of 3.

Now, if a channel is loaded, its sequencer will report a "higher than 0" signal, causing the selector to switch to its appropriate channel. In case multiple channels light up at once, the way selectors work, the channel with the highest number takes charge. I used to use a pulsing NOT gate to offload the channels but this is no longer needed: once a channel causes the selector to light up, this selector is instantly set to the highest (unused) channel. Here it will stay as a default if the channel has run empty, but if it has not then the appropriate selector channel will light up again after only a 1 frame interval.

This buffer system is now entirely self-operating. It is faster, only doing stuff when it needs to and contains less logic than before. With 28 of these darlings in a level of mine, the difference in framerate is very noticeable.

so now instead of cycling through each system continuously, it will completely empty each buffer before moving to the next.. is that a correct interpretation?

Quote:

---

Originally Posted by shane_danger

so now instead of cycling through each system continuously, it will completely empty each buffer before moving to the next.. is that a correct interpretation?

---

That's what I got out of it as well. I have some reservations, though...

Quote:

---

Originally Posted by Antikris

http://ie.lbp.me/img/ft/91e5b03c0d27...dd250d5585.jpg

---

Took me a while to digest what all this was for and how it worked, but... are you sure the new version even works? Sequencers take one frame to update, so your selector will double-fire if my tests were correct. All you'd need to do is add one more port to the bottom of the selector and wire from the third to the fourth to add a frame. Of course this was evret's solution to mine not working, so I could be mistaken.

At any rate, I'd probably do it as a feedback loop as well, due to easy expandability. As you add more and more buffer levels, it will tend towards being more efficient this way. This is the two-level version:

http://i6.lbp.me/img/ft/8e69b1e97ff2...cab07fbeba.jpg

The battery is at 1%, and all of the inputs are straight from the tag sensors, which are set to count 1 and 2 tags, respectively. When you get a signal, it will store the number of tags detected from the sensors into the loop as a percentage, and then start pulsing an output and subtracting 1% until back down to zero. Each cycle for the output will take 2 frames (to account for sequencer slowness), but the inputs will update on every frame. As long as you aren't killing commies at an insane frequency, the output (and accompanying count down) should always have time to drop back down to zero signal in the loop.

Then, to add more levels, you add more additions to the loop:

http://i6.lbp.me/img/ft/096fa037b801...f3ed796086.jpg

The nice thing about doing it this way is that you do not need to cancel lower-order sensors in the event that higher-order sensors are triggered.

this is pretty much the same method as mine but i tried to allow for large amounts by checking for 10 first and outputing that via a second wire (for the 10s part of a selector based display), although in hind sight the likelihood that that would b needed is very slim, your is much easier to understand though ;)

Quote:

---

Originally Posted by comphermc

http://i6.lbp.me/img/ft/096fa037b801...f3ed796086.jpg

---

This (assuming it works) would seem to be the most thermo-efficient way for converting a large number of simultaneous tag enables into pulses, given, for 'n' simultanous tags, it's only 3n+c components. The only change I'd suggest would be to use the "sackbot brain controlinator hack" to eliminate the ADC latency.

Of course, if you're gonna have more simultaneous enemy units active than you need simultaneous death detections, the real challenge is thermo-optimizing the enemy units.

I've often wondered if it's more thermo-efficient to lose the timer/pulser, and replace the tag with an emitter which emits a piece of invisible sticker panel with a tag which only lives for 1 frame.

Assuming the thermo cost for the enemy unit and sticker panel are mutually exclusive (since they can't both exist simultaneously), the piece of sticker panel could include a 1% battery powering the tag, which would eliminate the need for the 'n' AND gates in Comph's design.

You could also vary the battery strengths on the sticker panel for different scores, given that the pulser logic is just a glorified adding machine.

Quote:

---

Originally Posted by Aya042

Assuming the thermo cost for the enemy unit and sticker panel are mutually exclusive (since they can't both exist simultaneously), the piece of sticker panel could include a 1% battery powering the tag, which would eliminate the need for the 'n' AND gates in Comph's design.

---

Even better will be the ability to set a sensor to Count, so that it will output an analogue value equivalent to the ratio of active tags to target number of tags. Hooray for the Vita!

Quote:

---

Originally Posted by comphermc

Even better will be the ability to set a sensor to Count, so that it will output an analogue value equivalent to the ratio of active tags to target number of tags. Hooray for the Vita!

---

Even better will be the ability to set a sensor to Sum, so that it will output an analogue value equivalent to the sum of the signal strength of all matching tags. Hooray for the made-up feature! :p

Edit: Oh. I also forgot a few others new sensor modes: Product, Mean, Median, and my own personal favorite, Standard Deviation. ;)

I know I suggested it, and it obviously fixed the problem but that extra frame via the selector isn't sitting right with me....... You could try wiring the sequencer output to it's own reset and directly to the "subtract" AND gate and doing away with the selector altogether. That should cause the sequencer to do a fresh check after each subtraction frame. Or If you wanted to leave the selector u could set the battery in the sequencer to 1% and get rid of the AND gate.
Edit: you could also add a splitter to dump negative b4 the sequencer because I think the negative was what causing to to just keep pulsing when the loop should have been empty. Although it shouldn't b going negative in the first place

That is a very interesting alternative, Compher. You basically replaced every separate counter for one large feedback loop. Does it put extra requirements, btw, on how long a feed into the system should stay active for it not to add to the signal twice? A one frame pulse, I presume.

I ran a test to see whether an addition pulse escaped the system I have now - due to sequencer lag - and this turned out be not the case.

I might try and backup the buffers I have now and see if I can increase performance by using your approach. Though the ease of extending the system is certainly a benefit, at the moment my greatest concern is to squeeze every bit of performance out of my shooter level's logic.

Quote:

---

Originally Posted by Antikris

That is a very interesting alternative, Compher. You basically replaced every separate counter for one large feedback loop. Does it put extra requirements, btw, on how long a feed into the system should stay active for it not to add to the signal twice? A one frame pulse, I presume.

I ran a test to see whether an addition pulse escaped the system I have now - due to sequencer lag - and this turned out be not the case.

I might try and backup the buffers I have now and see if I can increase performance by using your approach. Though the ease of extending the system is certainly a benefit, at the moment my greatest concern is to squeeze every bit of performance out of my shooter level's logic.

---

Yeah it's just a one frame pulse on the tag that it needs, as it adds 1% for every tag that's active within each frame
edit: ok, it seems the reset on sequencers didn't work as i'd expected it to, u can use the 2 port selector if you place an AND gate b4 the sequencer, and and wire the second selector output to it's other input but it doesnt make the precess any faster, i'd say the only other option is to use a bot

Quote:

---

Originally Posted by Antikris

http://ie.lbp.me/img/ft/91e5b03c0d27...dd250d5585.jpg

Inspired by CompherMC's logic in his latest tutorial on sound effects, I simplified this buffer setup. The logic to cycle through the buffer channels was needlessly complex. The screenshot above is centered around a 3-channel selector - one channel more than there are buffer channels, set to 3 of 3.

Now, if a channel is loaded, its sequencer will report a "higher than 0" signal, causing the selector to switch to its appropriate channel. In case multiple channels light up at once, the way selectors work, the channel with the highest number takes charge. I used to use a pulsing NOT gate to offload the channels but this is no longer needed: once a channel causes the selector to light up, this selector is instantly set to the highest (unused) channel. Here it will stay as a default if the channel has run empty, but if it has not then the appropriate selector channel will light up again after only a 1 frame interval.

This buffer system is now entirely self-operating. It is faster, only doing stuff when it needs to and contains less logic than before. With 28 of these darlings in a level of mine, the difference in framerate is very noticeable.

---

Quote:

---

Originally Posted by comphermc

That's what I got out of it as well. I have some reservations, though...



Took me a while to digest what all this was for and how it worked, but... are you sure the new version even works? Sequencers take one frame to update, so your selector will double-fire if my tests were correct. All you'd need to do is add one more port to the bottom of the selector and wire from the third to the fourth to add a frame. Of course this was evret's solution to mine not working, so I could be mistaken.

---

Quote:

---

Originally Posted by Antikris

That is a very interesting alternative, Compher. You basically replaced every separate counter for one large feedback loop. Does it put extra requirements, btw, on how long a feed into the system should stay active for it not to add to the signal twice? A one frame pulse, I presume.

I ran a test to see whether an addition pulse escaped the system I have now - due to sequencer lag - and this turned out be not the case.

I might try and backup the buffers I have now and see if I can increase performance by using your approach. Though the ease of extending the system is certainly a benefit, at the moment my greatest concern is to squeeze every bit of performance out of my shooter level's logic.

---

@antikris- i think i'm with comphermc on this, the only way this setup would work as it is, is if they are counters, not timers or if you add the extra frame via the selector as comphermc said. if they are counters they wont b able to detect tags that are pulsed in every frame as the counter requires an off frame b4 it can count the next tag.
although it's possible i'm completely missing something
what makes you need 28 of these in your level?

While I think most folks participating in this thread would be content to roll their own, readers looking for some pre-made feedback loop parts (along with tutorials and other goodies) might want to check out Pivottt's Health Meter Toolkit discussed at this forum thread. There's some good plug and play stuff there and it continues to evolve.

Quote:

---

Originally Posted by evret

@antikris- i think i'm with comphermc on this, the only way this setup would work as it is, is if they are counters, not timers or if you add the extra frame via the selector as comphermc said.

---

They are counters, not timers. And the extra frame lag on the sequencer appears in this case to be an academic exercise; I tested it by filling the counters beforehand and the output result was exactly what I had put in.

Quote:

---

Originally Posted by evret

if they are counters they wont b able to detect tags that are pulsed in every frame as the counter requires an off frame b4 it can count the next tag.
although it's possible i'm completely missing something

---

Yes. If a tag pulses at the exact frame that another tag of the same name and color pulsed and switched off, then the receiving tag sensor will not register two pulses but one pulse of two frames long. Also, it probably won't be counted as a simultaneous pulse by the x2 sensor.

Thanks for pointing out this detail in Matt's setup. It looks like indeed his system does not require an off-frame for a pulse to count but adds signals that are set to ON on every frame that the feedback loop loops. Meaning that in above situation the loop will pass that tag sensor signal during the two frames it is ON and will add those to its signal value.

This is probably the biggest reason I should go with Matt's setup regardless of whether its performance is (minutely) better.

Quote:

---

Originally Posted by evret

what makes you need 28 of these in your level?

---

- 8 for the lower score regions (1x10, 2x10, 1x20, 2x20, 1x40, 2x40, 1x80, 2x80),
- 8 for the higher score regions (1x100, 2x100, 1x200, 2x200, 1x400, 2x400, 1x800, 2x800),
- 2 for exceptional score regions (1x1000, 2x1000),
- 3 x 2 for where one digit selector passes onto the next (and is also hooked up by score sensors of a higher score order),
- 4 on the yellow powerup collision unit.

And with each I mean a buffer 'channel'. In my latest screenshot you see two channels. Also note that I am not actually storing the score in an analog signal (which would eliminate the need for the 3x2 buffer, but bring about other challenges), but instead drive forward an array of 10-gate selectors. The output of these, a count display, does not change instantly with high increments of score, but gradually as the buffer channels are unloaded in steps of 10 (lower region), steps of 100 (high region) and 1000 (exceptional region). This goes pretty fast, though so it is hardly noticeable. (and when you do focus on it, you're dead :D)

As I intend to do more with score in my second release (area 2) I might have to rethink this, though. I'll be heavily experimenting with your analog setup. :)

I tried Matt's setup and noticed that the system keeps pulsing endlessly. It appears, due to what seems rounding errors, that the subtracting bit makes the loop dive below zero. This is interpreted by the sequencer as 'not 0' and thus it never ends. Simple fix is to put a signal splitter in front of the sequencer.

Also, it doesn't need the extra delay in a 3gate selector. A two gate is enough and makes the loop unload faster. However, this also causes one too many pulses and needs a slight delay. So I used a 2gate selector, wired the first output to the result action and the second output to the AND gate that subtracts.

http://i8.lbp.me/img/ft/b5855b1368db...890351223b.jpg

Quote:

---

Originally Posted by Aya042

You could also vary the battery strengths on the sticker panel for different scores, given that the pulser logic is just a glorified adding machine.

---

This won't work with multiple death events, ergo multiple of the same tags lighting up. What would he tag sensor for 2 or more simultaneous tags need to pick up if not a full 100% signal?