I have both Clang and Visual Studio on windows, but I can’t figure out how to compile everything. The GitHub repo says there are included prebuilt binaries for Windows, Mac and Linux, but the only thing in the prebuilt directory is a compiled version of Windows GLK. The only prebuilt binaries I can find are versions from Linus’s website.
1 Like
from memory, the prebuilt binaries are in the releases.
1 Like
Yeah, unfortunately Dialog is currently not tested for compiling on Windows. It should work fine with something like Clang, but for the official releases we cross-compile the Windows binaries on a Linux machine.
For the most recent official release (1a/01), you can find those binaries on the “Releases” page of the Github. (For the bleeding-edge version, 1b/01-dev, we also have Windows binaries on Github, but they’re harder to find.) If you have something like MSYS or Cygwin that provides POSIX utilities, you should also be able to make dialogc.exe dgdebug.exe in the /src directory, or look at src/Makefile to see what linking information to put into Visual Studio. It’s all portable ANSI C, so it should work just fine.
There is a repository in there that describes how to compile it with Visual Studio 2022 that I made a couple of years ago. Haven’t tried it with VS2026.
2 Likes
Never mind y’all, got it compiled nicely with the MinGW cross compilers on Fedora 42 via WSL. The Aa-machine tools, too, though Aamrun took ages for me to figure out how to compile since PKG (and its forks as well, as far as I can tell) and nexe are deprecated and don’t work with modern versions of Node. Had to install node 16.2 just to get the aa-machine interpreter to compile.
1 Like
Yeah, aamrun is…kind of a mess. No, not “kind of”, just a mess. The intent is that end users never need to build that one themselves, because if you have Node to build it, then you can just as easily run node nodefrontend.js which will do exactly the same thing without a ton of dependencies. Aamrun is only for people who don’t have Node at all, who download the release zip and want to use it without installing anything else. I should update the readme to make that clearer.
(We use @yao-pkg/pkg to build it because the vercel one is, as you saw, discontinued; the yao-pkg one seems to still be maintained.)
Also, just thought of something. I don’t know if Lectrote has Aa-machine support or not; if it doesn’t, then it definitely should. A virtual machine programmed in Javascript as its primary language is an oddity, and yet it works, so it’s basically begging to be added to Lectrote.
Lectrote does not. I would be happy to accept a PR.
It’ll probably be a nuisance, though. Everything in Lectrote goes through the same Glk API, without platform-specific hacks available.
A virtual machine programmed in Javascript as its primary language is an oddity
I’m not sure what you mean here. The Å-machine is another VM with a Javascript interpreter implementation.
1 Like
The debugger uses Glk so maybe eventually we can get the Å-machine into Emglken (and thereby into Lectrote).
The Dialog debugger doesn’t support all of Dialog’s output features though. I suspect some of them, like inline status areas, are fundamentally incompatible with Glk. Dialog’s styling features expose all of CSS to the game author, and all of those features are thus supported by the Å-machine web interpreter; it would seem frustrating to end up with a web-based interpreter which should be capable of following the styling specified in the story file but can’t because an intermediate step (Glk) can’t support it.
2 Likes
Maybe if I implement my CSS proposal…
1 Like