V6 Z-machine games cause assert() crashes

[frotz]

As my username suggests, I'm the custodian of Frotz these days. I'm trying to understand how Dreammaster added Frotz as a sub-engine of Scummvm, in particular how V6 games are handled and how to allow the player to highlight and copy text. These are two ongoing problems in getting the SDL interface of Frotz working correctly. For V6, some of Infocom's games use what's called an adaptive palette. This means that the interpreter is expected to change the palette of the image depending on what was already drawn.

I never fully understood how these two things are supposed to be done and I'm hoping I can copy Dreammaster's work in this regard. Unfortunately, when I try to use Scummvm to load a V6 game, I get assert() crashes. For Zork Zero, it's this:

Code: Select all

$ scummvm 
WARNING: SDL mixer output buffer size: 512 differs from desired: 1024!
User picked target 'zork0' (gameid 'zork0')...
  Looking for a plugin supporting this gameid... ScummGlk
  Starting 'Zork Zero: The Revenge of Megaboz'
scummvm: ./common/rect.h:102: Common::Rect::Rect(int16, int16, int16, int16): Assertion `isValidRect()' failed.
Aborted

For Arthur, it's this:

Code: Select all

$ scummvm 
WARNING: SDL mixer output buffer size: 512 differs from desired: 1024!
User picked target 'questforexcalibur' (gameid 'questforexcalibur')...
  Looking for a plugin supporting this gameid... ScummGlk
  Starting 'Arthur: The Quest for Excalibur'
scummvm: ./engines/glk/frotz/windows.h:138: Glk::Frotz::Window::operator Glk::winid_t() const: Assertion `_win' failed.
Aborted

Which commit was used to load Zork Zero as shown on Dreammaster's blog at http://dm-notes.blogspot.com/?

In case anyone's curious, the audio subsystem has been overhauled, thanks to Mark McCurry, and is working nicely. There are just a few loose ends, like the adaptive palette problem and copying text that's standing in the way of a new release.

[digitall]

Firstly as an IF fan myself for quite a while, especially of Z Machine games, thanks for maintaining frotz!

Right then... I am not an expert on our GLK engine. That would be dreammaster, but some quite triage questions:
1. What version of ScummVM did you test with? If you are not sure this is shown on the launcher or via scummvm -v command line.
2. You should be testing with either self-built from the latest git master or use the nightly builds from our buildbot.

I am not sure what commit dreammaster used for that, but he says January 7th which was probably commit 9b7866442b477fe9376896fbf167622514700320

Since I have the Zork Anthology which has a copy of Zork Zero, I will do a quick test to see if I can replicate the issue you are seeing here and bisect if this
is a regression.

[dreammaster]

Hey,kudos to all your previous work on Frotz. It's awesome! As I mentioned in channel, I reviewed the Git history and reverted one of the later commits I'd made that broke v6 compatibility. With that, Zork 0 at least works again. So you can either compile the latest code or shortly use a daily build. But make sure to have the graphics files present, because the engine currently throws a wobbly if you don't.

Also as I mentioned in channel, Zork 0 was my focus for the first graphical V6 game I got working. After that, I moved onto working on Shogun, but got frustrated trying to get it to work like the original, particularly given the need to use the Glk infrastructure. In the end, I decided to take a hiatus from working on it, and working on some of the other subengines. So as it stands, Zork 0 is likely completeable, but the others aren't likely to properly start up. But on the plus side, at least Zork 0 looks even better than the partial display in my previous blog posting

[frotz]

I'm trying with the absolute latest from the repo. I then did a pull of the new changes. No change in crash messages. Checked out 9b7866442b477fe9376896fbf167622514700320 and got the same crashes.

I have the game files as zork0.z6 and then the graphics are contained in zork0.blb. The blorb file comes from the IF Archive. Frotz as imported into Scummvm appears to only look for .zblorb files.

[Lillesvamp]

The assert is caused by the .blb file. My GOG version of Zork Zero works fine with latest ScummVM, reading the graphics from the ZORK0.MG1 file I guess, but if I add the blorb file from http://www.ifarchive.org/indexes/if-arc ... blorb.html to the game directory, I get the isValidRect() assert. Delete the zork0.blb and it works again.

