Sorry for the page, but your blog has no contact details and I couldn’t find your email addy in the extension or in your profile.
I added RTD to my game this eve for the purpose of putting tiny unbreakable pauses between successive requests of the player to ‘press space to continue’ - since one time my finger slipped and I went through 2 pages of text at once. It’s working fine. Also, I tried it without also including Fixed Point Maths and it still works fine, I’m guessing because I’m only using small numbers in a simple fashion (like 500ms pauses.) Is there any danger in not including Fixed Point Maths?
I noticed a sideeffect of RTD in Gargoyle, though - when a delay ends, it seems to generate a line feed. You notice this in Gargoyle because the text comes up from the bottom, so what happens is - you see a bunch of text - then there’s a pause for the delay you asked for - then the text bumps up one more line.
There’s no noticeable effect in interpreters that print from the top down.
I did find one really cheap workaround - request a super short delay, which generates the line feed so fast it appears to come as part of the original text dump - then trigger the delay you actually want. Two delays in a row does not generate more than one line bump.
Thanks for the extension.
Edit - Actually the two delay method is kinda neat! It gives the screen a tiny bit of motion which helps draw your attention to the fact new information has appeared. Something you can miss when static blobs appear instantly…
While my email address is available from a number of sources, I actually prefer that folks post to the forums for most questions so that the answers remain publically available. (I’d love for my email to appear in my profile here, but the profile refuses to show it even though I’ve indicated that it should. I’ve always assumed that the absence of profile emails is a general configuration set by the maintainer.)
The officially released version of Real-Time Delays, at least, doesn’t require Fixed Point Maths. There was a preliminary version that might have required FPM, but I don’t remember. Did you download RTD from the inform7.com?
Could you post the code that is giving you spurious line breaks? I couldn’t reproduce that issue, and RTD itself is very unlikely to be the cause in any case. I suspect that you are printing in such a way that the “press any key” instruction interrupts line input, which will result in a line break on all interpreters but Zoom and the OS X IDE. A code excerpt should indicate whether that’s the case or not.
The documentation on the site and in the extension, once downloaded, says it needs FPM, but if it’s working without, maybe it’s just that note that got missed?
Re: spuriousness - Each delay comes right after a ‘say’ that ended with typesetting (either [roman type] or [normal style], a glulx style I defined) and is followed by a keypress-getting loop.
Here’s a typical chunk:
[code]To reeeally wait:
wait 500 milliseconds before continuing, strictly.
say "[italic type]SUCCESS[roman type] - Sound is supported![paragraph break]You should be hearing an introductory tune playing. Press 'T' to hear it again. If you find you can't hear the tune, you may need to unmute or turn up your computer's (or speakers') sound volume.[paragraph break][line break][bold type]<< Press SPACE to continue to the next test when you're ready >>[roman type]";
reeeally wait; [prevent hitting space twice accidentally]
while the infinite_loop is 1 begin;
let k be the chosen letter;
if k is 32, make no decision; [proceed with checks if space pressed]
if k is 84 or k is 116, play_mischief_music;
end while.[/code]
Though I experimented with removing the [roman type] and the bump still happened.
Yep, that’s what happened–I missed deleting the description of the dependencies from the first paragraph when I cleaned up the extension for official release. The only dependency is Glulx Entry Points. Thanks for pointing that out!
Huh, it’s an odd sort of break, in that if you don’t actually print anything during the input loops, the next text to be printed will fill the empty line. It looks like GarGlk is printing a break on the first glk_select call, but printing over that break unless the game actively prints something in the meantime. I’m not positive about that, though… Anyway, this seems to fix it:
[code]To reeeally wait:
say “[run paragraph on]”;
wait 500 milliseconds before continuing, strictly;
When play begins:
say "[italic type]SUCCESS[roman type] - Sound is supported![paragraph break]You should be hearing an introductory tune playing. Press ‘T’ to hear it again. If you find you can’t hear the tune, you may need to unmute or turn up your computer’s (or speakers’) sound volume.[paragraph break][line break][bold type]<< Press SPACE to continue to the next test when you’re ready >>[roman type] ";
reeeally wait; [prevent hitting space twice accidentally]
wait for any key;
say “[line break]”.[/code]
By the way, you might want to consider whether you really want to do this, at least in precisely this way. If I’m replaying your game, for example, and not really reading the text, there is a half-second in which “press space” is printed on screen but won’t respond to input. I could hit the spacebar once, twice, or even more times before it actually does anything.
It might be better to wait for the half-second before printing “press space”. But possibly that suffers from the same issue that prompted you to look at this…
Just a note: I did a little more poking around and determined that it isn’t the glk_select call in itself that’s printing the blank line, and it’s not characteristic of any particular variety of Glk. The culprit seems to be the call to the “timed activity rulebook”–there’s no request for printing a line break in that rulebook; the call to the rulebook itself generates the break. I haven’t studied Inform’s line break algorithm’s well enough to understand why, but that’s the basic etiology.
Thanks a lot for looking into this. I will try out your fix.
Don’t worry, I already thought about the issue of inconvenience. I don’t enforce this gap every single time the game asks you to hit space, only during this configuration process. And this process only runs the first time you boot the game - or if you ask to go through it again later from a menu. By its nature, this segment is all about the player reading the responses in a state of attention.
If I do anything, I might change the loop length, but I already tested it on myself and 500ms seems pretty good. By the time you’ve read a few words of new info, you can press space, but if your finger just slipped, it won’t go off.