Seems to be partially timer- and partially event-merge-related: if I compile with -threaded, the pieces do not move at all on their own, but as long as I keep pressing "down", the game appears playable as intended; if I compile without -threaded, the pieces move occasionally, but the effects of keyboard input are entirely unpredictable.
I've noticed this behavior in since the last couple of days, So at a guess a bug got introduced somewhere along the line. The merge issue is known -- at the moment, an occurrence doesn't appear in the output until it's known whether or not the other event ever occurs, which isn't ideal. Unfortunately, the obvious fix for the issue creates a large memory leak, I've been playing with a few ways to fix this.
Thanks for the info, Tom, where can I find more details about this merge issue? Given that FRPLs are traditionally synchronously concurrent languages, this is rather surprising: when sampling anything, one knows about everything's values _now_, which should be sufficient for merge, no matter whether the other event might or might not happen later. Claus