What would it take to port an Infocom/Z-machine interpreter to PocketBook eReaders

[kakonema]

Originally Posted by wold

Way back Pocketbook organized an app development challenge of sorts. IIRC an Z-interpreter was a honorable mention, but I can't find the page anymore. It looked basic and probably came without its source anyway.

See also this Frotz for Kobo thread:
https://www.mobileread.com/forums/sh...42#post2711142

You mean this page?
https://pocketbook-free.sourceforge.net/en/index.shtml

[eline]

I am interested in this idea, because I've wanted to play IF on an e-ink screen for years.

I'm looking into what it would take to make a KOReader plugin.

[wold]

Originally Posted by kakonema

You mean this page?
https://pocketbook-free.sourceforge.net/en/index.shtml

Yes, the page was mentioned earlier.

That app is actually for a different format called QSP: https://www.ifwiki.org/QSP

Quest Soft Player is a text-based game developing system leaning towards the choice-based interface (there is an option to make a parser game). It includes a cross-platform player and a couple of utilities for game development.

Originally developed by Valeriy "Byte" Argunov, it has a big and stable Russian community.

[Biep]

Hi!
Any progress?
I'd *love* to have Gargoyle on my PocketBook Era. I used to have Frotz on my Kobo Aura One (R.I.P.), which allowed me to play basic games, but Gargoyle offers so much more!

Thanks for working on this!

P.S.: The list of third-party software on my PocketBook Era incluides QT 5.

[orontee]

Last version of the SDK includes Qt (see https://www.mobileread.com/forums/sh...d.php?t=361705), so now it should be possible to build Qt applications. (@Biep Qt5 libraries being installed on devices is not sufficient to build an application that depends on Qt5; It's only a requirement. In previous versions of the SDK, the build stuff for Qt apps was missing).

I thus decided to give up writing a pure "Inkview" front-end based and started to work on a mostly unchanged build of Gargoyle.

Detailed instructions to cross-compile garglk dependencies and try to build garglk itself are available in gargoyle-pocketbook-port Github project.

For dependencies it now looks good. But the built gargoyle contains hard-coded paths, the path to fonts and the path to interpreter. So at present time it fails to run any interpreter.

Remarks

• Sound support is disabled at build time since it adds a dependency on SDL2
• No idea what keyboard support we'll have once the paths are fixed...
• My knowledge of CMake is limited, and fixing the hard-coded paths problem is certainly trivial if one uses CMake procedure to install the application
• Harfbuzz and Freetype2 are complex libraries so don't expect things to work seamlessly after the hard-coded paths are fixed

[diegoocampo]

So great to see @orontee taking over this project. It was soon clear to me that without having previous experience with C/C++ development it was going to be a big project for me to even get started.

Maybe a separate thread to follow up with the progress on your Gargoyle for Pocketbook port would be good so people can see that there is clearly something on the works now?

[Biep]

Thanks for working on it! Don't expect any coding from me, but I am willing to help test anything you want (if it won't brick my Era or erase my stuff ��).

[orontee]

Compilation is almost good. I started the application and loaded a Z5 story. I am stuck after few screens since there's no onscreen keyboard.





Note that I tried to load a glorb file; Crash...

More positive, note that thanks to Harfbuzz the text rendering is very nice compared to the console rendering I first achieved with Frotz (cf. https://www.mobileread.com/forums/at...6&d=1704664918).

Given the Qt file chooser is really ugly, the screen isn't recognized with correct resolution and there's no onscreen keyboard, and I am not a Qt lover, I see no reason to keep using Qt. So I'll switch back porting gargoyle with my own UI based on Inkview SDK.

Be patient!

[diegoocampo]

Thanks for the update and those first screenshots of Gargoyle in a Pocketbook! that seems like great progress. An UI using Inkview will surely look cleaner. Looking forward to the next update.

[Biep]

����������
(If that doesn't show - it's applause.)
Thanks for the work you are putting in it!

[Biep]

Is there any other group programming for the PocketBook? They might have valuable knowledge.
I only know of KOReader, but they are not too focused on PocketBook as opposed to some other brands.

[Biep]

In conclusion things are going as expected, just time that's missing! I plan to work on this project next week.

I just found your repository.
How are things proceeding? Thanks for working on this!

You might get Steffen Bauer interested - if only to help you find out things about PocketBook programming that he found out the hard way.

[orontee]

Originally Posted by Biep

I just found your repository.
How are things proceeding? Thanks for working on this!

You might get Steffen Bauer interested - if only to help you find out things about PocketBook programming that he found out the hard way.

As you can see from the repository log I've not spent much time on this recently. But it's still on my todo list and I am really interested in that project, need time...

One technical blocker is that I've not succeeded in monitoring key pressed on the on-screen keyboard: No event received to check what key has been pressed. Without that users would have to press a key then enter key (after that key an event is received and one can fetch the entered string)... Not that user friendly. Also I've not found any keyboard layout with direction keys... Thus I realized that I should implement my own on-screen keyboard. Interesting but I need to design that work and I procrastinate...

I am worrying whether I should start to write a pomodoro application first (despite the smiley, I am serious).

[Biep]

Hasn't KOReader solved those problems?
I asked Steffen Bauer about reducing the time for making something a long press, and he told me he didn't know how to do it. I told him KOReader did it, and then he saw that KOReader monitored key presses and releases to be able to determine itself whether some press should be long or short.

And of course KOReader has a very pleasant, "programmable", on-screen keyboard, which you might just be able to copy.