I’m certain I’m doing one thing silly right here – however I can’t see it :
Evidently the default choose (from an unbuffered channel) has a timeout that I can’t keep away from.
I’ve the next init() :
func init() {
strikes = make(moveChannel, 0)
go updateRelativeMove(strikes)
}
Then I’ve this replace :
func updateRelativeMove(strikes moveChannel) {
move_pair := newMovePair()
for {
choose {
case new_move := <-moves:
if new_move.x != nil {
move_pair.x = new_move.x
}
if new_move.y != nil {
move_pair.y = new_move.y
}
fmt.Println("<-", *move_pair.x, *move_pair.y)
default:
interval(move_pair)
time.Sleep(INTERVAL)
}
}
}
The place INTERVAL is const INTERVAL = time.Length(time.Second / 30)
and and I’ve checked the runtime worth as effectively – it’s reported as ‘33.333333ms’, i.e. 0.033 secs or 1/thirtieth second.
What occurs is that my interval will get referred to as ~15 instances a second and so the updates are (after all) calculated fallacious – however I anticipate this to be ~30 instances a second. Be aware that that is when the primary case will not be matched – i.e. no messages are obtained from the channel.
I might calculate (at runtime) the time for the reason that final interval – however this shouldn’t be essential – interval must be referred to as 30 instances a second – my solely thought is that the unbuffered message learn is itself taking the remainder of the time – despite the fact that that’s solely about 15 calls a second?!
Be aware: If I modify the interval to 1/sixtieth seconds I get ~38 calls/second
Any assist please – greatest needs – Andy
Okay – I mounted it – right here in case it helps anybody
I modified the default to:
case <-time.After(INTERVAL):
interval(move_pair)
}
and re-measured my timing a bit higher (cease watch) – and this works…
Additional to the above – evidently RobotGo is introducing delays of as much as 327.1859ms – presumably C taking on the Home windows thread…