[dreammaster]

I'm looking into the problem now. Looking back, I did all my testing using the MG1 files, so I don't think I ever verified that the if-archive Blorb files worked properly.

[dreammaster]

Okay, I got a problem with the placeholder rect handling sorted out, and the game now works with Blorb files. I also added some extra logic so that it'll also automatically scan for the if-archive Blorb filenames, so you won't need to explicitly ensure that the filenames match for it to be detected. There's a problem with background transparency that'll still need to be looked into, but at the game is properly starting with the Blorb file now.

[frotz]

Thanks. Now Zork Zero is loading properly, but the initial images using an adaptive palette are not rendered at all. This seems to be how Scummvm has been rendering the game with the original .mg1 file. Since I switched Frotz to using only Blorb instead of Infocom's audio and graphic files, it has been able to render all graphics, but the colors for images using adaptive palettes are wrong. So, it looks like I'm a little further on than you are here. As I've been tinkering with things, I find that I now have colors rewritten correctly, but now am having assorted double-free and corruption problems.

Arthur is still crashing Scummvm on startup with an assert on _win failing regardless of if the .mg1 file is present or not.

For getting things right on your end, you should read these documents: https://eblong.com/zarf/blorb/blorb.html and
https://www.ifarchive.org/if-archive/pr ... ension.txt. The first one describes the Blorb standard and the second describes how to deal with graphical oddities of the V6 games within the confines of the Blorb standard.


See https://gitlab.com/DavidGriffith/frotz/issues/116 and the sdl-adaptive branch if anyone is curious.

[dreammaster]

Thanks for the links. Turns out the transparency problem was pretty simple to fix, so now the pillars in Zork Zero now display correctly. There is, however, still issues with the compass rose pictures not displaying correctly. I'll need to look into how the data for their images differs in the MG1 vs the Blorb files. Hopefully it'll be another simple thing to fix. As for Arthur, yeh it figures. I was getting a lot of similar asserts from Shogun, due to various window-related functions being called by the code prior to a Glk window being created.. Glk windows need to be a specific type (text grid, buffer, or graphics), so I had various troubles related to pre-creating them, only to later have to recreate them with a new type. I was sort of in the process of creating a window virtualization class that could cache the properties until a Glk window could be created when I stalled out and decided to work on other sub-engines for a while.

[frotz]

Andrew Plotkin's intent for Glk and Glulx was to breach the limitations of the VM being 16-bits and to do things Right (tm) where Infocom did things Wrong (tm). I seem to recall him describing Infocom's design for V6 as very kludgy at its very foundation. This led to inherent incompatibilities of Glk with V6. I don't know how absolute the incompatibilities are or exactly how they manifest, but the issue is something you should be considering as you work on integrating Frotz into ScummVM.

As other interpreters implemented Glk for IO, I declined to do this to Frotz because I want to preserve a means for people to play V6 games on modern computers. I pondered adding Glk support as another IO library just for fun. From what I've seen you do here, it seems doable. After I clear out some other things like the upcoming release with the audio overhaul, I'd like to explore the idea of copying your Glk interface code back into Unix Frotz proper.

[frotz]

The problems you're having with the compass rose is that some images have an adaptive palette that changes according to whatever else is loaded at the time. I'm currently flailing around with David Kinder's Windows Frotz code to figure out exactly how he implemented the palette changes and port it from C++ to regular C. The Blorb extension I described above includes information on how to determine which images need to be fixed.

[dreammaster]

The problems you're having with the compass rose is that some images have an adaptive palette that changes according to whatever else is loaded at the time.

You were right. With some extra logic to load the list and handle the palette copying, the Blorb version of Zork Zero now renders the compass rose correctly. Thanks for the help.

[frotz]

The problems you're having with the compass rose is that some images have an adaptive palette that changes according to whatever else is loaded at the time.

You were right. With some extra logic to load the list and handle the palette copying, the Blorb version of Zork Zero now renders the compass rose correctly. Thanks for the help.

Congrats on getting that working. Unfortunately I'm still having problems related to translating David Kinder's work and it looks like your changes don't really translate to talking directly to the SDL library. PM sent.