[Semi-solved] Building ScummVM on macOS 10.14 Mojave

[Lillesvamp]

I asked about this on IRC some time ago, and Criezy tried to help me, but had no trouble when building it on his own Mojave system. After trying different things to no avail, I thought I might just as well ask here, too.

Basically, I have followed the instructions on the wiki, with all engines enabled, and it compiles, but the ScummGlk engine refuses to find the fonts.dat file no matter where I put it, and Zork Grand Inquisitor crashes after the intro movie with Assertion failed: (scale > 0.0f), function setPanoramaScale, file engines/zvision/graphics/render_table.cpp, line 219.

Both work fine with the daily builds, and they used to work fine for me when I compiled ScummVM myself on 10.12.

This is on a MacBook Pro (Retina, 15 inches, mid-2014) with macOS 10.14.3 with Intel Iris Pro graphics and the HD formatted to APFS, Xcode 10.1 with (the default) Apple Clang 1000.11.45.5. I'm using Homebrew for all dependencies.

Full Terminal output from configure and make here.

Note that building with the Xcode IDE also seems to be broken on Mojave, but that is the subject of another post.

[dreammaster]

At least as far as ScummGlk is concerned, I's possible that the paths for your manually compiled version are different than the daily builds you tried. Tonight (PST) I'll do something that was suggested to me earlier, but I forgot to do.. I'll make the error messages for fonts loading more descriptive, so that you'll be able to tell whether it couldn't find a fonts.dat at all, it found one that was malforned (i.e. from some other application or game), or whether the fonts version was incorrect (i.e. it found an earlier version). That'll at least give you a better guide at what's going on.

[Lillesvamp]

Thanks for replying! I've tried setting the extra paths, deleting and recreating the settings, and copying the fonts.dat file to every location I can think of, but that doesn't mean I haven't missed something obvious. It's happened before.

A more informative error message sounds helpful!

[Lillesvamp]

Right, now it says:

Out of date fonts. Expected at least 1,200000, but got version 1,000000!

Which is kind of weird, as I have repeatedly tried downloading the fonts.dat file manually from the Github repository, deleting it and downloading it again with git checkout, then tried copying it from the Resources folder of the buildbot builds. I've placed it in the scummvm root directory, in the Zork Zero game directory and set the extra path to the dists/engine-data folder. I've tried various z-code games, and they all work in the daily buildbot builds, but give the same error in my build.

EDIT: I commented out the font.dat version test on line 89 in engines/glk/screen.cpp, and after that Zork Zero worked just fine. I also tried a couple of other z-code games, The Awakening and Not Just An Ordinary Ballerina. Now I got a different error:

Assertion failed: (_defaultForeground != -1 && _defaultBackground != -1), function initialize, file engines/glk/frotz/glk_interface.cpp, line 169.

So I commented out the assert on that line as well, and now they all seem to run flawlessly!

[Praetorian]

Right, now it says:

Out of date fonts. Expected at least 1,200000, but got version 1,000000!

Which is kind of weird, as I have repeatedly tried downloading the fonts.dat file manually from the Github repository, deleting it and downloading it again with git checkout, then tried copying it from the Resources folder of the buildbot builds. I've placed it in the scummvm root directory, in the Zork Zero game directory and set the extra path to the dists/engine-data folder. I've tried various z-code games, and they all work in the daily buildbot builds, but give the same error in my build.

This suggests that the atof() command in the fonts.dat version check is not behaving as expected in your system; it seems to be returning the integer part only instead of the full double number.

[Lillesvamp]

That's really weird, isn't it?

I found this question on Stack Overflow and thought that I was getting somewhere, but as far as I can tell, none of the advice there makes any difference at all. Well, except for the last one:

Code: Select all

export CPATH=/Library/Developer/CommandLineTools/usr/include/c++/v1

which makes Configure unable to find many of the Homebrew-installed dependencies, and therefore disables several engines. Anyway, that question seems to mostly concern compiling with GCC, and I'm using Clang.

[Praetorian]

That's really weird, isn't it?

I found this question on Stack Overflow and thought that I was getting somewhere, but as far as I can tell, none of the advice there makes any difference at all. Well, except for the last one:

