It doesn’t slow down at the line break either.
Well I’m out of ideas. All of the pauses work as they should for me in both WinGlulxe and WinGit–both the original line break delays and your 2 second pause–running in Wine (Windows emulator on OS X). I can’t see why this would work in Wine but not on a native machine…
Try downloading my gamefile and testing with that:
dl.dropbox.com/u/947038/Bug%20Report.gblorb
Any difference?
–Erik
P.S. Here’s the code used to create the gamefile:
Include Real-Time Delays by Erik Temple.
When play begins:
say "Type TURN ON COMPUTER to see animated text display. The desired delay in milliseconds between the printing of each character is initially 20 ms. You can change this by typing DELAY 2, for example, which would change the desired delay to 2 ms."
The Lab is a room. The computer is a device in the Lab.
Delay is a number variable. Delay is 20.
To teletype (text-to-be-printed - an indexed text):
repeat with N running from 1 to the number of characters in the text-to-be-printed:
if character number N in the text-to-be-printed is "[line break]":
wait 400 milliseconds before continuing;
say "[character number N in the text-to-be-printed][run paragraph on]";
wait (delay) milliseconds before continuing, strictly.
Instead of switching on the computer:
say "[line break]";
teletype "The great and wise Cheif Buga stands before you on a pedistal, illuminated by the two torches on either side of him.";
say line break;
wait 2000 ms before continuing;
teletype " He is a giant of a man (both in height and weight), with hands so large he could crush your skull like a paper cup.";
say line break.
Setting the delay is an action applying to one value. Understand "Set delay at [number] ms" or "delay [number]" as setting the delay.
Carry out setting the delay:
change the delay to the number understood;
say "Delay is now [delay] milliseconds."The way that the interpreter in the Inform 7 application works means that it’ll never respond that quickly to short timer events: Inform 7 runs the interpreter in a separate process so that it can recover if the interpreter crashes, but a side effect of that is that communication between the two is generally only checked about once every 100ms or so. In normal use this is fine, but the teletype effect makes it rather obvious.
There isn’t much that can be easily done about this without compromising the stability of the Inform 7 front-end or quite a lot of re-working. At the moment there’s too many other more important things to work on for this to be a priority, sorry.
I admit I haven’t tested this myself, but it seems like even 10 FPS would be OK for teletype? Or is it unbearably too slow?
I’m not sure about the performance BishyT is getting, whether it was 1/100ms or even worse. However, David’s explanation suggests that one ought to see an increase in speed by “releasing” the gamefile and opening it in an external interpreter. Like David, I don’t think this is a big deal–if performance is acceptable in the end user’s experience, it doesn’t really matter whether there’s a bit of a lag in the IDE. (And there is some lag in most multimedia functions in the IDE, whether on Mac and Windows).
On to your question about 1/100ms. I think it is pretty slow, but it’s not excrutiating; certainly it ought to be good enough for testing. You can try it with the gamefile I posted upthread. Type DELAY 100 to see what it looks like…
What I’ve found testing other terps was that Zoom was able to get significantly better speed than any of them (hence the name?). I estimate Gargoyle (Mac OS X) prints one letter every 50-90 ms, whereas Zoom seems to be able to do significantly better than 1/20ms, maybe even better than 1/5ms.
UPDATE: David Kinder has explained that the resolution of the timer for Windows Glk (which powers the WinGlulxe & WinGit interpreters) is such that the best possible temporal resolution is about 20ms, and for a “teletype” effect like this where the entire display must be re-rendered every time the timer “ticks”, the best resolution will probably be around 50 ms. So there’s an explanation for the lag on those interpreters.
–Erik
Well whaddaya know, it works! With the teletype set to 50 ms all the other waits work now.
What was your setting before? Could you post the full code of the failed game? As I said, I couldn’t replicate what you were seeing, but if there’s a bug with timers in Windows Glk, I’d like to be able to track it down and submit it.
Thanks,
Erik
Strange, it seems to have fixed itself. Now the pauses happen even if the teletype is set to 1 (though of course the teletype itself doesn’t run that fast in the preview).
Also, I tried running my project in WinGlulxe, and everything worked perfectly fine (no lag).
If the timer limitations in other interpreters have turned you off from using this or other Glulx multimedia tricks, there is a cross-platform solution with very nice performance coming:
Ben Cressey (the driving force behind the Gargoyle interpreter) has been working on new timer code solutions as well as display-speed enhancements for both text and graphics. The beta Mac build (see here) showcases both of these improvements, but I think you can expect to see them expand to the Windows and Linux versions of Gargoyle before too awfully long.
–Erik