Another gift!

It turns out the music, contained in the XMI.GJD file, is in xmidi format. Which scummvm already supports. Woohoo! This says to me that the next stage is probably going to be adding the engine to scummvm ... a big task.

Oh, and I'm going to rename all the files so they have small letters. internally they're all referred to in small letters, so for the time being I may as well be consistent. Eventually I guess it's gonna have to cope with both, but I prefer the idea of being short-sighted for a bit.

And I'm going to redo the database, this time with all the unknown data values, and possibly bytecode totals for all the resources. Maybe. Still haven't decided what format the database should be in, I'm having a go with OpenOffice database, seems ok. Whether it'll read in comma delimited data, who knows...

Building database

Well, I figured if I was going to get every bit of this game working, I'd need to know which part is where, etc. So I'm unpacking everything. That may not sounds very exciting (and it's not), but I was quite impressed to find that just INTRO.GJD, which starts off at about 30MB decompressed to about 900MB. So the whole game (about 650MB) will probably take up 20GB. And then I just have all the decompression data to put into some sort of usable form...

/me trundles off to investigate MySQL

And I'm spent

I managed it in the end. I figured out not only what the problem was, but why I had a problem with that frame in particular. The frame uses a particular opcode, 0x60, a lot, when others don't (at all? Not sure). That opcode gives very precise control over the image: where the previous frames have been slightly "rushed" as it were, to save space, this one is done very precisely. If you remember the intro to 7th guest, you'll know why: all the action for the next few scenes takes place on the pages of that book: it basically doesn't change for a minute or more.
But that's not important. The important thing is that it works. Now I've just got to try it on all the others and find the ones it doesn't work on...

Noooooooooooo!

It was all going so well! I'd finally got the palette completely sorted (how could it be so difficult?), the first 30 frames were perfect, then this! Where do I start trying to figure out what's wrong with this? I just don't know...

Still bad, but getting better

As you can see, I'm getting there...

My sticking point

In case anyone is trying to do the same (unlikely, I know), the thing that was confusing me was that the 0x61 opcode, which skips to the end of the line, is also required at the end of each line (like a new line character). As such, you don't need to keep track of the number of tiles in the x direction that have been processed.

Woo hoo!

Though barely recognizable, this is a breakthrough. This is the house, after we've pulled out to see it in the book (remember that bit?). It may seem like small comfort, but it pretty much just the palette that's screwed. Hopefully.

End of night post

This is to aid my memory when I come back to this tomorrow. Too late now.

Program segfaults. This is because it goes beyond the end of the image array. This is because it goes beyond the correct number of blocks in y. I do not know why this is, I must have interpreted the file wrong... right?

Progressing

Next stage. Still not really recognizable (I think it's just gonna be the mansion again, btw).

Not quite there yet

Was getting bored of writing, so thought I'd post some images. This could be an interesting transformation... I think I've screwed up the palette on this image. I'm gonna be putting it together a few pieces at a time, so we'll see!

Valgrind is teh Magic

It seems that when your code is shonky (and you have an inkling that it might be), valgrind is where to look. It'll point to things, even when your program appears to be working, and say "err, are you sure that's right? it looks like you're being a bit of a muppet there". And you can ignore it (I did, mostly cos it took me a while to figure out what its error messages meant), but eventually they'll come up and bite you in the seg fault.

In short, I feel it is going to be invaluable. Even more so than it has been tonight.

Don't Panic!

It's ok, it was a very easy thing to fix. Phew. Now, where was I...

Well, at least I liked Square 1 when I was there first time round...

There is no expletive to express this.

Up until now, I have been working with the smaller GJD files that get installed to the hard drive, but I couldn't find a delta frame there that had a palette change. So I went for a biggy: the INTRO.GJD file on disc one. It's good I did, because I've discovered that the bit that was easy, the extraction from the GJD file, doesn't work properly. It gets about two into it (out of a couple of dozen), then falls over.

Still, I've already learnt / re-learnt quite a lot since I did that bit, so it might be obvious...

Decompressing V.EXE

As a distraction from those scary delta frames, I used a combination of unlzexe and dosbox to decompress V.EXE, which was compressed using LZEXE. So now all I've gotta do is disassemble it :-)

Procrastination, that's what you need

As expected, I'm putting off delving into the delta frames format. As you might expect, it's pretty complicated, so I've been trying to make sure my program is ready for it. I've now got a proper image struct for storing the images, which makes it much easier to have a second one to store the new image. Part of me feels I should be doing this properly in C++ classes though... I'll have to eventually...