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

[Aya042]

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.

[comphermc]

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!

[Aya042]

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!

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

[evret]

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

[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.

[evret]

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

[evret]

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.

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.

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?

[LittleBigDave]

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.

[Antikris•]

@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.

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.

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 )

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.

[Antikris•]

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.

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?

[comphermc]

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?

I think he didn't explain the whole setup. You could have the tags of different strengths be different colors and thus use different sensors, but still use the same loop. I wanted to call him out on it as well, but it sort of makes sense.

Say your pulses on the enemies all have 1% or 2% signal coming in, through blue and green tags respectively. Have two sets of sensors to detect signal strength for each color and stack them like above (so a sensor for 1 tag, 2 tags, 3 tags, etc). Now you don't need the AND gates and everything will get properly added into the loop. Subtract out as before.

[evret]

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.

i tested this setup and kept gettin one less pulse out than was added, however going back to using the top output of a 2 port selector with the added splitter seemed to fix it. with this setup it is pulsing out every second frame, so it's the fastest solution yet


i also tested this in multiple situations, 5 in on one frame, 5 in on consecutive frames then a mix of both and it always pulsed out 5, where using the 2nd output of the selector i kept getting 4

[Aya042]

You could have the tags of different strengths be different colors and thus use different sensors, but still use the same loop.

You don't need to use different colors.

If you set a tag sensor to "signal strength" mode, then the "number of keys required" will determine which tag's signal strength it outputs. Setting it to 1 will give the signal strength of the first tag to be enabled within its radius, setting it to 2 will give the signal strength of the second tag to be enabled within its radius, etc.

So this circuit...



...always outputs the sum of the signal strengths of all green tags (up to five) in its radius, regardless of what values you use... well... except if the sum exceeds 100%.

The point about using the emitter is that activating an emitter and a destroyer on the same object on the same frame will cause the emitter to fire, but activating a tag and a destroyer on the same object on the same frame will not cause the tag to enable.

[Aya042]

If you set a tag sensor to "signal strength" mode, then the "number of keys required" will determine which tag's signal strength it outputs. Setting it to 1 will give the signal strength of the first tag to be enabled within its radius, setting it to 2 will give the signal strength of the second tag to be enabled within its radius, etc.

Okay. That was a lie. It's actually as rtm223 posted just over a year ago...

Also, worth noting is that if you use "signal strength" on a tag sensor, and there are multiple matching tags, it will pull the value of the n^th highest signal strength (where n is the number required), regardless of distance. Not sure if this is news to anyone else but me - I seem to remember from the beta assumed that it would pull the strength of the n^th closest - i.e. that I would be able to pull out the distance to, and value of the n^th closest matching tag by using a pair of sensors. This is not the case. Indeed I don't think there is any way to match up the distances and strengths of each tag in a neat manner.

...where "highest signal strength" is determined only by the signal's magnitude - the sign is ignored. Still, the main point was that each sensor always measures the strength of a different tag, so the signal summing logic works either way.

This is actually better, cos it means you can easily sort analog signals from highest to lowest, so if your signals are 'scores' and also contain player color info, you can easily output the scores and colors of the players in 1st, 2nd, 3rd, 4th places.

Not sure if it helps for evret's four-signal sorting chip. Best I could think of was to add a distinct microscopic signal to each 'score' before sorting, then subtract the original signal after sorting, and use the remaining signal to determine which was which.