I am currently able to use scaled-to-fit large (4k) images in web releases of my upcoming Spring Thing games. That’s great! Since scaling is kind of hit and miss between interpreters, I used much smaller images for Repeat the Ending that never scaled. I’d like to go back and remedy that someday, if there’s ever time.
I’ll still be using small images, of course, for local interpreters, but it’s nice to have an option for high-resolution images.
I am wondering if this means I will have to maintain separate releases for HQ and LQ images? I could ask the player about it, but the game is front-loaded with junk (and I haven’t even asked about screen reader mode yet). It would be nice if this could be automated. My question:
is there a way for my project to detect whether a web (or local) version is running? Something I could use as a condition while displaying figures.
I’m sure this has been asked many times for many reasons, but I seem to have chosen bad search terms.
I’m guessing you’re not really testing for a web interpreter so much as testing for a particular type of rendering capability? Lectrote, for example, is just a web interpreter packaged up as a local application, so anything Parchment can do, Lectrote should be able to do too.
Unfortunately, while there are plenty of ways to test for particular rendering capabilities, there’s currently no way to test the size of the entire screen in pixels, which I’m guessing is what you want. I put forward a tentative proposal last year but it hasn’t ended up going anywhere yet.
It may be possible to get the size of the whole screen in pixels by calling glk_window_get_size on the root window, but I can’t find where (or if!) it’s defined what units that function should use on pair windows. It may be illegal, or it might be undefined behavior, or it might use the pair’s key window’s units.
It should be possible to get the size of the whole screen in pixels by closing all existing windows, opening a single graphics window that takes up the whole screen, measuring it, then undoing that whole mess. But in the process this will erase anything that was printed to the screen, so it should only be done at startup…which means these values will be wrong if a game is saved on one platform and restored on another.
You can get around that by @protecting these values from restoration, but things are rapidly getting out of hand here, and if there’s any simpler solution you should prefer it over this!
Still, if you don’t mind these values being wrong if a game is saved on one device and restored on another, an extension could hook into the “starting the virtual machine” rules to capture these values before Inform starts up properly.
I probably mean that. I can see what you mean, maybe, but I don’t really know those terms. I started down this road a long time ago with the “release with an interpreter/website” option. That may be why I’ve attached to the term.
Lectrote, mechanically, could do the scaling (and it has that transcription, too!), but I don’t want to distribute CSS on the competition page. So it seems a browser solution is what’s viable for the distribution goal? Unless I did an EXE, but I don’t feel great about that idea two weeks before the deadline.
It doesn’t sound possible, but I would love some kind of “hey VM where are you,” or passing / detecting something very high-level or general that could be used to determine whether static or scaled images should be used.
But long term, I definitely agree that screen detection would be a huge help
e: understanding what I can about your recent update, yes, that seems like just the thing.
I can probably whip up a “get screen dimensions at startup” hack, but I haven’t done Inform stuff in a while, so I don’t know if it’ll happen within two weeks. Which Inform version are you using?
Specifically for knowing whether you’re playing online or not, I know that there are things called ‘Gestalts’ that each interpreter has, and you can ask Inform if an interpreter has that gestalt or not.
So, for Bisquixe, when I made it, there’s one new gestalt that just says ‘Am I online using Bisquixe or not?’.
So, if you’re using Parchment or Quixe, it’s possible there’s a gestalt that’s just for them, too, that you could use. I’ll research it but it’s probably unlikely
@Draconis@mathbrush Thank you! But I’d hate for you to put that kind of effort into it. I think I have a workable solution. Heck, maybe I should skip the gblorb and just do browse/bundled lectrote. I know there have been some threads about that.
I wonder if players would resent the lack of a .gblorb? I’d rather just control everything.
Ryan Veeder has had a couple of games in recent years where there is no download at all due to neat features (like Fly Fishing Simulator). And all Vorple games are online-only; so if you did browser and bundled lectrote it would be more options than both of those.
For Never Gives Up Her Dead, I did bundled games, browser play, and I did add gblorb but labelled it as ‘intended for mobile device use only’ since using an app like Frotz or Fabularium doesn’t work with the other options. But I don’t think you have to go that far if it works well online already.
Please consider those of us with lousy internet connections. I really hate having to download a whole “website” just to delete everything except the gblorb. Or to recreate the gblorb by editing and decoding the base64-encoded Javascript file.
Incidentally, never ever ever use screen size. The only thing that matters is the window size, either the interpreter window or the browser window, as appropriate.
It’s not that bad if you can arrange your program so that you can set which version compiles with a single true/false statement at the head of your source, or by commenting one extension in or out. I’m still on 6M62 but I hear Inform 10 is better at this sort of thing than pre-10 Inform was?
Yeah, I’ll do it with extensions. That’s what I’ve been up to, but it’s kind of a hassle.
I think bisquixe can solve that, and I’d like to try getting my formatting in there, too, but I’m worried about the time left until deadline. I don’t really understand CSS. I just hack at it until things work.
So yes! It’s straightforward to have a game determine in Bisquixe, then decide in-project whether to print large or small images.
figure of astronaut is the file "astronaut.jpeg".
figure of Lastronaut is the file "astronaut 540.png".
to say AImage:
if screenreader is true:
say "Add descriptive text here.";
otherwise if bisquixe is active:
display the figure of astronaut;
otherwise:
display the figure of Lastronaut.
The most arduous part of the process is keeping the images in the game.
Instead of release along with a "bisquixe" interpreter, I ran my game file through the ifsitegen.py process.
These are the lines I used to specify image placement (via bisquixe)
this is the tall images rule:
css-set-fast "img; width; auto !important";
css-set-fast "img; height; 80vh !important";
this is the wide images rule;
css-set-fast "img; width; 100%";
css-set-fast "img; height; auto !important";
(credit to Ferkung for help with the CSS)
Once/if I have everything the way I want, I will write up something a little more detailed for people like me who maybe aren’t so great at this stuff.
