Impersonal Daydream

Hello Scummers!
I apologise if this post is of no interest to you, but It pleased me and I thought I should tell you all about it :p

A while ago I was made aware the Personal Nightmare (DOS) was shipped out with a corrupted '71.out' file, sadly this corrupted file made the game difficult to complete under DOS, and impossible under ScummVM at least without the development of an ugly hack to work around the Vicarage section.
After a couple of hours of searching it became clear that the patch Horrorsoft was rumoured to have developed didnt exist in any form on the internet.
After speaking with Kirben I learned that he was in contact with the developers of the game and was awaiting responses from Alan Bridgman to see whether he had an uncorrupted version of the game.
Contact was also attempted with LurkerScum from the ScummVM forums who seemed to know a little bit about the patch that was released for the game. unfortunately it turned out he was using a BugMeNot login.
Later I found out that he had a real forum account(Potent1), but still didnt recieve a response.
As a side project I spent a while looking at the files, trying to compare the atari and amiga 71.IN
files with the PC 71.out file. while it was clear there was a large similarity this was a fruitless task, they just were not similar enough.
I briefly spoke with Kirben again who informed me that the reason for the lack of similarity in the files was due to the compression and graphical differences between the games(PC is EGA, others are VGA)

I decided that it would be a good idea to look at the files again. this time I started by loading up the PC version but replacing the 71.out file with a renamed 71.in file from the Atari ST version.

sadly this didnt work, and I was soon to find out why!
I was using DosBox with the debugger enabled, this allows you to see which files are opened from the hdd, The game was choking on '72.out'!!

after another brief search for a patch I decided to replace the PC 72.out file with a renamed 72.IN file from the ST version again.

To my delight this was quite successful, DosBox started the Vicarage section!



And in ScummVM things were looking even better :)



This gave me some hope, but was not an ideal solution, because the PC game differs quite a bit graphically from the Amiga and ST versions, Kirben informed me that the palettes were not calculated in the same way too. I ditched this idea and sat with my fingers crossed for an official patch from the guys at AdventureSoft.

I got bored today and noticed that Kirben had just committed a patch for the uncompressed PC files. Im still yet to understand why HorrorSoft packaged the PC game with a data file decompressor, especially when the uncompressed files dont work with the interpreter.
But Im sure glad they did.

I decided to try and compare the uncompressed files, so I had to trick the unpacking tool into uncompressing the Atari ST versions '72.IN' file, just with a simple rename :p
I also uncompressed the PC version.

upon opening the two files in a hex editor I was able to see that the two files headers looked very similar, but that the PC version was missing a few bytes that were present in the Amiga and ST versions. I didnt think much of this but figured that I would try to patch the PC version myself.
The file header differs by 4 bytes, namely : 00 00 01 A8. I inserted those bytes into the beginning of the PC file and fired up ScummVM, being hopeful I crossed my fingers as I clicked Load

Heres an image of the result, Its the best current solution as it uses the original data, although an official patch would be better!


It was an amazing feeling to know that I was one of the few people to see the PC DOS vicarage screen for quite a few years :D

This sadly only works with the uncompressed version, but its the best option we have so far.
Since its only 4 bytes then it should be possible to simply patch this on the fly without bloating the code too much. It might even be possible to patch the compressed version on the fly after uncompressing.. :s
Failing that it might require someone to write code to re-compress the file.

who knows...
this is all just speculation and Im still really waiting for a patch, since this method is not completely tested!