The Blorb resolution chunk (‘Reso’) is now supported, allowing graphics in V6 games to be scaled appropriately for the interpreter’s window size. For Infocom’s V6 games this scaling is done as a simple, ‘blocky’ rescale (producing a result that matches the original appearance of these games), but for other games this is done with a proper rescaling algorithm that produces smooth results.
The V6 scaling item in the options dialog has been removed: when running an Infocom V6 game the interpreter automatically resizes the window to the largest multiple of 320x200 that fits on the screen.
If the game calls the restore or save opcodes in the form that does not bring up a file dialog, the interpreter now takes care to remove any characters which would change the directory in which the file is written.
A case where the check_unicode opcode would report that a character could not be printed, when in fact it could, has been fixed.
The output_stream opcode did not correctly handle its width argument in V6: this has been corrected by a patch from David Griffith.
I realise this isn’t really the place to ask, but I have downloaded the installer, and when I try to run it, it says I don’t have permission. This is a first! I’ve tried running as administrator and that fails in the same manner (how?). Even downloading the zip, extracting, and running Frotz directly doesn’t work (same error). I’m using Win 7 SP1, I’m the sole user with admin rights. I’ve tried also downloading the installer to different internal, external and remote drives with the same effect.
Hmmm, that’s odd - I’m using Windows 7 here too. Did it work with earlier versions of Windows Frotz, or is this the first time you’ve tried it? Can you post the error dialog, or is it a UAC one (i.e. with a darkened screen)?
That would suggest something is blocking access to the installer and executable at the kernel filesystem level. What are you using for anti-virus? Could that be blocking it? Is there anything else installed on your system to restrict access to files?
Spot on David: the AV software I am using (Avast) was causing the errors. I disable it, the installer runs fine and Frotz installs and runs fine also.
I probably wouldn’t have guessed the AV software was at fault (at least, not for a bit). I will look into reporting this to them (but I wonder how much good it will do?) in case anyone else has similar issues with it.
No, not a thing, however that may be my fault as I usually keep it in ‘silent/gaming mode’ so it throws no notifications (and updates itself silently in the background). I’ll put it back in noisy mode and try running the installer again this evening.
For what it is worth, when I disabled Avast and ran the installer, it finally worked, as I said above. Now, however, I can’t make it fail again! All combinations of ‘silent/gaming mode’ and disabling the whole program still result in the installer working as expected, and I cannot make the above errors appear again (which you may consider a good thing but an un-reproducible error is one of the worst).
I’m just going to shrug, roll my eyes a bit and mutter “Windows” under my breath…
This may sound like a dumb question, but I’m curious where Frotz stores its configuration data. It seems to preserve my settings between sessions, but I can’t figure out how… ah, nevermind, I found it in the registry. Is there a way to preserve a default configuration for the program without using the registry? (I keep my IF stuff on a USB stick so I can play in idle moments on any computer I’m at.)
Actually, that’s a pretty good point. I personally violently dislike programs invisibly storing their configuration somewhere and I’d much, much prefer a transparent config file. Plus, just like Matt_W said, it makes it more portable. Maybe if the existence of a config file in the Windows Frotz folder could take priority over any registry settings (or lack thereof)?
Having a config file in the program folder would violate Windows’ guidelines for how a program should behave (a program should never - and on modern versions of the OS is not allowed to - write in the program folder), but keeping a config file in AppData would be ok. That wouldn’t help with the USB-stick problem though.
So here’s another suggestion: Use AppData (or the registry, but if you’re doing config files it’s probably easier to switch completely to using config files - having both seems like a recipe for getting things messed up) if the program is normally installed (i.e. lives inside %ProgramFiles% - just remember that the name of that folder is localised and should never be hard coded), and use the program folder to store config data if it’s run from another location (e.g. a USB stick). That way you could get your needs met without having to edit a config file manually, or having the program behave badly (writing where it shouldn’t).
I’d think providing file-based configuration as a command-line option would be permissible, with a path to the configuration file included, similar to how you can launch Frotz with a story file. Glancing through the code, I actually might be able to manage a rewrite that would permit this, provided I can get the current code to compile. It should only require an additional step for command line parsing, and then a redirect in the application initialization routine. Getting it to error-check and fail gracefully would be much harder than the utility code. My C++ relevant to the Windows API is a bit rusty and it would take me quite a bit of time, but I might attempt it at some point. I’ll admit that I’m a programming wuss and usually just opt for C# when I write Windows code.
Note that I can currently run the Frotz installer, copy the installation folder to my USB stick and then uninstall Frotz on my system and it runs fine from the stick. I just have to re-apply settings on every machine I run it on, which isn’t really that big a deal.