New ScummGlk engine added to ScummVM

This is to announcement that an implementation of the Glk API has just been merged into the master last weekend, and is now available in daily builds from the ScummVM website. At the moment, only ScottFree and Frotz are implemented as sub-engines under the API; the others will be gradually added in as time goes by. Part of the process will be cleaning up the various codebases and conforming them to the ScummVM coding standards.

Finally, I’m able to play my classic Infocom favourites directly from ScummVM :smiley:

1 Like

Well that’s a long time coming! You must know as well as I, I can see your avatar right there in the SCUMMVM forums also, 8-10 years ago… what made them change their minds? … e2acaba287

Well, attitudes have somewhat relaxed over time, for which I’m thankful. Once the decision to allow RPGs to be included was made, there was, IMHO, a gradual shift in thinking of ScummVM more in terms of a platform for adventures/stories, rather than just narrowly point and click adventures. Plus, the ScummVM is more flexible now than it was back then… it now properly supports Unicode, TrueType fonts, and the clipboard. Which makes it easier to include the bells and whistles similar to other standalone systems.

Does this mean that there are bug fixes and compatibility improvements for ScottFree with SAGA games?

Depends what you mean by compatibility improvements. The engine will run on all the different systems and consoles ScummVM supports. It also supports auto detection of supported games, and ScummVM’s enhanced save dialog. But if anyone wants to test the games, any found bugs can be reported on, and they’ll be looked into.

Actually, to be specific, the autodetection only currently recognizes the freely available games. The current list can be found here. But any other valid game with a .saga extension will still at least be detected. even if it can’t give it a known name.

Since you posted that list I had to go take a gander, first going “yup, there’s all the Scott Adams games, and yup, there’s all the Digital Fantasia games”, then going “oh huh, didn’t know about the Bruce Hansen games”, then going "didn’t someone write one a few years ago for the IFComp… ah yes, “R (Pron: Arrr…)”… then finally going “OK, does someone maintain a master list” and finding … system,11/

Is it fair to expect that those all will be / should be / are supported? (And are there any missing from the list? I gather that a number of people rolled their own games in its format following the publication of Pirate Adventure source code in the Dec 1980 BYTE Magazine…)

(Sorry, every time I see new support added for SCUMMVM my first impulse is to ponder “quick, how many borderline titles can we sneak in under this opening?”)

(Now I’m wondering about Jyym Pearson’s Other-Ventures and Scott Adams’ own Return to Pirate’s Island 2 in 2000.)

(This fixation is nutty, I don’t even enjoy that vintage of text adventure games!)

I was talking about the bugs in ScottFree release 1.14 for Unix and Linux, by Alan Cox, and the differences between the game loop of ScottFree and the original drivers.
Robert Schneck talks about some ScottFree bugs in the README file of his Asfdcurs interpreter: asfdcurs.tar.gz->README->Changes from ScottFree revision 1.14

I had found other problems, but a long time ago that’s why I have to look at it again.
For example, with ScotFree, you can’t read the time limit (for the artificial light source) in alternate counter eight (8). With Adventure interpreter version 8.5 for TRS-80, you can.
In TRS-80 interpreter, Automatic Actions are ignored if they are placed after Player Input Actions; but not with ScottFree. This is the case in Cloak of Darkness, which is not playable on TRS-80 interpreter.
And other things.

I don’t see why not. I’d just need to find a reputable source for them if they’re free. Or, if not, for someone to give me a list of the games’ filesizes and md5 of the first 5000 bytes.

Thanks for letting me now. I’d never looked at the Scott Adams games/format until working on ScummGlk, so I wasn’t aware of any extant issues with ScottFree. I’ll definitely look into it further when I get back from my Christmas holidays.

I’m not sure on the flexibility of ScummVM in handling story files (or perhaps is too long time I don’t follow its development…) but I wonder how an engine designed for point-n-click IF can handle parser-based story files.

Best regards from Italy,
dott. Piergiorgio.

I gave it a quick test, but it doesn’t seem to work on MacOS.

I got the latest dev build (dated “Dec 16”). I created a folder containing zork1.z5 and used the “Add Game” button to select the folder. (Not obvious to a scummvm newbie…) The app recognizes it and shows it in the library (“Zork I: The Great Underground Empire”), but when I hit “Start”, the app crashes.

You’re probably having a similar issue that another user had, in that the particular daily build doesn’t include a needed datafile. Try downloading the fonts.dat file from here and putting in either the same folder as the game or executable.

Fairly well in my admittedly biased opinion. This isn’t the first engine to have heavy use of text. The Sierra AGI games, for example, use a text parser, as do so some of the earlier SCI games. Starship Titanic also has a fairly heavy text parser for conversation with the game’s bots. Obviously, it would be unfeasible to play these games on a console without a keyboard, but that applies to the Sierra games just as much as ScummGlk.

About the only area I’m not entirely happy with is that of resizing the game window (in windowed mode). If you use the OpenGL renderer in ScummVM, it allows you to resize the window. But this is just a stretching done on the output surface, not the screen my engine renders text on. Thus, if you do increase after starting a game, it will only increase the size of the text, rather than keeping it the same size and increasing the number of lines and columns available.

A tester for my new ScummGlk engine reported a somewhat interesting problem playing Beyond Zork. In the attached save there’s an endurance indicator visible, and if you W, SW, SW, then the text description fills up the remaining area of the info box, and it displays a ‘[MORE]’ and Use ‘down arrow’ to scroll. However, it doesn’t seem possible to do so, since the up/down arrows are used to scroll through the history of entered lines in Frotz. I’ve tried as well using Windows Frotz, and it also doesn’t work, indicating it’s an issue with Frotz itself.

I’m wondering if anyone has any idea how the original Beyond Zork interpreter handled this? Is a down arrow key meant to interrupt and abort the read line with a special return value to indicate it? Or is the arrow key down meant to some kind of special processing without interrupting the line entry that Frotz currently doesn’t implement?

Didn’t help. I’ll try a different daily build sometime in the future.

Nowadays of course the convention is to scroll through command history with the up and down arrows, but Infocom interpreters never did such a thing. The up and down arrows in Infocom’s Beyond Zork interpreters did just what the prompt indicates, paged the description window. But Frotz lets you do that with the Page Down and Page Up keys.