Saturday, 11 August 2007


And it was just a comparatively small step from there to here!

The video frames (i.e. each one after this, the first one) are stored differently again, I think they're going to be even more tricky to pull out, but at least I know my BMP writer works!

Picture posting

So I figure, now would be a good time to start posting pictures. Here's the mansion, as my program outputs it atm. Clearly far from right, but it is there if you stand on your head and look hard...

Decompression fixed

Yes, there was a problem with the decompression. This would have been obvious with a little bit of arithmetic: the output .dat file was 2.5k, and it should have been about 50k. Fixed now. The BMP is still screwed, but in a much less terminal way (I hope :-).


Hmph. I think there is a problem in my decompresser. And after I was so happy that I got it working and everything.

The problem is that I have no intermediate. I can check the vdx files are correct, but after that I have to go:

vdx -> individual chunk -> decompresser -> read image -> write bmp

The only stage where I can actually check that everything is going according to plan is at the stage where it has made me a bmp file. Which is rather frustrating. I'm used to checking at every single stage along the way, to make sure all is going well, but here I don't get that option. Unless I try to take apart the pascal code... no, I think that would be going too far. This will work, it will just take care and hard work.

Friday, 10 August 2007


And now, the task ahead is to convert my pretty little file into a bmp file, so that I can view it. Which is a decidedly dull task, so I keep putting it off and off.

I emailed the guy who re'ed the vdx and gjd files, and he was supportive, but he only ever concentrated on those files. Looks like I've got all the help anyone's able to give me...

Right. BMP files. *sigh*.

Decompression complete

Woohoo! It was a challenge, more mentally taxing than I'm used to, but I now understand the algorithm and have it working in my program. At the moment it just dumps the decompressed files to disk rather than converting them into any sort of viewable format, but that should, I hope, be comparatively straight-forward...

Thursday, 9 August 2007

Holy compression batman...

It turns out this is going to be a little more tricky than I thought. Not much, but a little. The video sequences use a form of data compression, LZSS, which I'm gonna have to write a decoder for. Which would be a huge set-back, or at least would slow me down an awful lot, if it weren't for the fact that someone (at the page linked to above) has written a pseudo-code decoder. I say pseudo-code, it's pretty much pascal. I've begun by just directly translating it, but I'm starting to get confused: I think I'm gonna have to figure out how it's working first, then implement it after.

Starting vdx extracter

Well, I've set off on the vdx file extractor. And although reasonably straightforward, it is definitely NOT going to be a one-night job like the gjd extracter.

One thing about it is that unlike the gjd file, where every byte is accounted for, there are several bytes here and there that the handy specs linked to earlier just say "unknown". Now, they didn't have to worry about them, because they had the sole purpose of extracting resources from the files, but I'm probably going to need what's in them at some stage. So I'm storing them, but I have to come up with variable names for them when I have no idea what they are / what they do. I've decided to follow the theme, and name them (initially at least) after characters in the game. I should point out that I don't know those names off the top of my head: I'm not that obsessed with the game! I looked them up on wikipedia, so if they're wrong no-one can blame me. As if anyone will notice / care :-)

Easier than expected

Using the ScummVM tools as a base, it was really easy making an extracter for the .GJD files. Admittedly, it's not difficult, it essentially just a bunch of files stuck together, but I had expected to take a while to get going, so it's good to get an easy bit out of the way. Next (but not tonight), the vxd files, which although more tricky, really shouldn't prove too much of a problem.

Wednesday, 8 August 2007


Having not managed to get any of the game extracting things working under linux, I thought I'd write little tools first that would extract the resources from their respective files. But someone beat me to it. And they run perfectly under wine, unlike everything else I've tried this evening.

I think it's still going to be a good exercise to write the tools in C though: it'll get me to know the file formats well before starting anything more complicated. It's just that I'll be translating from Pascal to C rather than writing from scratch!

The long journey begins

There is some information on the web to get me going: the most helpful is that someone has re-ed the file formats. I've been trying to get MultiEx Commander working under linux, but it doesn't seem to like wine. Which is rather frustrating. There's no way I could do this under windows, so I'll see if I can find anything else to help me out...

Welcome to my... blog

So this is my attempt to actually get started on this: start a blog, then I'll get really depressed if I don't put anything in it for a while and be forced to do something.

I am intending to reverse-engineer The 7th Guest, the eventual intention being (if they'll have it) to add it to ScummVM.

I should point out that I have no experience of reverse engineering, little experience of ScummVM programming, and only moderate experience of programming. The thing I have in abundance, though, is a willingness to learn these things. Hopefully that will be enough!