Jump to content

Home

Akos...


checkmate
 Share

Recommended Posts

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

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

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

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

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

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

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

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

  • 4 weeks later...

It's been a while, but yes, I'm still working on it. Slacking off, you know. That's what everybody does around summer.:rolleyes:

 

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

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

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

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

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

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.

 

:newbie: Geez I love this smilie.

Link to comment
Share on other sites

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

  • 2 weeks later...

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.:confused:

Link to comment
Share on other sites

 Share

×
×
  • Create New...