I'll proceed to detail what I know of the compression algorithm's characteristics. What I'm interested in are everyone's opinions on whether JPEG compression is even a remote possibility here, and furthermore whether anyone wants to take a guess as to whether the compression could involve huffman encoding, or whether it might be something much more easily dealt with.
Below is a screenshot showing a decompressed image, with a sample from the compressed file inset. I've confirmed through experimentation that the visual matchup suggested by the red circles is approximately correct -- the parts you can understand visually in the compressed file are truly literally-encoded pixels.
The literal pixels are encoded in 16 bits-per-pixel, RGB format. So, two bytes per pixel. Now, the pixels in the compressed file that appear visually as really bright colors or otherwise interrupt the literal image are probably some sort of compressed packets or decompression instructions, and I believe they may also be stored two bytes apiece -- or maybe four bytes apiece, since I'm having trouble finding a compression instruction that isn't at least "two pixels long" when the file is visualized as a 16bpp image.
The file is encoded in Little Endian byte order and all literally encoded pixels have a value of FF7F or below (since it's Little Endian, "7F" is the high byte and "FF" is the low byte, so a human would read it as "0x7FFF"). The compressed packets/decompression instructions all have a value of "0080" or above (again, we would read that as "0x8000").
What I'm thinking is, the game developers made some kind of proprietary compression scheme that took advantage of the fact that they only needed about half the colors available in the entire High Color range. In other words, I suspect that the decompressed images use colors 0000 ~ 7FFF, for a total of 32,768 colors, which sounds is more than satisfactory for a game released in 2001. Values 8000 ~ FFFF, then, are interpreted by the game as decompression instructions.
Interestingly, if the literally encoded pixels are nulled (well, "blacked", since I just overwrote them with the bytes 0000), the decompressed image will display with the change. If the compressed packets/decompression instructions are nulled, however, the game freezes at the point the image is to be displayed. So something must be telling the game to expect compressed packets at specific offsets, and it freaks out when it doesn't find them. There are a ton of pointers sitting at the very beginning of the image, so I think I'll try following them and see where they lead.
This is the first PC game I've looked at in depth, so I have some questions about proper tools to use (like whether there's a really good memory dumper that dumps only a game's memory and not all of Windows memory, that sort of thing); but I'll hold off on that in lieu of the JPEG question. It seems silly to ask about the possibility that this could have anything to do with JPEG compression after what I described (not to mention, the compressed files have none of the JPEG standard header material), it's just that the dll was bothering me. The game appears to use a BASS dll for music playing in most cases, and a BINK dll for its movie files, so I keep wondering whether there might be something in the Intel JPEG library that could be useful to whatever decompression scheme is happening here.
If anyone's working on games made in Asian countries (for translation projects, for example) and needs to view, edit, and re-import graphical elements representing text,