The ARM64 build of 2022.1 launches on macOS Big Sur 11.6, but whenever I try to open a game file I get this error:
I think this is due to you having a garglk.ini file that youâve modified from a previous version of Gargoyle. Since the default fonts have changed, you still have the older fonts listed. There are fallback fonts for this case, but itâs not properly working on macOS (and Iâm pretty sure I know why.)
So, there are easy workarounds for this, at least.
The first is to download and install the fonts that are listed in your garglk.ini. One is obviously Liberation Mono, but you might also be missing the proportional font. You can see which fonts are set by running this in a terminal:
egrep '^(mono|prop)font' ~/garglk.ini
Then install those fonts to your system (e.g. with Font Book). You should be able to find copies in the 2019.1.1 source code, available at the releases page.
The other (easier) option is to modify your garglk.ini file, and set monofont and propfont as follows:
monofont Gargoyle Mono
propfont Gargoyle Serif
Iâll look at fixing the fallback fonts on macOS for the next release.
Thanks for this! The Intel Mac version works fine on my MBPro running Monterey.
Perhaps a silly question: is there any way to change the default font size and text/background color? The games I tried (even Beyond Zork, with its built-in mapping) displayed fine, but the font is a little small for my âold manâ eyes.
Thanks for everyoneâs hard work on this new version.
Yes! However, Gargoyle is configured via a text file rather than graphically. On Mac, you can go to the Gargoyle menu and select âPreferencesâ (or hit â,) to open the config file in a text editor.
To change the font size, find the propsize and monosize entries. These are the sizes of the proportional font and monospaced font.
For colors, find the section starting windowcolor. Colors are 24-bit hex values of RRGGBB (if you do a Google search for âcolor pickerâ, Google should pop one up for you, if you need to look up colors).
windowcolor is the background color. tcolor and gcolor are the foreground colors for text buffers and text grids (which almost always correspond to the ânormalâ window and the top status line, respectively). These look complex because they allow fine-grained control over colors for various text styles. You can use wildcards, though:
tcolor * e7e8e9 31363b
gcolor * e7e8e9 31363b
Using * sets values for all text styles. These have to either replace, or come after the other tcolor and gcolor entries, or theyâll be overwritten.
This is complex, and I keep thinking about writing a graphical config tool, but as of yet, itâs still just vaporware. Feel free to follow up with any questions you may have.
1 Like
As a follow-up, this reminded me that I was going to add a Wiki page with some âcolor themesâ, so to speak, now that 2022.1 supports the wildcard syntax. You can see some example themes here: https://github.com/garglk/garglk/wiki/Color-Themes
4 Likes
Thanks for this! Canât tell you what a relief it is not to squint at the screen any more!
With the color schemes though I found (for Git 1.2.9 anyway) I had to manually change the Heading and Subheading like so:
#=================================================
# Lectrote Slate
#================================================
windowcolor 4d4d4f
caretcolor ffffff
morecolor ffddaa
tcolor * ffffff 4d4d4f
tcolor 3 ffffff 4d4d4f # Header
tcolor 4 ffffff 4d4d4f # SubHeader
tcolor 8 ddffdd 4d4d4f
gcolor * 333333 ffffff
Otherwise they remained unaffected by tcolor *. This was true for all the color schemes. I was changing a copy of garglk.ini in my Home directory rather than in /usr, if that matters.
Huh; I assume that problem youâre seeing with header/subheader is that the colors are the defaults, i.e. black on white, instead of the expected white on gray? I ask because I canât reproduce this: headers and subheaders appear fine for me with the values from the Wiki.
Having garglk.ini in your home directory shouldnât be a problem at all (I assume youâre on macOS, as thatâs the only OS which looks in $HOME for garglk.ini).
If youâre willing to provide your garglk.ini, and let me know which macOS release youâre on, as well as a game that exhibits the problem, I can take a look and see if I can reproduce it.
Actually Iâm on linux mint 19.2 Tina, using the Mate desktop. I just fired up an old wip - but it was a standard .ulx file with no quirky extensions. Maybe I shouldâve said that itâs gargoyle-free Iâm using, since thatâs the only only one allowed in the repo for copyright reasons.
Hmmm. I see if I go open Jack Toresal and the secret letter (also a plain .ulx file) the instances of italic text are also still the default black text on white background, although the rest of the file looks fine now that Iâve manually changed the Heading and Subheading colors.
garglk.txt (8.1 KB)
(OK uploaded: had to change the extension to txt to allow the site to accept it.)
1 Like
Oops. Ignore the previous content of this post. I was still using 2019.1!
Is this version 2022.1, or is it the older 2019.1? If itâs 2019.1, the wildcard syntax wonât work there: youâll have to specify each style manually. 2022.1 introduced the wildcard syntax making âthemingâ somewhat easier. The themes will look the same in 2019.1 if you list out all the styles, itâs just more of a pain to do.
Ah, that would explain it. Repository apps are usually a version or two behind - just the sheer shortage of volunteer hours. Unfortunately there doesnât seem to be an âaboutâ menu, so I donât know how to find out the version (except that it says Git 1.2.9 in the top of the window.) But at least it doesnât look like itâs some mysterious bug thatâs going to come around and bite you later.
But thanks a lot for taking a look at it. And as I said: going to a dark theme was just the icing on the cake. The main triumph for me has been my eyes thanking me for enbiggening the text!
(Looks like Linux Mint 19.2 gets packages it doesnât provide directly from Ubuntu 18.04, which, along with Git 1.2.9, implies Gargoyle 2011.1.)
1 Like
An classic tool for checking duplicate executable names in a *nix environment in the path is whereis(1)
I change the name with one reflecting the release (in gargoyleâs case, the release yearâŠ), so in my case, I have:
pigi@Duilio:~$ garg
garg2019 garg22 gargoyle gargoyle2019 gargoyle-free
(whose illustrate well the usefulness of bashâs tab completion⊠
)
Best regards from Italy,
dott. Piergiorgio.
2 Likes
Is there anything new about the âreplayâ command? Looks like the filename of the .txt must not contain umlauts anymore (âWarning: unable to open the command script.â).
Is this Mac or another platform? There is a new file picker on all other platforms which might be the source of what youâre seeing. Can you give specifics on which platform and which Gargoyle download you used? And any idea if the filename is encoded in UTF-8, or some other encoding? Iâm not at a computer at the moment but will try to reproduce when I am.
I used the gargoyle-2022.1-windows-x86_64.exe from the Github page provided in the first post. The filename of my replay file contained an umlaut (like, Ă€Ă¶ĂŒĂĂĂĂ), and opening a file worked after I renamed it (removing the umlaut). Does that help?
Yes, thank you! I can reproduce this and itâs not an easy problem (at least for a Unix developer on Windows).
This problem exists in another fashion in the 2019.1 release of Gargoyle. 2019.1 will allow you to load your file properly, but it will not load a file called âą.txt. It also fails on È.txtâŠ
The problem is Unicode vs ANSI functions on Windows: C functions like fopen() are so-called ANSI functions on Windows, which donât support Unicode. Gargoyle cannot use Windows specific functions, meaning it gets the ANSI versions. Your umlauted filename is compatible with Windows ANSI functions, but something like È.txt is not.
With the latest Gargoyle release, filenames come from Qt and are converted with a function that assumes the target is UTF-8, which is not the case on Windows. I think I can get the 2019.1 behavior working on Windows using a different conversion function; this will also fail with the same names that 2019.1 failed with, but at least it wonât be a regression. I donât know if there is a way to get all possible filenames working when crossing the WIndows/C boundary.
Windows developers, if Iâve made a gross misstatement here, please correct me!
On a related note, presumably also for encoding reasons, filenames on Unix platforms which are not UTF-8 canât be loaded. I havenât tested whether this is a regression or identical to 2019.1, but Iâll look into that as well. Itâs not as big a deal since UTF-8 is more or less the standard on Unix these days.
1 Like
I think youâve got the gist of it. The detail is as ever a bit more complicated, so a longer explanation âŠ
C functions like fopen are invariably implemented in library code that comes with the compiler. Theyâre not the actual operating system call. On classic Unix the actual operating system call was open, I donât know if thatâs whatâs still used on Linux. On Windows there are two basic operating system calls for opening files, CreateFileA and CreateFileW.
For historical reasons most Windows calls that take strings have two forms, A (for ANSI, even though itâs not really ANSI, itâs whatever 8-bit character encoding is relevant for the process, known as the âcode pageâ) and W (for Wide, which originally meant UCS-2, and now means UTF-16).
The usual way that fopen is implemented is just as a simple call to the appropriate operating system call. I assume on Windows Gargoyle is built with MinGW? If so then fopen is a pretty simple call to CreateFileA, so the encoding of the string passed to fopen should match CreateFileAâs requirements, i.e. it should be in the code page for the process. It would be entirely possible to write a Windows implemention of fopen that assumed the input string was UTF-8, converted it to UTF-16 and then called CreateFileW. Thatâs how Unix-like systems on Windows like Cygwin tend to work.
The harder problem is then what to do about this. The simplest approach, and what Microsoft seem to want to do these days, is to just set the code page for the process to UTF-8. This can be done from code, or in the application manifest, see Use UTF-8 code pages in Windows apps - Windows apps | Microsoft Learn
The downside of this is that it only works on recent versions of Windows, from 2019 onwards (Windows 10 build 1903). If working well on older Windows versions matters to you then thatâs no good, though itâs worth considering now as most consumer PCs will be updated to at least that version. If you donât want to go that route, youâd need Windows specific code to do the right thing somewhere. As youâve noticed a relatively easy solution is to re-encode the string from UTF-8 to the processâ code page, and pass that to fopen, which will work for all characters in the code page. This is virtually always good enough for most uses.
2 Likes
Thank you for the detailed explanation! This really clears things up for me.
I assume on Windows Gargoyle is built with MinGW? If so then fopen is a pretty simple call to CreateFileA, so the encoding of the string passed to fopen should match CreateFileAâs requirements, i.e. it should be in the code page for the process.
Yes, thatâs correct. So it makes sense that only certain characters are working (if itâs Windows-1252 or Latin-1, characters like Ă€ and Ă« exist, but È and 
donât).
The harder problem is then what to do about this. The simplest approach, and what Microsoft seem to want to do these days, is to just set the code page for the process to UTF-8. This can be done from code, or in the application manifest, see Use UTF-8 code pages in Windows apps - Windows apps | Microsoft Docs
The downside of this is that it only works on recent versions of Windows, from 2019 onwards (Windows 10 build 1903). If working well on older Windows versions matters to you then thatâs no good, though itâs worth considering now as most consumer PCs will be updated to at least that version. If you donât want to go that route, youâd need Windows specific code to do the right thing somewhere. As youâve noticed a relatively easy solution is to re-encode the string from UTF-8 to the processâ code page, and pass that to fopen, which will work for all characters in the code page. This is virtually always good enough for most uses.
Supporting older versions, at least for the time being, is a high priority, but if itâs something that can be determined at runtime, thatâd be a fine solution; or if not, it may be useful to provide two versions for download, which is something weâve done for macOS in the past, to support older versions.
For the time being, it does sound like just converting to the current code page is acceptable, at least until I can get something more comprehensive done. I donât mind adding Windows-specific code at all. Whatâs one more #ifdef, after all?
Thanks again for the info. Iâve got a much better grasp of this area of Windows now.
Looking at this again, it seems like it canât be done in code, it can only be specified in the manifest. My current plan for my applications that need to use UTF-8 at some point is
- Convert between UTF-8 and the processâ current code page as needed in code. This works pretty well in everything Iâve worked on, and no-one has ever complained that characters outside of the code set canât be used.
- Specify UTF-8 in the manifest: that will be used for recent Windows versions, and ignored in old ones. If itâs used, the functions that convert between the current code page and UTF-8 will be effectively no-ops, so harmless. I havenât actually done this yet but will do it at some point.