If a menu has instructions printed in the status bar, it seems like the instructions can get cut off when the game is played on a smart phone. Is there a good way to prevent this?
Wade Clarke’s Menus extension has a screen reader mode, and if I select that, it prints the instructions in the main window, so they wrap instead of being cut off. But I don’t know if someone not using a screen reader would think to try that. (And screen reader mode also makes other changes, not just that.)
Unfortunately, the best you can do is detect that the screen is too narrow, and change how you display your text. Word-wrapping in text grids is entirely up to the game, not the interpreter.
It’s tedious, but in my WIP I ask the player if they are using a mobile device and configure the status bar based on the answer.
Flexible Windows has a phrase for detecting the width of the window (this is just from a random version of the extension that came up in search results)
To decide what number is the width of (win - a g-window):
(- FW_WindowSize( {win}, 0 ) -).
but it doesn’t work by itself, and I’d like to avoid adding in that whole extension. Is there another way to detect the width?
Is there a way to set up wrapping in text grid windows, or is it a matter of manually printing one (shortened) line at a time?
Basic Screen Effects also provides a “to decide what number is screen width” phrase; the reason Flexible Windows needs a more elaborate implementation is because you can divide the screen up in weird ways. But in standard Inform, the width of the main screen and the status bar is always the same, so you can do it the simple way.
This is its definition:
To decide what number is screen width:
(- 0->33 -);
On Z-machine, the interpreter stores the screen width at byte 33 in the header; on Glulx, the Inform library stores it there for convenience. This will notably cap at 255 on very wide screens (or overflow on old versions of Frotz), but if you’re just deciding if your hints fit, that won’t matter.
Manually printing one line at a time unfortunately. This is massively painful in Dialog and a little bit less painful in Inform. But still painful.
That looks great! Thanks!
(Edit: I tried adding this i6 code, and also tried using the variable “screen width” without adding the I6 code (I was already using Basic Screen Effects), and got different results. I think I’m going to go with whatever the built-in definition is, because that number seems like it’s responding when I resize the window, and this one doesn’t seem to do that.)
I’m assuming that’s number of characters. (Does anyone know the standard number of characters that a mobile screen can print?)
(Edit: After doing a little bit of experimenting with Parchment and developer tools, the smallest width I came across was 42, for Samsung Galaxy S8+.)
Hmm. I guess the options would be to print shorter lines in a text grid window (and maybe also start the text on the left side instead of centering it–I’m not sure how much difference that would make), or to print the text in the main window instead so it will wrap automatically.
I’m curious about how you configure the status bar for mobile. Do you make the status bar taller and break up the text into more lines, or print in the main window instead, or something else?
Yeah, and for text grid windows (the status bar), it’ll be exact. In the main window, not all characters are guaranteed to be the same width, so it’s technically how many zeroes will fit.
As for a standard number—when I asked before, 20 seemed to be the conventional minimum. But that’s pretty tiny.
At present, I am just cutting out the middle portion, but by release I’d like the player to be able to choose which columns to display. Since it’s all table-based (I’m using basic screen effects, too), that shouldn’t be hard to throw together
I do have the height vary sometimes when the “current tasks” list gets long.
I’ll try to grab a screen from my phone, just a sec…
edit: uh-oh! it looks my CSS is broken at the moment. I’ll try to look at that today
Thanks, @kamineko! No need to go to the trouble of more screenshots, though. I’ve got the general idea.
Probably not what you need, but I threw this together. It fits the text into the status bar, changing the number of rows based on the available width and the length of the text to be printed. It’s ugly (hard-wrapping without regard to words) and slow in both the IDE and on Borogove, but it’s pretty fast on iPhone Frotz:
Thanks, everyone!
I think I’m going to hack something like this into the Menus extension, using these instructions instead of the regular instructions if the screen width is below a certain threshold. (That threshold will probably be around 78, because it looks like that’s where some of the longer instructions reach the edge of the window.) These tables don’t account for every possible set of instructions that can be displayed with the Menus extension, but they do account for the instructions I am actually using. And they should fit for screens as narrow as 20 characters if necessary.
[Condensed status bar instructions for extra narrow screens (20-38 characters) displayed in the top menu]
table of extra narrow screen top menu status
left central right
"[mn_menuheading]" "" ""
" Press a number to" "" ""
" choose an option or" "" ""
" ESC[if screen width >= 23] or [otherwise], [end if]Q or X to exit" ""
[Condensed status bar instructions for narrow screens (39 characters to whatever the small screen threshold is) displayed in the top menu]
table of narrow screen top menu status
left central right
"[mn_menuheading]" "" ""
" Press a number to choose an option, or" "" ""
" ESC or Q or X to exit." ""
[Condensed status bar instructions for narrow screens (20 characters to threshold) displayed in endnodes that are accessed from the top menu]
table of narrow screen endnodes off top menu status
left central right
"[mn_menuheading]" "" ""
" ESC or Q: Go back[if screen width >= 39] to the previous menu[end if]" "" ""
" X: Exit" "" ""
[Condensed status bar instructions for narrow screens (20 characters to threshold) displayed in a submenu with numbered options]
table of narrow screen submenu status
left central right
"[mn_menuheading]" "" ""
" Press a number [if screen width >= 39]to choose an option, [end if]or" ""
" ESC or Q: Move back[if screen width >= 27] a menu[end if]" ""
" L: Leap to [if screen width >= 24]the [end if]top menu" ""
" X: Exit" "" ""
[Condensed status bar instructions for narrow screens (20 characters to threshold) displayed in endnodes that are accessed from a submenu]
table of narrow screen endnodes off submenu status
left central right
"[mn_menuheading]" "" ""
" ESC or Q: Go back[if screen width >= 39] to the previous menu[end if]" "" ""
" L: Leap to [if screen width >= 24]the [end if]top menu" "" ""
" X: Exit" "" ""
(There are two variations for the top menu, depending on whether the screen width is 20-38 characters or 39-78ish characters, because that will affect how deep the status bar will be.)
The rest of the time (that is, when a menu is not open), it also looks like left-aligned and right-aligned text in the status line overlap when the screen gets narrow. So maybe I should account for that, too.
Do you mean by editing the extension file…? I really can’t recommend that… what exactly is your “hack”? There might be a way to do it without actually editing the extension file.
If I misunderstood you, feel free to ignore this.
I’m talking about editing a game-specific version of the extension that’s in the materials folder for this particular game. I added in these tables and a variable and modified an existing rule (or phrase?) to display the tables at the right time. If I wanted to avoid that, I could maybe copy the whole original rule into the game itself, modify it there, and say it’s listed in place of the original rule. (I’d have to go back to the extension and see if the original was actually a named rule or a phrase.) But since I had already edited the extension to make another change (to a phrase), it seemed neater to have all of the changes in one place.
I guess it’s less bad if it’s copied to the materials folder.
Replacing a rule, phrase, or table without editing is easy though. (None of these even require an “in place of” header, unless of course it’s an unnamed rule.) That said, if it’s a big rule and you just want to add one line to it, I guess that’s not so easy.
Making your own modified copy of an extension under your own name is also far from unprecedented; I7 expects it and provides the second credits line specifically for this purpose. I think like half of my folder in the extensions repository is my modifications of other people’s extensions. (Probably less now that a lot of those other extensions were updated for the new versions.)
Sure, but whenever possible I think it’s better to use section replacements, rule relistings, table replacements, phrase replacements, or similar tools.
Of course, that may not always be possible.