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.

If you work out Codec 16, the scummvm team will be very happy. *grin* :)

- Ender
Developer, ScummVM

Why are the codecs called 1, 5, and 16, rather than 1, 2, and 3?

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

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

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.

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.

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

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

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?

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.).

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.

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

Thanks:)
How many times have I posted "thanks" now?
The core for my viewer is probably 99% done.

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?

Yes, should be right... Can't check right now, but I pretty much checked it when I first wrote that stuff.

- Serge

Whoa, did I just say "summer"? I meant "winter" to you guys down in Australia.

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.

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

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?

Wait, don't answer that. Figured it out myself.:newbie:

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.

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.

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

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:

Screenshots. I have output from my program. Where can I post them on the internet? I have found a few images never seen in the game, or in ScummRev.:)

AkosView is almost ready for release! Scumm Revisited 3 had a weird problem where some costumes would show up as black rectangles. Not in here. AkosView also supports Codec 5.

Well you could post them on this forum:)
If you need some webspace to hold them you can use my megre isp-given webspace for a bit. Its not doing anything atm.

This is me (bgbennyboy@yahoo.co.uk)

I need help. The AKOF block has structures like this:

UINT32 akcd
UINT16 akci

Unfortunately, the AKOF block is not "akcd-akci-akcd-akci". It sometimes has other stuff in it, and I can't tell them apart, which doesn't give me access to very many frames in the costume. I think the solution has something to do with AKCH or AKSQ, so if someone could explain those, I'd be very happy.

AkosView version 0.2, has server space kindly provided by bgbennyboy, and can be downloaded here. (http://www.gorman.btinternet.co.uk/Akosview.zip)

Please note that it is alpha quality, has problems, and graphics issues specific to Windows XP that I am trying to fix.