Jump to content
Stray Fawn Community

Delay Gate Issue?


Konchog

Recommended Posts

The delay gate seems to be acting differently than I imagined.  Maybe it changed in the last update?

So, in the enclosed drone (see picture), the three circuits all have an impulse pause of 3 seconds, and the gate has a delay of 1 second.

From the top down, the impulses last for 0.9s, 1.0s, and 1.1s respectively.

Before you run the drone, ask yourself which LEDs are going to be lit, and at what time offset from zero are they going to be lit, and for how long?

I would have thought, bearing in mind it's a delay gate - that we would see all 3 LEDs lit, all at the 4th second, with the each LED being lit for 0.9s, 1.0s, and 1.1s respectively.

Seems reasonable, for a delay gate.

3 circuits

But that is not what happens.

In fact, only the bottommost LED is lit, and it is lit for 0.1 second.

So - it appears that an 'off' value sent to the delay gate while it is processing the delay just clears the gate's internal delay buffer.

filter component.drn

It seems that any change to the input cancels the buffer, which means it's some sort of short frequency filter. Maybe that is your intent - but I think that calling it a delay gate is a bit weird.. There's a real thing called the "gate delay" (or propagation delay) - which is the length of time which starts when the input to a logic gate becomes stable and valid to change, and ends at the time that the output of that logic gate is stable and valid to change.

The only way I can see to get the the behaviour I expected efficiently is by adding a driver - a buffer gate, which has the timing set to be equal to the delay gate. (see the following drone for the blinkenlights). While this works, it does mean that the forward timing (of the delay gate) must be repeated in the buffer gate, which doesn't seem to be correct.

I am quite willing to be told that I am ignorant and out of my depth here!

delay driven with buffer gate.drn

Link to comment
Share on other sites

7 hours ago, Konchog said:

The delay gate seems to be acting differently than I imagined.  Maybe it changed in the last update?

So, in the enclosed drone (see picture), the three circuits all have an impulse pause of 3 seconds, and the gate has a delay of 1 second.

From the top down, the impulses last for 0.9s, 1.0s, and 1.1s respectively.

Before you run the drone, ask yourself which LEDs are going to be lit, and at what time offset from zero are they going to be lit, and for how long?

I would have thought, bearing in mind it's a delay gate - that we would see all 3 LEDs lit, all at the 4th second, with the each LED being lit for 0.9s, 1.0s, and 1.1s respectively.

Seems reasonable, for a delay gate.

3 circuits

But that is not what happens.

In fact, only the bottommost LED is lit, and it is lit for 0.1 second.

So - it appears that an 'off' value sent to the delay gate while it is processing the delay just clears the gate's internal delay buffer.

filter component.drn 23.54 kB · 0 downloads

It seems that any change to the input cancels the buffer, which means it's some sort of short frequency filter. Maybe that is your intent - but I think that calling it a delay gate is a bit weird.. There's a real thing called the "gate delay" (or propagation delay) - which is the length of time which starts when the input to a logic gate becomes stable and valid to change, and ends at the time that the output of that logic gate is stable and valid to change.

The only way I can see to get the the behaviour I expected efficiently is by adding a driver - a buffer gate, which has the timing set to be equal to the delay gate. (see the following drone for the blinkenlights). While this works, it does mean that the forward timing (of the delay gate) must be repeated in the buffer gate, which doesn't seem to be correct.

I am quite willing to be told that I am ignorant and out of my depth here!

delay driven with buffer gate.drn 53.02 kB · 0 downloads

i thought about this too before

the impulse is activating the output for .9s     but what i don't know is if the delay gate takes that as a single tick input regardless of the duration it's held     ---

or if it takes it as a bunch of inputs, basically infinite since its being held, and then just registers the last tick when the   input active held duration    ends

 

for the delay gate to activate all the leds,     

the impulse giver activation time has to be    greater than     the delay gate time [ 1s ]

since the top two were .9   and    1.00

they didn't register  and only the bottom  1.1 did

 

for the delay gate holding the led on

the delay gate doesn't have a held output so it should be one tick

but the input isn't one tick

its technically infinite ticks

but if it worked by   registering the held tick inputs as infinite    and then   doing the output for each tick of the input which would make it register as infinite

then maybe the delay gate would output each tick, or have infinite ticks  for the duration of the input that went into it

 

instead of infinity the game could just immediately activate another tick   if it's  'held'   so there isn't a gap,  its not technically infinite seamless but it would simulate no gaps     and then the delay gate would output each tick that went into it

idk if the game can recognize infinity,   if the smallest possible time it can do is in fact    one tick

 

this would mean that if 

impulse held output  --> .9     |  delay gate  --> activates the first tick after the set delay time   and then continues activating the rest of the                                                                                                           ticks comprised in the .9 input  for   .9 seconds

so in the example there was a 1 second delay time

