Is this as difficult as I fear? I can’t recall ever doing any real-time programming in Inform (not even i6), but I remember reading some dauntingly complex examples.
Basically, I am using my status line for tutorial tips. Simple, right? Except people don’t look at the status line when they need help, because they are focused on the bottom of the window and tend to ignore the top. So I was thinking if I could just make the status text blink once or twice, in real-time (i.e. not waiting for the player to type another command to change its state), and it would attract the eye quite nicely.
But it seem pretty difficult to change the status line on any trigger other than the player hitting ‘return’.
Anyone got a tip on doing it without too much mess?
You could use Erik Temple’s ‘Real Time Delays’ - and maybe ‘Glulx Status Line Control’ - to use the glulx timer to get the status line to flash - or just part of it (EG you could have one character appear and disappear). This kind of thing can be set up to happen only when a certain flag is 1 or something, so that you can turn the flashing on and off as required.
Due to the current default programming of the status line, a status line which is more than 1 line long will already flicker every time it is updated on some interpreters, but obviously you can’t rely on this, and it could go away in a future Inform update.
My prime interface target for this is a browser window. Depending on how well my optimisation phase eventually goes, I may have to go with .z8 instead of Glulx, for performance’s sake. I am also worried about real-time programming, in general, maybe not being optimal for browser-based play. If I have to replace the main event loop of the game with a real-time event loop for every single command, it may be too big a performance price to pay for this feature; although I really don’t know since I’ve never done this and tested it yet.
Wasn’t there a way to just set text to flash in the z-machine in the old, old days? Maybe I am dreaming or confusing it with plain APPLE II programming. Thanks for the tips on those extensions, though.
Real-time control isn’t a performance hit unless you set up a timer of many ticks per second. The interpreter will sleep between events. You can set up a timer that runs, say, four times a second – redrawing the status line each time – and then shut it down after a polite four blinks.
Or, if you’re aiming this at a browser window, you could use Glulx and then set up your CSS (for a particular style) with “text-decoration: blink”! It is in the CSS spec… although I suspect most browsers ignore it.
Huh. Well that’s what I’m using now so hopefully from the sounds of this’ll be fast enough, although I do have some known inefficiencies to iron out, regardless.
As long as I am switching to real-time input, maybe that will bring me within easy reach of something else I’ve always wanted to add to this thing: shifting all the player’s input automatically into upper case.
You can do that (with the current version of Quixe), but it’s not a real-time function. You’d turn off echoing and handle the printing of the line input yourself. See glk_set_echo_line_event().
Just in Quixe eh? Well, it’s something. I want to run as identically as possible in an interpreter, but the graphic design is more important in the browser, anyway. Thanks man!
It will work in all interpreters that are up-to-date. I specified the current version of Quixe because you said your target is a browser window, and the version of Quixe that ships with I7 lacks this function.
Oh I see, thanks. The browser is the main target because it’s a web story about a man playing a game. But the game that he is playing is still a standalone game and I want it to look as identical as possible when played as a standalone game, for continuity’s sake.