Code: Select all

export CPATH=/Library/Developer/CommandLineTools/usr/include/c++/v1

which makes Configure unable to find many of the Homebrew-installed dependencies, and therefore disables several engines. Anyway, that question seems to mostly concern compiling with GCC, and I'm using Clang.

I think the atof() issue could be a system locale setting that eg uses comma (,) instead of dot (.) as a decimal point where that particular atof() expects a dot to function correctly (since the version.txt in fonts.dat contains the string "1.2").

edit: it could be linked to what this old (closed) issue refers to: https://bugs.scummvm.org/ticket/6434

[Lillesvamp]

I think the atof() issue could be a system locale setting that eg uses comma (,) instead of dot (.) as a decimal point where that particular atof() expects a dot to function correctly (since the version.txt in fonts.dat contains the string "1.2").

Bingo! That seems to be the problem. My system is set to Swedish, which uses a decimal comma, and if I change it to English it works without a recompile. I wonder what about Mojave made this different. Google finds some reports of locale bugs in Mojave, but no details or obvious solutions. Some of the ideas about how to make the code more locale-independent in the discussion of that old ticket sound promising, though.

[dreammaster]

Bingo! That seems to be the problem. My system is set to Swedish, which uses a decimal comma, and if I change it to English it works without a recompile. I wonder what about Mojave made this different. Google finds some reports of locale bugs in Mojave, but no details or obvious solutions. Some of the ideas about how to make the code more locale-independent in the discussion of that old ticket sound promising, though.

Glad you both were able to identify the problem. I've changed the version string parsing code to no longer rely on atof. Though it does make me wonder if there are any other game engines using atof that might suffer similar problems. I'm at work right now, so I don't have access to my ScummVM installation to check.

As for the other problem you encountered with the assert. It may well be that you're using a 32-bit display mode. The engine has support for using such modes if the default 16-bit mode isn't available. In which case, it would be interesting to try putting some lines like warning("FG: %u BG: %u", _defaultForeground, _defaultBackground); at the end of UserOptions::UserOptions constructor in engines/glk/frotz/config.cpp. My guess is that the RGBToColor is converting the default white background color to an RGBA of $FFFFFFFF, which gets treated as -1.

This isn't actually so much of a problem now. Originally, -1 through -4 was used by the GLK backend for special cases like transparent, or "cursor color". I since refactored the constants to use a range of $7FFFFFFF to $7FFFFFFA.. since they fit in a standard int field. In theory, even in 32-bit display modes, the alpha should never be anything other than $FF, so $7F should be pretty safe. I'll do some further refactoring tonight to remove the assert and convert some of the outstanding int fields for colors to unsigned int just for consistency

[Lillesvamp]

Thanks for looking at this! Just for clarification, setting the system language to English fixed all the problems I mentioned. The ZGI scale > 0.0f assert a̶s̶ ̶w̶e̶l̶l̶ ̶a̶s̶ ̶t̶h̶e̶ ̶G̶l̶k̶ ̶_̶d̶e̶f̶a̶u̶l̶t̶F̶o̶r̶e̶g̶r̶o̶u̶n̶d̶ ̶!̶=̶ ̶-̶1̶ ̶&̶&̶ ̶_̶d̶e̶f̶a̶u̶l̶t̶B̶a̶c̶k̶g̶r̶o̶u̶n̶d̶ ̶!̶=̶ ̶-̶1̶ ̶a̶s̶s̶e̶r̶t̶.̶

EDIT: Nope, I was confused. The _defaultForeground != -1 && _defaultBackground != -1 assert still occurs with English system language. For the reson you explained, no doubt.

EDIT2: It seems that strikethrough text is not implemented on this forum, or am I missing something? The unicode thing I tried to do above doesn't look great.

I searched the ScummVM source for atof, and it didn't seem to be too common. It looked like it might cause trouble in Wintermute, but I tried a couple of games in that engine (Rosemary and Chivalry) with the system set to Swedish, and they seemed to work fine.

EDIT 3: I created ticket #10897 for the remaining Zvision issue.