Hello, everyone. I’m trying to do a small modification of Frotz for Windows for a university project. I’m a grad student at Carnegie Mellon (not in computer science, though). But I’m having a very, very hard time compiling Frotz for Windows. First of all, the only compiler I could find that even opens the project in a semblance of usable way is Visual Studio .NET 2003 and then there are still problem ahead.
The regular Frotz compiles very easily on Mac. But Frotz for Windows fails on numerous dependencies. I’ve been able to add most of them, but now it wants a static library called “scaleglx.lib” and I’m still trying to figure out how to get it that. All of this seems to relate to blorb and I’m looking to use Z-machine files only. Is there a way to remove glulx and blorb entirely? The source code is big and I can’t find anything that resembles a precompiler definition to do that.
If anyone can help, or if anyone knows if there’s a manual out there to get Frotz for Windows compiled, please let me know.
ScaleGfx.dll is a separate library that handles the scaling of graphics images, which is used for (very rare) Z-code version 6 games that use graphics, and for the “About this Game” dialog, which may involve a picture. It’s a separate library as it contains two versions of the scaling algorithm, one for non-SSE equiped processors, and one for SSE equipped ones, that is substantially faster. Testing indicated that Visual C++ never provided very good SSE support, so ScaleGfx.dll is compiled with GCC for Windows.
You could hack the source to avoid the use of ScaleGfx.dll, but there’s no easy way other than commenting out bits of code until it works. (Windows Frotz doesn’t support Glulx, but Blorb is more than just Glulx-specific.) The easiest fix is to get ScaleGfx.lib from my GitHub page: https://github.com/DavidKinder/Libraries/tree/master/scalegfx
intfiction.org never sent me an email about your reply, so I went on working at it and I got the .lib compiled. I couldn’t get the DLL to compile, and I ended up just copying it from the Windows Frotz zip archive. Now I have my own compiled version that actually works. I’ll try to modify it from here on.
Part of what I was trying to do was to work with a “real” full Windows open-source app and try to figure it out, so really I’m glad I got it to work the way I did.
But since you’re actually on this forum, how likely do you think it is that your source code will work with a recent version of Visual Studio? I couldn’t get anywhere with it when I first tried but now that I’m more familiar with it, I’d like to try again if I knew it was feasible.
I’m used to Unix and interpreted languages, so Windows Frotz is in many ways new grounds for me. I was looking for something that had C, C++, Windows, “real-world code” and story involved in it. Windows Frotz was the best candidate by far.
Thanks again for the reply and I’m sorry I didn’t notice it sooner.
Later Visual Studios should be fine. Here I generally use VS 2008, and if I load up the Windows Frotz project, it builds for me. If it doesn’t work for you, post what errors you get and I’ll see if I can help. The project is in VS 2002 format as I tend to use that for release builds as it will produce an executable that works on all Windows back as far as Windows 95.
I’ve included a screenshot that illustrates two problems I’ve with Windows Frotz. I’m now in the process of getting it to compile on another machine. This time, as per your recommendation, I’m using VS2008.
First of all, two of the localization projects don’t open. They didn’t work on any of the versions of Visual Studio that I’ve tried, and I think that includes 2003, 2008, 2010 and 2012. I’m not going to use them, but I thought you might like to know.
The piece of code that fails in the screenshot bothers me more. It says that things that are defined in a file that is included are not in fact defined. I don’t know why that is. On the other machine, I went around the problem by commenting out the whole “if” statement. I’m using the latest PNG libraries, but everything is undeniably defined in there. I checked.
For now, I can comment out the code again, but this too I thought you would like to know.
At a guess, this is because the program you’ve used to unzip the source archive has made a mess of the project file names, which I have seen before, notably with Windows’ built-in zip handling: it’s notable that the two translation DLLs with non-ASII characters in the name fail. I know 7-Zip unpacks the file correctly, or you could just try renaming the .vcproj files.
Anyway, these aren’t important (unless you want to modify the translations).
Ah, this is because the interface to libpng changed slightly, and the code in Windows Frotz has to be updated to match. I have done this in my GitHub repository (see https://github.com/DavidKinder/Windows-Frotz/commit/247c4ef4b74ce19ec3bd594026efa3690e94901a) but no release of Windows Frotz has been made since then. I’d suggest manually applying the above linked change.
This is EXACTLY the sort of thing I wanted to know. So far, I’ve mostly developed on Unix. I’m not going to use the localization project, but it would have taken me forever (if ever) to realize that Windows unzipping could have had something to do with messing up the non-ASCII characters.
This is the sort of thing you don’t learn it books and that I’m trying to pick up now. Even before I started posting on this forum, there are many, many small things like that I’ve learned thanks to Windows Frotz.
I’ll try not to bother you any more than I have to, but for these two things, I was just wondering why the were the way they were.
I’ll apply the changes. If I ever start over again, I’ll probably start from the Github version, rather than the website zip file.
I remember from my previous attempt, now, the png_set_expand_grey_1_2_4_to_8 thing, I’d actually managed to figure out from the PNG readme file. But the first one, I couldn’t makes sense of.
