WebAssembly is not fully alive yet, and won’t be for another year. If you want to use it, asm.js is its current analogue.
A desirable project in its own right.
I see. I wasn’t sure what Dannii means advising not using PNaCl, but my reasons not to use it would be:
- requires some work reorganizing makefiles;
- has no access to local file system from the modules;
- kind of “proprietary-ish”: if Google decides to abandon it, is likely to die. Also, modules wouldn’t be runnable from a Firefox plugin, or in any other browser.
But what I’m interested in is a little broader topic beyond just IF interpreter GUI-shells: if I install Lectrote today and then need another Electron-based software on my computer, I end up having two additional Chromium installations even though I use Chromium as my default browser already.
Another thing is upstream interpreter updates: if I use either Lectrote or Gargoyle, I have to reinstall them completely to get those updates. And whether they even have those, depends on their authors or maintainers.
What I would like to have, is a standardised platform where other C/C++ programs can also have an external web UI in a similar way. Easily installable like Chrome apps, once user has framework installed, and easily upgrade-able when their modules have new versions. A couple of examples would be: a board game with chess-like minimax algo written in C, that I have written a jQuery-based UI for. I don’t think I can compile it with Emscripten so that it would run fast enough, not that it’s theoretically impossible but I lack the expertise, so I would like to integrate my UI with its binary in some way that perhaps resembles Glk.
Another theoretical example: OCR package that is already in Debian repository, Cuneiform, could have an additional package using it as a library and doing talking to the Webkit.
Is there a way to build it upon Glk adding more primitives to it?
I have no idea how packaging would work outside of Linux, that may be another interesting project to bring Debian, CentOs or Gentoo-like repositories to Windows and Mac.
(It’s possible to install programs in Windows-fashion on Linux, dragging all the disparate version copies of all dependencies along; but not the other way round!)
The benefit of this modular structure would be instant upgrade of let’s say Bocfel soon after new version is out, without having to wait for GUI-shell maintainer to replace sources.
Probably an off-topic here, so feel free to banish me to the off-topic subforum with this 
It is possible to add more primitives to the Glk API, but that is set up around the idea of extended input and output capabilities. Trying to cram a general application interface or update system into that API is not going to work out well.
Mac and Windows have good reason to treat applications as sealed bundles with all their dependencies included (aside from core OS libraries). It’s easier for users to understand, easier for users to manage, and hard drive space is cheap. You can use Linux-style package managers – I use Homebrew – but most people don’t.
If you want to manage Electron’s dependencies in a unified way, you could rely on the Node level. Install Electron as a global Node package, install Lectrote’s source somewhere, and then launch it with “npm start foo.z5”.
Emscripten is about 0.5x native speed as long as you avoid certain pitfalls (I think 64-bit integers and exceptions are the only ones of any relevance). kripken.github.io/emscripten-si … lines.html
Just use emscripten. Your browser is that standardized platform. asm.js is supported by all desktop browsers, and whether it dies or not, emscripten’s abilities will never disappear; it can only be supplanted by something that does the same thing better.
Emscripten’s asm.js output will literally run faster than a Java or Python application, at least in desktop browsers. This isn’t some kind of “theoretically, Java is just as fast as C++” nonsense; you get this performance without doing anything.
On mobile, performance depends if they support asm.js (they don’t). So your performance will suck on mobile, about the same as a normal browser webpage, too bad I guess. But at least it will run.
You can start an emscripten project from scratch, or steal code from my project here: github.com/ad8e/Text-Game-Standard-Engine
It’s public domain, so no need for any kind of credit. Its shell file is designed for text output of any kind, not just IF, pretty useful.
Actually, I shouldn’t have said all desktop browsers, old versions of IE don’t support asm.js either. I think only Edge does out of Microsoft’s browsers, and that’s only available on Windows 10.
I agree with zarf that having N copies of Chromium on a desktop machine isn’t a big deal. For Electron apps that don’t run third-party JS, just the JS provided with the application itself, it isn’t even very important to keep Chromium up to date. My perception is that Lectrote is “fast enough” on desktop.
Electron/Lectrote doesn’t work on WinXP, but XP is dead now, completely unsupported by Microsoft for almost two years; it’s already rare, and getting rarer.
IE11 (the most popular version of IE) “supports” asm.js; it’s just ES5 JS. But it’s pretty slow.
For a while I thought that Emscripten/asm.js on mobile would be the best way forward, and I still kinda think that, but I think we’re at least five years off from that being a good solution for Android devices. Android hardware is seriously underpowered in ways that really matter to single-threaded JS performance.
youtube.com/watch?v=4bZvq3nodf4
twitter.com/slightlylate/status … 5543740416
“much of this is down to L2/L3. iPhones have gobs of it (3MB L2, 4MB L3), Android’s don’t (Pixel: 1MB L2, no L3)”
You can’t buy an Android phone with L3 cache at any price today in 2017. Even if Qualcomm realized their mistake and started shipping bigger caches starting now, most Android users wouldn’t see the benefit for years.
For the foreseeable future, mobile CPUs will benefit from tightly constraining memory usage; in practice, that means C compiled to native code. iosglulxe+iosglk are probably as good as it gets on iOS. (iosglulxe doesn’t do JIT compilation like GIT can, but Apple forbids JIT in apps, so you’re stuck there.)
On Android, IMO RemGlk + Git Glulx is our best hope; hence allensocket’s heroic work on exactly this.
https://intfiction.org/t/help-c-devs-android-blorb-image-sound-saving-in-remglk/10985/1
You’d have to turn off the USE_DIRECT_THREADING option in Git, but that’s always been a bit shaky. The Makefile has it turned off on MacOS and on anything using GCC3. I have a feeling it won’t work on Android either.
Hmm, that’s interesting about Android’s poor/missing cache. I wonder how that would affect IF parser terps, which are generally running games with <1MB RAM or stack.
ifvms.js is now using Typed arrays, so memory use there will be nicely constrained. What isn’t contrained is the JIT. I could add a LRU cache, but I doubt it would really be effective. It’s very unlikely for the terp to max out a phone’s RAM, and even if the CPU is missing L3 it will be able to handle caching the JIT better than I could.
I think it will come down to what I’ve been saying for years: minimising function calls. Since discovering zmach I’ve got an even better idea how to adapt the relooper algorithm.
Of course choice based fiction has a whole nother set of performance questions, being less JS intensive, but often more DOM intensive.
As we close out August, things have really improved on this front. 1. Chris Spiegel has taken the terps from Gargoyle into their own GitHub project and created fresh CMake files. github.com/WakeRealityDev/Thunderquake_Qt
What we are lacking is user interface. The backend is all there and solid, you can run multiple terps and RemGlk is extremely flexible in terms of license issues mixing closed-source and open-source, etc - as you are not linking and completely using data exchange of JSON. Performance is perfect, the overhead of JSON is not significant. What’s missing is visual design, user interface, how to cope with mobile keyboard and screen sizes, etc. Popular apps are out there like Son of HunkyPunk / Text Fiction / etc that could be adapted to work with RemGlk - and I’ve released some demonstrations of that with Text Fiction with some success. But I really encourage some people with better visual skills than I have to make some fresh front-ends for presentation of the JSON. Especially on mobile screens where people want to pinch-to-zoom, different font sizes, rotate, keyboard hinting - there is a lot of opportunity for creativity.
I made some big Android-specific mistakes in Thunderword design in the first half of the year with the JSON interface, and that really discouraged me and slowed me down, but I’ve solved that now this week. It’s a friendly and elegent user interface that’s really the thing we need most. Ideas, drawings, mockups - and of course, complete apps, are welcome and encouraged 
And HTML front-ends are welcome too, there is no real performance reason to avoid a WebView front end. I hit this thread to look at some of the parts of Lectrote - in terms of front-end.
Still working away More to come.
My thoughts on mobile IF user interface:
First, on 5" phones, the situation really isn’t so bad. Hadean Lands is basically playable on a 4.7" iPhone 6 with not much in the way of phone-based UI assistance.
Having said that, I think there is room for some possible improvements.
-
iosGlk offers a nice feature where you can double-click on any word on the screen and it will add it to the current input text, with a little animation. That’s a big help.
-
iosGlk also provides a nav bar at the top of the screen with a button to show/hide the keyboard. When the keyboard is hidden, the game shows a tab bar at the bottom, including a Help tab and a Settings tab.
-
It would be cool if Thunderword would provide game-specific keyboard autosuggest suggestions. I believe it’s possible to influence/control the keyboard autosuggest options in an Android app. At a minimum, you can disable the keyboard’s suggestions and provide a “fake” suggestion bar of your own.
If you populate the suggestion lexicon with words shown in the game, plus a dozen standard commands (examine, look, take, wait, save, restore, undo, drop, open, close, push, pull, turn, put) I bet it’d work just dandy.
It’d be especially helpful if the “default” three suggestions before you type anything are “examine” “inventory” and “look” (or maybe “help”).
- Long term, I think the right way to make phone-friendly parser IF is for all games to adopt key features from Blue Lacuna, especially including hypertext in the transcript, and a feature where typing a noun does a default action (normally “examine”). The autocomplete bar would then support links instead of terms. For example, Hadean Lands includes a “dusty bubble” and a “scratched bubble” as objects. Typing “d” should suggest “dusty bubble” instead of just “dusty” (because that’s a link that has appeared in the game). The game would autosuggest only links and verbs, ignoring non-linked (non-notable) words in the transcript.
Then, upon entering a room, you could just tap on things that you see in the room description to examine them, or type just the first letter or two of an object’s name to get an autosuggestion. Tap the room name in the status bar to examine the room, i.e. “look.”
I think this is all beyond the scope of a general-purpose interpreter like Thunderword, so I’ll stop my rambling here.
Meandering verbose reply, I will try to come back and edit this reply and respond to specific things you mentioned about UI elements - as a lot of those ideas exist in already published Android terp apps. But I’d rather let it (the topic, state of things) all hang out and not leave anyone with the impression that what’s been going on with Thunderword is out of desire, it’s really a matter of weak talents.
I’d really like to see us add a Glk-type standard for basic menus and CYOA on parser (Gluxe). There have been experiments over the years with hybrid interfaces, we just need to encourage some standard encoding - and we could even do static data-file analysis of the existing library of IF stories to help build a database that all the terps could reference.
Downloading, organizing, and off-line play of IF stories. I’ve openly begged for apps to do these things here all year 
I’d also like to see a standard created for all html-based (mostly CYOA) terps in a .zip file container so they can be downloaded and started in an offline browser / WebView. Right now, many are only available on “live websites” and really aren’t using active-server features - they just aren’t published as a single file like a .blorb was intended for multi-asset sets.
On Thunderword, it’s been a technical meat-grinder of my worst talents I’m really not a C programmer, although I wanted to leverage the basic Gargoyle set with a heavy emphasis on channel I/O (multi-windows streams, some of which can do out of band triggering like Vorple and other libraries can do). You will see me begging for Makefile help a year ago, and code for how to extract blorb files, these things ate up a lot of my time. But the real issue that’s holding me back is my lack of UI talent. I’m just not good at all with the visual design / UI development and I keep hoping someone who has really played on the existing Android apps - which are full of ideas (Text Fiction, Sony of Hunky Punk, Twisty, etc) can say “hey, can you make it work just like this specific design”, but so far, no such suggestion or screen mock-up has been shared. I figured a few players would have a discussion about what they really wanted from other game apps (of all types), and maybe even create some Photoshop mock-ups / animated gifs / videos / etc.
I would need development help to get something as solid as the Apple developers are accustomed to making. I’m a bull in a china shop when it comes to UI, and in general to the IF scene. I can’t even make good icons, story illustrations, or color schemes, and likely never will be able to. Even my forum posts of late seem rambling frustrations more than well-organized coherent presentations… but I’ve witnessed some great work that people published years ago (like Incant app, Glulx on Android) that nobody bothered to even discuss as it sat and rotted on the vine. So, I’ve let my frustration all hang out, as I wanted a well working technically modern app too!
The very first thing I opened source at the start of the year was Thunderstrike - which was without a UI - and a small simple app - hoping somebody would program a RemGlk Activity for us all that’s better than the ones I’ve made. But it’s now September, and I don’t think anyone has done it. I’m to the point where this week I’m literally bringing in code from GlkOte - as at least it’s interface is feature complete, ahead of my most-complete work in Thunderword. However, GlkOte doesn’t deal with mobile screen sizes or mobile keyboard either.
I was really hoping that the existing major Android app developers, who have done better UI than I can do, would have woken up from their slumber. Or even the long-ignored Incant app (open source) would have inspired some development this year (the code is well organized, and readable). It wasn’t really my intention to be pushing a new line of apps - they have mostly been noise-making efforts to show that even someone with low talent can make a multi-back-end Android app - so why aren’t we as-a-community doing it on Android. Even HTML interfaces could be added on top of RemGlk engines compiled in C. Almost any programmer can work with JSON in a variety of languages… even a cross-platform game engine like Cocoa2D with LUA could be brought in to make a user-interface on top of the JSON coming out of RemGlk.
I’ll try to come back and edit this messy comment.
Zip file containing index.html. There’s your standard. Include metadata.iFiction (XML format, see Babel doc) for bibliographic info.
I’d rather go a couple steps further the filenames could be .zip_if - so that we can locate them without having to open up every possible .zip file on a system Like the purpose MIME types serve on downloads. The main thing I seem to observe is that a lot of HTML stories are not being archived / published in containers and when on a live website they don’t have the metadata file or even an asset manifest. For example, you may not know an image asset comes off the server until you enter into a specific room in the story (dynamically loaded). So it isn’t possible to save the webpages in a classic sense. On the meta regard, I think we also need to start encouraging parental / age / content markings like is required by Apple and Google to publish. It’s “keeping up with the times” that I’m encouraging, since a lot of the Web HTML stories did not adopt blorb conventions. To me, these are real problems I’ve run into, not some theoretical imagination of a seam. Perhaps it’s my poor presentation that inspires so much negative response around here, saying “it’s fine how it is, don’t question things”.
My comment about HTML-based stories was that we encourage standard practices, and encourage new IF authors to realize just how long-lasting (decades) IF stories have been endeared by readers. Encourage off-line packaging. Domain names expire and works are lost all the time.
I’m no UI expert either, but my approach to UI is to find a UI that I like and clone it, within reason. Today, for Thunderword, the natural thing to clone would be iosGlk.
I asked some Apple app users if they could make a YouTube video to help me understand what was working for them as players: groups.google.com/d/msg/ifrotz- … CMANecEwAJ
I do not have the skills to clone well balanced and perfectly executing user interfaces. All the Android terp developers I have encountered with open source projects seem to have no interest in working together (and all just independent built apps and left them, except for Twisty - but that’s been in development for many many years). I mean, if you want to just run one story and make an app for one story - people have done that: github.com/SimonChris/AndroidIF
I could release a stand-alone self-contained Text Fiction that runs with all the RemGlk backends. It seems popular on the UI front. And I’ve finally solved all my RemGlk stability problems (my mistake) that have been dragging me down all year. But there hasn’t been much enthusiasm from the established Text Fiction users. And it still needs a user interface for picking more than just Z-machine stories.
The obvious answer for the community was for Twisty 2.0 to get finished - or for Son of Hunky Punk to add Glulxe. They are both open source. There interface is well rated and popular. I tried working with the code on both a year ago and had so much confusion over Glk multi-windowing and their C to Java interfaces that I just couldn’t personally do it. Alas, I made a huge design error in my approach to RemGlk C to Java interface (in-process dynamic loading of terps) that wasted months of my time in 2017 to get working on diverse Android hardware. The cure to the stability issues took 1 day when I finally gave up and started fresh with Qt on the desktop for a sanity check, but I can’t get my months back In hind sight, that time could have been spent on Son of Hunky Punk’s Glk - which has a functional user interface. And the size of the mistake I made has left me discouraged and on a tighter schedule for my fiction story writing.
I haven’t given up.
I know I’m a broken record for the AXMA system which is a Twine-like choice engine with extremely nice multimedia capability, but one of the other amazing tricks it does is it automatically adjusts the UI and text wrapping to the screen size.
If you’re on a phone, it removes the graphics window and the side menu and replaces them with a “show image” button in the bottom left corner, and flows the menu along a line at the bottom. When a new picture is displayed, it fills the screen with it initially and lets the user dismiss it with a tap and bring it back up with the button. It’s pretty impressive if you resize the desktop browser window because it does this on the fly as the screen size/ratio changes.
Lectrote 1.2.9 has been published which fixes the bug of Hugo not being able to save properly.
Right, thanks for mentioning it – I dashed off a build last night but didn’t have time to post about it.
Also thank you for fixing the Hugo save bug. 