intfiction.org

The Interactive Fiction Community Forum
It is currently Sun Dec 17, 2017 6:14 pm

All times are UTC - 6 hours [ DST ]




Post new topic Reply to topic  [ 29 posts ]  Go to page Previous  1, 2, 3  Next
Author Message
 Post subject: Re: Lectrote 1.2.0
PostPosted: Sun Jan 29, 2017 5:48 pm 
Offline

Joined: Sat Jan 23, 2010 4:56 pm
Posts: 5507
Quote:
Another possibility is to enhance Gargoyle with GUI dialogs for tweaking it's configuration file.


A desirable project in its own right.


Top
 Profile Send private message  
Reply with quote  
 Post subject: Re: Lectrote 1.2.0
PostPosted: Mon Jan 30, 2017 9:36 am 
Offline

Joined: Fri Jan 27, 2017 3:29 pm
Posts: 11
ad8e wrote:
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.


I see. I wasn't sure what Dannii means advising not using PNaCl, but my reasons not to use it would be:

1) requires some work reorganizing makefiles;
2) has no access to local file system from the modules;
3) 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 :)


Top
 Profile Send private message  
Reply with quote  
 Post subject: Re: Lectrote 1.2.0
PostPosted: Mon Jan 30, 2017 12:40 pm 
Offline

Joined: Sat Jan 23, 2010 4:56 pm
Posts: 5507
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".


Top
 Profile Send private message  
Reply with quote  
 Post subject: Re: Lectrote 1.2.0
PostPosted: Mon Jan 30, 2017 4:12 pm 
Offline

Joined: Sat Jan 28, 2017 2:03 am
Posts: 9
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). https://kripken.github.io/emscripten-si ... lines.html

Quote:
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.

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: https://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.


Top
 Profile Send private message  
Reply with quote  
 Post subject: Re: Lectrote 1.2.0
PostPosted: Mon Jan 30, 2017 4:23 pm 
Offline

Joined: Sat Jan 28, 2017 2:03 am
Posts: 9
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.


Top
 Profile Send private message  
Reply with quote  
 Post subject: Re: Lectrote 1.2.0
PostPosted: Tue Jan 31, 2017 12:14 am 
Offline

Joined: Sun Apr 18, 2010 3:58 pm
Posts: 773
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.

_________________
At Choice of Games, we sell long-form choice-based interactive fiction games. We're looking for writers, paid in advance.


Top
 Profile Send private message  
Reply with quote  
 Post subject: Re: Lectrote 1.2.0
PostPosted: Tue Jan 31, 2017 12:19 am 
Offline

Joined: Sun Apr 18, 2010 3:58 pm
Posts: 773
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.

https://www.youtube.com/watch?v=4bZvq3nodf4
https://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.
viewtopic.php?f=38&t=21086

_________________
At Choice of Games, we sell long-form choice-based interactive fiction games. We're looking for writers, paid in advance.


Top
 Profile Send private message  
Reply with quote  
 Post subject: Re: Lectrote 1.2.0
PostPosted: Tue Jan 31, 2017 12:43 am 
Offline

Joined: Sat Jan 23, 2010 4:56 pm
Posts: 5507
Quote:
(iosglulxe doesn't do JIT compilation like GIT can, but Apple forbids JIT in apps, so you're stuck there.)


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.


Top
 Profile Send private message  
Reply with quote  
 Post subject: Re: Lectrote 1.2.0
PostPosted: Tue Jan 31, 2017 1:52 am 
Offline
User avatar

Joined: Wed Oct 14, 2009 4:02 am
Posts: 2436
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.


Top
 Profile Send private message  
Reply with quote  
 Post subject: Re: Lectrote 1.2.0
PostPosted: Thu Aug 31, 2017 9:37 am 
Offline
User avatar

Joined: Fri Sep 30, 2016 7:02 pm
Posts: 404
Location: USA
dfabulich wrote:
IE11 (the most popular version of IE)
On Android, IMO RemGlk + Git Glulx is our best hope; hence allensocket's heroic work on exactly this.
viewtopic.php?f=38&t=21086


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. https://github.com/cspiegel/terps CMake is the native make system supported by Qt and Android Studio NDK - so great mobile options there. It works with multiple Glk libraries. 2. A complete in-editor Android Studio 2.3.3 solution for Glulxe + RemGlk is open source with a Java front-end example - https://github.com/WakeRealityDev/IFTer ... droidCMake 3. an example of the same technology with pure C++ in Qt 5.9.1 was released open source this week. https://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.

_________________
Glulx interpreter Android apps are in open beta testing! Three apps to watch for: Incant!, Thunderword, and Thunderword enhanced Text Fiction.


Top
 Profile Send private message  
Reply with quote  
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 29 posts ]  Go to page Previous  1, 2, 3  Next

All times are UTC - 6 hours [ DST ]


Who is online

Users browsing this forum: No registered users and 2 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
cron
Powered by phpBB® Forum Software © phpBB Group