I’ve been staring mindlessly at assembly language for hours. I’ve got a book, and I can figure most of the stuff in there, but when I try and translate that to the T7G exe, it seems worlds apart. I’ll try and find a reverse-engineering book in our uni library tomorrow, hopefully if a book is coming from the same angle as me it might help.
Forlorn.
The video above celebrates the fact that my “engine” can now pull a vdx from a gjd directly and play it (previously, in case you haven’t been following, I had to extract the vdx with a command line tool first).
Enough with procrastinating. Now I have no excuse but to attempt some disassembly. Well, I could work out how to do sound / xmidi, but I think I’ll save them for later.
So I’m just about to turn off Google Desktop, in case it overwrites the part of the hard disk that the files were stored on.
I mean, how often do I need to search for files on my computer anyway? It’s not like…
Hmmm.
It lets me search for strings inside, for example, source code files. Does that mean it stores cached versions of those file?
Bingo!
OK, I don’t have them all back, but the only ones I’m missing are the detection files and the makefile, which should be a piece of cake to do again.
I may have to keep google desktop for at least a little while, if only to say thank you.
This could be my last post for a while. I have been exceptionally stupid, and managed to delete my entire engine. I’m not gonna go into details of how I did it, it’s far too depressing, but I’ve tried “recover” and “e2undel”, to no avail. I’m now in the process of grepping my entire hard drive (which has to be done in 100MB blocks, otherwise grep runs out of memory) to see if anything is salvagable.
Suffice to say, if I get everything back up and running again, or if I have to start from scratch (my last way-point was my empty engine), I will be setting up a backup system, probably an svn server.
Grrr.
As expected, the problem was with me being a muppet. When telling it the length of the data (for example, for the initial still image), I was giving it the length of the compressed data, rather than the uncompressed. So it was only getting partway through. Now it works, yay!
Where to go from here. There are a number of options:
Although it may seem like I’m procrastinating (hell, of course I am, disassembling still scares me), I’m gonna sort out reading the vdx from the gjd. Everything is stored in gjd files, including the xmidi files, and I think it will be good to get me into the C++ mindset.
Got the timing working. Problem is that now it’s running slowly enough for me to see artifacts. *sigh*. It’s easier to fix them when your program outputs every frame as a bmp. Maybe I’ll get scummvm doing that…
If you can see it at this crap quality… I managed to get the animation frames working. Timing is not adhered to (by any means), but all the frames are in there.
ION, given I have 4 bluetooth devices, 2 of which have video cameras on, you’d think I’d be able to transfer the video easily. No. It was possible, but I had to open the linux app that received files. Would be good to have that built into the bluetooth, or at least the option to start it whenever a bluetooth device is connected. Anyway, done now. The next question is, will this video work?
OK, nobody get too excited (though I am, but I know what this is). At the moment, this is just reading the first frame of one of the animations. Don’t get me wrong, this is a big step, but … there is a whole 200 storey building to climb after this one :-). But still, yay!
Hmmm.
Looking at the LZSS decompresser in the scumm he engine, that works by just allocating big enough chunks of memory to decompress the entire stream. This is all fine and good. But *my* variant of LZSS doesn’t tell me how big the decompressed data is, only the compressed data. This, it turns out, is a bit of an arse.
At the moment I’m planning just to say “it’s never gonna be bigger than this” as a nasty hack, just to get something working. In the future, when I’m feeling a bit more confident, I’ll write an LZSS-compressed stream class (unless someone beats me to it :-).
Well, this is something of a non-post. Or at least, it will seem it to anyone that’s not me. I’m trying to get my engine to just play a vdx file first, just to find my feet. I’m getting my head round the way everything’s done in ScummVM, slowly, but it’s not helped by the fact that my C++ is rusty: I wrote the extraction tools in plain C. Might have to get a book out of the uni library tomorrow. Anyway, I have figured out how to draw to the screen, & open and read from a file… but now I’ve got to decompress a stream of data on the fly. In the tools I wrote before, I extracted to a temporary file, then read that back in. I knew it was a hack, and that I’d have to do it properly, but just sort of ignored it. Thankfully, there is already an LZSS decompresser in the SCUMM engine: it uses different settings so I can’t use it, but I should be able to use it as reference.
Man that was a boring post. Maybe next time I’ll have some pretty pictures… hopefully.