goods news, bad news

So, after some more playing, it turns out that the game I was testing the 16-bit interpreter with, the Vault of Hugo, won't restart even if you only use the standard library (also, a small Roodylib game will still restart in the 16-bit interpreter). If I drop the HugoFix debugging suite and identical and plural object support from Vault of Hugo, the game will work, but add either one of those and it's back to shenanigans. I take this to mean that the issue is deeper than anything I can do to fix.

For the most part, not being able to provide games for the 16-bit interpreters isn't a big loss. It'd really only be useful for things like the @ party thing mentioned in the last post (although it's still very possible that IF doesn't even need to meet the 1992 requirement) or targeting other real die-hard retro fans.

When I do the @ party thing, I'd like to go somewhat hardcore. I think that means that I'll probably have to use ZIL for that, which is cool, but my only regret is that it's probably too late this year for me to write a ZIL game in time for @ party. Still, next year, the @ party might be a great thing for a ZIL competition to piggyback on to.

not surprising, but disappointing

A recent post on the int-fiction forums informed me that @ party demoscene gathering has continued to invite interactive fiction into its yearly competition. I had considered submitting something a couple years ago when I first heard about it (although at the time, it had one of those wordings where Inform games were preferred). Anyhow, not having heard about it at all since then, I had assumed that they had dropped the IF invitation.

I don't exactly have a game idea ready as much as a malnourished concept. We'll see if I turn it into something worthwhile.

While the Interactive Fiction section of the @ party rules doesn't request any particular requirements, one of the other ones requests that submissions be run on computers available in 1992 so I'm approaching it from the same angle. Out of curiosity, I tried compiling a couple games to see how the current Roodylib works with the 16 bit and simple Hugo interpreters.

Disappointingly, there were two problems that popped out at me right away. For one thing, the status line wasn't being drawn properly in the 16 bit interpreter. For another thing, both interpreters would hang when I tried to restart the game. That problem wasn't just Roodylib's DoRestart's fault, as replacing it with the original did not help. I think the interpreters were just out of memory.

As far as PrintStatusLine stuff goes, it seems that the 16 bit interpreter also miscalculates the screenwidth, just as the simple interpreter does. The actual screenwidth is one character shorter than the detected screenwidth (in the simple interpreter, it is two characters short). Possibly, this is DOSbox's fault, or possibly, print to works differently in each of these interpreters. Also, Roodylib's latest PrintStatusLine also doesn't work in the DOS 32-bit interpreter, either, but I, admittedly, do some strange window-drawing stuff in that. It works fine with the previous PrintStatusLine.

Anyhow, making Roodylib compile a game that works with all of these interpreters is probably impossible, especially since the 16 bit interpreter considers itself a non-MINIMAL_INTERFACE interpreter. Still, I put some stuff in Roodylib that specifically helps out interpreters like the simple interpreter, so it'd be a shame to stop supporting it altogether. I'm going to try to go through Roodylib and provide a switch for turning off unnecessary features, and hopefully the resulting games will still work with older interpreters. Authors will unfortunately have to compile multiple versions of their games (if they wish to support old DOS interpreters), but I don't really see a way around it.

That said, games compiled with the minimum-feature Roodylib probably won't work with extensions like newconverse.h, which is another shame. Oh well.

Update: Ok, it's not so much that the DOS 'terps are detecting the wrong width (although the simple interpreter still is short by one character), it's just that when they write the last character to the line, it automatically goes to the next line, whereas in the Windows 'terp, you can stop right there. Right now, I'm thinking that I'm going to make the Infocom-style status line (two spaces on the left and right sides) the default, regardless of whether you set the DESCFORM_F flag. Again, not optimal, but better than trying to code for every possible interpreter.