checkmate Posted May 7, 2002 Share Posted May 7, 2002 Hi:) I've started a project to decode and view the AKOS costumes used in Full Throttle and later. I think I've figured out some of the format (special thanks to ScummVM team!), and I need a little help. Please correct me if I make a mistake...I'm not completely sure of any of this. AKOS is split into three codecs: 1, 5, and 16 (Weird.) Codec 1 is an RLE-type format with entry and repeat value in one byte. Depending on the number of colors, an encoded byte looks like this: C = Palette Entry Bit N = Repeat Value Bit If number of colors = 16: CCCCNNNN If number of colors = 32: CCCCCNNN If number of colors = 64: CCCCCCNN Codec 5 is (I guess) similar to BOMP images. I haven't figured much out on this. Codec 16...unknown right now. If you'd like to tell me what you know (if anything) on the AKOS format, please do. Link to comment Share on other sites More sharing options...
Ender Posted May 7, 2002 Share Posted May 7, 2002 If you work out Codec 16, the scummvm team will be very happy. *grin* - Ender Developer, ScummVM Link to comment Share on other sites More sharing options...
checkmate Posted May 8, 2002 Author Share Posted May 8, 2002 Why are the codecs called 1, 5, and 16, rather than 1, 2, and 3? Link to comment Share on other sites More sharing options...
checkmate Posted May 8, 2002 Author Share Posted May 8, 2002 If you work out Codec 16, the scummvm team will be very happy. I'd be glad to try, but don't count on me. Link to comment Share on other sites More sharing options...
checkmate Posted May 8, 2002 Author Share Posted May 8, 2002 Actually, what would really help if somebody fills me in on endianness. I'm not familiar with Big Endian numbers and Little Endian numbers, and how do I convert the two? Link to comment Share on other sites More sharing options...
john_doe Posted May 8, 2002 Share Posted May 8, 2002 Originally posted by Endy If you work out Codec 16, the scummvm team will be very happy. *grin* - Ender Developer, ScummVM This codec 16 is really strange. Ludvig once mentioned this could be sort of a Huffman-like compression (but I'm sure you either know that already or Ludvig came to the conclusion that it's wrong). The only thing I found out about the codec 16 costumes is that they don't seem to use a color palette (no AKPL chunk and an empty RGBS chunk) - at least the some I examined closer (all from The Dig). So either it's just coincidence (could be), or the palette info is stored directly in the encoded costume (unlikely), or that the codec 16 costumes rely on the room palette. Link to comment Share on other sites More sharing options...
checkmate Posted May 8, 2002 Author Share Posted May 8, 2002 Actually, I examined a Codec 16 costume from Full Throttle. It's the animation of Ben popping out of the dumpster. This AKOS block has *no* RGBS block, and the AKPL block has nothing in it. The dumpster room's palette does contain a few suspicious colors, though. Link to comment Share on other sites More sharing options...
Serge Posted May 8, 2002 Share Posted May 8, 2002 Me! Me meme ME! I'll take the easy one Little endian: Derived from Little End First. Big endian: Derived from Big End First. What does that mean? It means that if you store a word (2 bytes), you can store it in two ways. Take the number 1234. That's 0x04D2 in hex. So, the bytes 04 and D2. Now, the "little end" is the end that has the least significance to the actual size of the number (so, the little end is the one we normally put last). The "big end" is thus the end that has most significance. So, 1234 - hex 0x04D2 becomes: 04 D2 - in big endian byte order. The "big end" is stored first. D2 04 - in little endian byte order. The "little end" is stored first. The same thing goes for double-words (4 bytes). The number 123456789 - in hex: 0x75BCD15 - can either be stored: big endian: 07 5B CD 15 or little endian: 15 CD 5B 07 Hope this was at least relatively comprehensible - Serge Link to comment Share on other sites More sharing options...
Serge Posted May 8, 2002 Share Posted May 8, 2002 Codec 16 uses the room palette, from the little I've looked at it. It accesses a palette redirection table which is also accessed in some cases by codec 1. The redirection table it created at runtime, and is only modified by two script commands (kludge commands for those who know what those are about, it's not really essential knowledge to get this) - build-palette-shadow and set-palette-shadow. My guess is, in the cases where the redirection table (which redirects costume palette entries to room palette entries) isn't used, the palette of the room is used. Haven't looked more at it. This was found in the CMI code, however, The Dig and FT should be the same. - Serge Link to comment Share on other sites More sharing options...
checkmate Posted May 8, 2002 Author Share Posted May 8, 2002 Thanks, Serge! Would my Wintel machine be considered Big Endian or Little Endian? Little Endian, I'm guessing. Are you saying that there's no such thing as a "Big Endian" or "Little Endian" byte? Link to comment Share on other sites More sharing options...
john_doe Posted May 8, 2002 Share Posted May 8, 2002 Originally posted by checkmate Would my Wintel machine be considered Big Endian or Little Endian? Little Endian, I'm guessing. Are you saying that there's no such thing as a "Big Endian" or "Little Endian" byte? Yes, the Intel 80x86 processors are little-endian machines. Big-endians, for example, are the Motorola 68xxx line (used in Macs etc.). Link to comment Share on other sites More sharing options...
checkmate Posted May 8, 2002 Author Share Posted May 8, 2002 Thanks. I won't be needing any more info on endians just now. Would somebody tell me about the AKOF block, please? As far as I know, it contains the offsets to image header and image data, but how do I find the image offsets in there, and is it like offset from start of data or header block, or offset from AKOF? If somebody could also mention the AKSQ, I'd be happy. Link to comment Share on other sites More sharing options...
Serge Posted May 9, 2002 Share Posted May 9, 2002 A byte can be big endian/little endian in the way the bits are arranged inside the byte. So, the number 1 - in binary 00000001 - can be stored as: little endian: 10000000 or: big endian: 00000001 As for AKOF, AKCI, AKCD etc., the simplest way to decode the cels of the costume, with no regard to the playing order etc. (which is, as far as I recall, stored in AKSQ - don't remember the format, but it consists of frame numbers and various commands (those that begin with the byte C0)) is: - Find the amount of cells - stored as a LE word at offset 14 in AKHD - Find the codec (you know where to find that) - Find the height and width of each cel - that's stored in AKCI, cel by cel, in LE words, width height width height width height etc. The offset where the width/height for one particular cel is stored is found in AKOF, which consists of 6 bytes for each cel - the first 4 (a little endian doubleword) are the offset into AKCD where the image data is found, the last 2 (a little endian word) are the offset into AKCI where you find the width/height. Both those offsets are relative to the start of the block content. I.e., for the width/height offsets, it's relative to offset 8 in the AKCI block, for the image data, it's relative to offset 8 in the AKCD block. - Then the palette - you know all about that too. - Finally, start decoding at the offset given in AKOF. Once again, hope this helped - Serge Link to comment Share on other sites More sharing options...
checkmate Posted May 9, 2002 Author Share Posted May 9, 2002 Thanks:) How many times have I posted "thanks" now? The core for my viewer is probably 99% done. Link to comment Share on other sites More sharing options...
checkmate Posted June 2, 2002 Author Share Posted June 2, 2002 It's been a while, but yes, I'm still working on it. Slacking off, you know. That's what everybody does around summer. Quick question: Serge, so you're saying that to find the cel offset info in AKOF, I do "celNumber * 6"? No, that's not right. What should I do? Link to comment Share on other sites More sharing options...
Serge Posted June 3, 2002 Share Posted June 3, 2002 Yes, should be right... Can't check right now, but I pretty much checked it when I first wrote that stuff. - Serge Link to comment Share on other sites More sharing options...
checkmate Posted June 6, 2002 Author Share Posted June 6, 2002 Whoa, did I just say "summer"? I meant "winter" to you guys down in Australia. Link to comment Share on other sites More sharing options...
checkmate Posted June 6, 2002 Author Share Posted June 6, 2002 I'm happy to say that I'm on the verge of getting a working program running! I have all the code put in, now I just have to debug it. It'd be nice if someone could tell me about the DCOS block in the directory file, because that's what I'm trying to use. Link to comment Share on other sites More sharing options...
Serge Posted June 6, 2002 Share Posted June 6, 2002 DCOS, DSOU, DROO, DRSC, DSCR and DCHR all work the same as far as I recall (DOBJ is different). The format goes (for CMI): dword - "DCOS" header dword BE - size dword LE - number of directory entries repeat <number of directory entries> byte - room number endrepeat repeat <number of directory entries> dword LE - offset relative to LFLF block endrepeat The first entry will usually be 0 for both room and offset. Note that for DROO, the room number actually refers to the disk number, and the offset is 0 - the actual room offset is stored in the LOFF block instead. Some differences in the earlier versions (such as Dig and FT). Namely the number of directory entries is a word rather than a dword, and the offset may be relative to the ROOM block. - Serge Link to comment Share on other sites More sharing options...
checkmate Posted June 9, 2002 Author Share Posted June 9, 2002 Well, I've got yet another question. It's about the how the original scumm interpreter works...what is its method of finding blocks in a file? Does it make a list of all the block offsets? Does it just go through the file and seek a block? Does anybody know? Link to comment Share on other sites More sharing options...
checkmate Posted June 10, 2002 Author Share Posted June 10, 2002 Wait, don't answer that. Figured it out myself. Link to comment Share on other sites More sharing options...
Ender Posted June 10, 2002 Share Posted June 10, 2002 john_doe/serge: Yeah, your right - it uses the shadow palette in mirror mode falling back to the normal palette. It doesn't look particually huffman'ish - in fact, it looks like Yet Another Hack on the LZSS algo. I should look into this a little more, I think. Link to comment Share on other sites More sharing options...
checkmate Posted June 11, 2002 Author Share Posted June 11, 2002 I notice that most of the codec 16's I've seen involve alpha effects like dust puffing up. I even have a disassembly of what I believe is codec 16, but I'm not sure if that would help. I'm sorry about the delay on my AkosView project. I'm fighting off a certain compulsive mental issue I'd rather not talk about right now. On looking at some ScummVM code, I notice that to load and search for resources, memory pointers are used. How can you do that without loading the entire file into memory? I'm trying to create a kind of module, you see. Geez I love this smilie. Link to comment Share on other sites More sharing options...
Serge Posted June 11, 2002 Share Posted June 11, 2002 Resources ARE loaded into memory. When you enter a room (O_CURRENT_ROOM opcode), the ROOM block is loaded. The other resources (COST/AKOS, SOUN, SCRP etc.) are loaded using other opcodes (subopcodes of O_HEAP_STUFF) by the scripts when needed. As a side note, SCUMM Revisited actually uses memory pointers for entire files too, without loading them into memory - by using Win32 memory mapping (that's what caused problems on NT4). This maps a memory range to the file (it's the same thing Windows does with the swap file). - Serge Link to comment Share on other sites More sharing options...
checkmate Posted June 20, 2002 Author Share Posted June 20, 2002 Are you sure that I can find the offset info in AKOF with "CelNumber * 6"? The one line of code I wrote to do that seems to make the program just quit, without illegal operations, without errors, without blue screens, and without me telling it to. It just quits . And, looking at ScummVM code, it's obtained from AKSQ. I don't know. I'm confused. Link to comment Share on other sites More sharing options...
Recommended Posts
Archived
This topic is now archived and is closed to further replies.