Author Archives: The Regular Oddity

Frotz re-compiled (yay…)

I got stuck for an hour on one final problem I could not solve, even with Shaveen and Mohit’s help: an include file refused to be included. I could import it by explicitly giving its path, but the compiler refused to find it via the include path. In the end, I had to resort to explicitly adding the path. It’s very strange. I am baffled.

But I can now compile Frotz on my ETC computer as well as at home.

During the process, Mohit pointed out to me how to change Windows environment variables. It may be that we changed the right one but that Windows needs to be restarted for the changes to be effective. Still, addding the directory to the Visual C++ search path really should have been enough. I am slightly angry about the absurdity of it all.


I get more help from David Kinder

I got a new response from David Kind, the developer of Windows Frotz on the IF forum. I learned something that I consider important, mostly because I would never have figured it out without this project: the

  •  standard, built-in Windows unzip function can corrupt non-ASCII characters. (That was really a revelation.)

He also told me about a fix he added to the code to adapt to a change in the PNG API. The fix changes two lines of code, and one of them, I had actually figured out on my own last weekend. This may all be very minor, but really, the more problems I run into, the more I get to learn the messy parts of Windows development, the part you can’t learn in books.

It really time now for me to get working on actually looking into the virtual machine itself. I should get somewhere with that this weekend.

Compilation on ETC machine almost smooth

I really am glad in a way that I’ve had to many problems with Visual Studio. By actually trying to solve them, I’ve become a lot more comfortable with it.

In order to make good use of my newfound skills and in order to work on my project at EA, I decided yesterday to compile Windows Frotz on my ETC machine.

I’d like to reiterate at this stage that the regular Frotz is Unix-only, which means that it won’t natively work on Windows, unlike Linux and OS X. It will probably work on Windows with Cygwin but I don’t want to get into that at this stage.

I installed the version of Visual Studio that David Kinder, the developer of Windows Frotz recommended, Visual Studio 2008, after downloading it through Carnegie Mellon’s Dreamspark program. The project opened and, by then, I knew how to deal with the missing libraries. It really all went very smoothly until Visual Studio complained about missing a DirectX header, specifically dsound.h.

Based on what I found on the web, I had to install the DirectX Software Development Kit, or DXSDK. That proved to be very problematic. I need two header files that probably total 10 kilobytes in size, but Microsoft will only provide those as part of the whole DXSDK package, which is a 550 megabyte installation file that installs to 1.2 gigabyte package. And the installation process takes a while. And the installation invariably failed until I restarted my computer today.

I’m not near my ETC computer now, but I suppose that part of the compilation will resolve once I add the DirectX directory to my include path in Visual Studio.

What puzzles me greatly here, however, is that I don’t remember ever doing that on my Mac. And it’s not as if the DirectX SDK could have remained from a previous project: it was a completely fresh install of Windows. It’s not really a huge issue and I now have better understanding of how the DirectX SDK works. But it still bothers me that I can’t explain it.

SUCCESS! Frotz compiled!

I figured out that there was a file in the ScaleGfx package that I had never used: ScaleGfx.def . I figured out where it went (after several failed attempts) and I got a ScaleGfx.lib. Then Frotz compiled. I tried to open it, but then it asked for a ScaleGfx.dll. I spent quite a bit of time trying to compile that until I realized that the DLL had to be in the final distributed version of Frotz. There is really no need for me to compile it and doing so would just be inefficient. So I did just that: I got a final copy of Frotz, copied the DLL to the one I had compiled and IT WORKED! I have a working version of Frotz for Windows that I can most likely change! That part took a lot longer than I expected, but I really, strongly feel that I’ve learned a lot in the process. And it’s the sort of thing that you can’t learn in classes and books and tutorials: those are usually structured in such a way that you avoid precisely the problems that I had to confront here. I’m going to call it quits for today, but at last I have a base code I can change. Next, I’ll probably go back to the original Frotz and try to get some specific information out of it.

UPDATE: Yesterday, David Kent, the developer of Windows Frotz had in fact replied to my forum post. It’s great to know that he can be reached! I’ll try not to bother him too much, though.