that would mean that        the led will light   1s after the very first tick from the impulse held output    and it should light up for   .9s

first tick   ==   '

first and ending ticks   ==   |

 

[3s]---------------->[']                 <no gap>                   [starts delay gate 1s]--------->|------------------------------------->[.9s]---------------------------------------------->|

(impulse wait)  ^                                                    ^                                                ^         (activation stops when delay gate uses all ticks)          

                            ^>   |-------------->[.9s]--------------->| ^   >    >    >    >    >   >   >   >   ^    

                            ^ (impulse held time output      ^             (delay gate keeps getting ticks)

                            ^ immediately? fills with ticks) ^      

                            ^                                                     ^

                            ^   >       >       >       >       >      >   ^

                                   (delay gate takes 1st tick)

 

i think the way it works now is that it if the input is still not being pressed after the delay finishes it won't activate 

so a more accurate name would be a trap gate  (may or maynot exist in real life)

probably needs a description like  Waits for the input key to be activated for a set time, then activates output key.

 

 

tell me if there is something wrong

 

also check this out

 

the battery full output     is not going to the delay gate input

                                           but it is lighting the battery full led

it's not starting below full so should at least put out one tick of battery full

but it must be doing that because the led is lighting

but then why isn't it going to the delay gate input

battery full output.drn

Edited by ababaBABABABABBA
Link to comment
Share on other sites

Well, with the battery full output, the delay gate time is less than than the battery expiry time.

If you change the battery delay gate to 10 seconds, then the turquoise LED never lights - it's just the same as the other stuff.

I do not think you need to be concerned about infinity, either..

Well - so my expectation was that the "Delay Gate" is what is called a "digital delay line" (There are analog delay lines too - which is normally fixed to a specific offset).

So, we know the the game uses ticks, (which are normally called 'samples' in digital electronics), and the maximum number of seconds the "Delay Gate" is set to is 10, so you only need 10 * the number of ticks / second for storage; not infinity.

The normal programming structure for a digital delay line is some form of FIFO queue.  Normally you only update the pointer to an array, which acts both as the value to output, and then the place to put the next input.

An empty three tick DDL, with inputs (at each tick) of 10100 will output 000101

000=>100 // Tick 1: output 0, input 1.
^        // Ptr at 0

100=>100 // Tick 2: output 0, input 0.
 ^       // Ptr at 1

100=>101 // Tick 3: output 0, input 1. (the pointer loops back to zero)
  ^      // Ptr at 2

101=>001 // Tick 4: output 1, input 0. (the input 1 has been delayed 3 ticks!)
^        // Ptr at 0

001=>001 // Tick 5: output 0, input 0. (the input 0 has been delayed 3 ticks!)
 ^       // Ptr at 1

001=>000 // Tick 6: output 1, input 0. (the input 1 has been delayed 3 ticks!)
  ^      // Ptr at 2
  			

Now, because the Devs at stray fawn did NOT implement the delay gate this way, I'm trying to work out just why they did it the way they did.

So, it's clear from experimentation that the Delay Gate will only activate if the input happens to coincide with it's own timing loop. Therefore, by tying an Impulse Giver with a active/pause of 0.1/1.2 (1.3 seconds total), to a Delay Gate with a delay of 0.7 seconds, the delay gate may never fire, even though.

It also turns out that my earlier solution fails, because the buffer just blanks out any input changes, which isn't so hot.

So, I then thought to actually build a proper delay line using If Gates for the FIFO queue elements.  (see attached).

lossy.drn

I added a space key sampler (once the buffer is filled, press the space key to see if there are any 0 being propagated), and it's clear that the logic gates are very lossy indeed, which really sucks and is completely unnecessary:  It looks like the rise times or fall times are not correctly coded, so the zeros are washed out of the signal.

Damn.  

So I may be wrong, but it seems there is no feasible way of writing a simple digital delay line that is not lossy.

Oh - is this a deliberate thing to stop storing variables?  I don't think so - because it's reasonably straightforward to construct addressed memory out of the existing logic gates.  It's a pain - but it's made much easier with the on-off switches...  

So.. what is going on?!

Link to comment
Share on other sites

3 hours ago, ababaBABABABABBA said:

i think the way it works now is that it if the input is still not being pressed after the delay finishes it won't activate 

so a more accurate name would be a trap gate  (may or maynot exist in real life)

probably needs a description like  Waits for the input key to be activated for a set time, then activates output key.

 

Yeah - sort of...

This is what I have now - Delay Gate has just the Time variable, which is on a loop.

At the last tick of each loop, it checks the input. If there is a value there, it sends an output. Otherwise it does nothing.

That means you can have lots of stuff being sent to delay gate, and you only need a single tick of nothing for the delay never to send anything, if it's synchronised.

Quote

............*   (check the last tick on the timer)
1111111111110   (inputs on every tick but the last)

==> Never lights up.

 

So, why is that useful?  I have no idea!

 

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...