Jump to content



  • Posts

  • Joined

  • Last visited

Everything posted by checkmate

  1. This program can view AKOSes? Great! I'm sorry I never finished AkosView. I can't get myself to finish it, so thank you for making a different program capable of this (and a lot more)
  2. Oh DARN! I forgot to add code that detects the different SCUMM versions (hence slightly different file formats). I assume it works for Curse of Monkey Island, right? I'm on vacation, so unfortunately I won't be able to correct this problem for a week or two. If you have a C++ compiler, you might be able to modify a few lines of code to make it work. Some DWORDs in the Directory blocks ought to be WORDs in Full Throttle (the value specifying the number of items, as well as the offset fields, I believe).
  3. I've decided to upload the finalized version of AkosView, with source code. This is NOT an alpha version, and is capable of extracting AKOS data from SCUMM files! I actually finished the AKOS extractor a couple months ago, but I didn't want to release AkosView because there were still some things I wanted to work on, such as getting the colors correct and animations. I couldn't figure those things out, though, and I didn't want it to look like the project was dead. Get it here! Of course, AkosView will be obsolete once the ScummEx project gets going. Until then, "you can count on Nosedog to serve all your AKOS-viewing needs"...
  4. You'll notice that I have a skeleton for an index file reader. Gotta complete it sometime...
  5. Yo! Would anybody like to comment on the source release?
  6. You're trying to use the original DOS version, aren't you? Try ScummVM .
  7. New version (Alpha 5), and I've released the source code!
  8. I didn't realize anybody needed it anytime soon. But if you wanted it, Mr. Flibble, you got it! AkosView Alpha 4 adds support for image saving (as PNG rather than BMP).
  9. I haven't added a "save as bitmap" feature yet. I guess I'd better get to work on it!
  10. I seem to recall there was a "Scumm Xplorer" project, but I can't imagine where it is, now. Wasn't Drigo Zoxx in charge of it?
  11. Hooray! Thanks for your help. I misinterpreted your post and thought the bits were supposed to be read in reverse order...wrong. And I also discovered a bug in the code I had to start with...I was doing (1 << count) instead of (1 << i). Why didn't that just jump out at me?? Could've saved us a lot of trouble. Codec 16, it turns out, is actually one of the Background Image codecs.
  12. Ai-yai-yai! I understand your post, now I'm just trying to make the BitStream reader go "in reverse"! Unfortunately, it's more difficult than I thought... This obviously isn't correct (it still outputs trash), but it's what I've got so far: BYTE readBits(int count) { BYTE result = 0; for (int i = 0; i < count; i++) { if (!--numBits) { bits++; numBits = 8; buffer = *bits; } if (buffer & 0x80) { result |= (1 << (count - (i + 1))); } buffer <<= 1; } return result; };
  13. It's not like I just copied the whole thing over from ScummVM, just that it's too similar for my liking...and it still doesn't help me understand it.
  14. Well, I'm convinced there's a problem with the bitstream reader...that was confusing in the ScummVM source code. This is an implementation that was copied and slightly modified from ScummVM. The Alpha 3 version uses this implementation; it actually works: #define AKOS16_FILL_BITS() \ if (numBits <= 8) \ { \ bits |= (*dataPtr++) << numBits; \ numBits += 8; \ } #define AKOS16_EAT_BITS(n) \ numBits -= n; \ bits >>= n; void AKOS::codec16(BYTE* result) { BYTE* src = currentAKCD; BYTE unk5 = 0; int unk6 = 0; BYTE mask = (1 << *src) - 1; BYTE color = *(src + 1); BYTE shift = *src; WORD bits = (*(src + 2) | *(src + 3) << 8); BYTE numBits = 16; BYTE* dataPtr = src + 4; WORD height = currentAKCI->height; while (height--) { BYTE* curDst = result; WORD width = currentAKCI->width; while (width--) { WORD lineBits; *curDst++ = color; if (!unk5) { AKOS16_FILL_BITS() lineBits = bits & 3; if (lineBits & 1) { AKOS16_EAT_BITS(2) if (lineBits & 2) { WORD tmpBits = bits & 7; AKOS16_EAT_BITS(3) if (tmpBits != 4) { color += tmpBits - 4; } else { unk5 = 1; AKOS16_FILL_BITS() unk6 = (bits & 0xFF) - 1; AKOS16_EAT_BITS(8) AKOS16_FILL_BITS() } } else { AKOS16_FILL_BITS() color = ((BYTE)bits) & mask; AKOS16_EAT_BITS(shift) AKOS16_FILL_BITS() } } else { AKOS16_EAT_BITS(1) } } else { if (!--unk6) { unk5 = 0; } } } result += currentAKCI->width; } } The AKOS16_FILL_BITS and AKOS16_EAT_BITS are rather odd...I'm not sure how the bits are structured in the data. The implementation I wrote (which doesn't work) reads bits in this order ("1" is the least-significant bit): Byte 1: 8 7 6 5 4 3 2 1 Byte 2: 16 15 14 13 12 11 10 9 ...etc...
  15. Well, I've just found one bug in the above code. I'm going down the rows too fast. Here's another version, but it's STILL NOT QUITE RIGHT! It still outputs gibberish, though I have to admit, this gibberish is more readable than the previous version. void AKOS::codec16(BYTE* result) { BYTE colorBits = *currentAKCD; BYTE color = *(currentAKCD + 1); BitStream stream(currentAKCD + 2); WORD height = currentAKCI->height; BYTE rep = 0; while (height--) { WORD width = currentAKCI->width; while (width--) { *result++ = color; if (rep) { rep--; continue; } if (stream.readBits(1)) { if (stream.readBits(1)) { BYTE code = stream.readBits(3); if (code == 4) { rep = stream.readBits(8); } else { color += code - 4; } } else { color = stream.readBits(colorBits); } } } } } There may also be a problem with my BitStream reader, so that deserves some scrutiny too.
  16. Thanks! I think I'll release the source code with the full, non-Alpha version comes out. As for codec 16, I pretty much copied some bits out of ScummVM. But after looking at it carefully, I've drawn up a flow-chart that should help...so with that, I wrote up an implementation by hand. Trouble is, that implementation outputs a pile of pixel gibberish. I've written a small file that should really help with implementing Bit Streams: // BitStream.h // By Nolan Check #ifndef BITSTREAM_H #define BITSTREAM_H #include "AkosView.h" class BitStream { public: BitStream(BYTE* theBits) { bits = theBits; numBits = 8; buffer = *bits; }; BYTE readBits(int count) { BYTE result = 0; for (int i = 0; i < count; i++) { if (!--numBits) { bits++; numBits = 8; buffer = *bits; } if (buffer & 1) { result |= (1 << count); } buffer >>= 1; } return result; }; private: BYTE* bits; int numBits; BYTE buffer; }; #endif And my hand-written implementation of codec 16 looks like this: void AKOS::codec16(BYTE* result) { BYTE colorBits = *currentAKCD; BYTE color = *(currentAKCD + 1); BitStream stream(currentAKCD + 2); WORD height = currentAKCI->height; while (height--) { *result++ = color; if (stream.readBits(1)) { if (stream.readBits(1)) { BYTE code = stream.readBits(3); if (code == 4) { BYTE rep = stream.readBits(8); while (--rep) { *result++ = color; } } else { color += code - 4; } } else { color = stream.readBits(colorBits); } } } } Remember: this implementation outputs gibberish, so it's got a bug somewhere. Would anybody like to help me find it??
  17. I have V7 and V8 the wrong way around? I was copying what IndexFileSpecs.txt said, which I'm pretty sure is backward... So if I got it mixed up in my previous message, then the Index File Specs does too. You should probably double-check.
  18. My main concern with your Index File Specs is the definition of the Directory Blocks. It says that SCUMM V8 Directory blocks have this structure: Block Name (4 bytes) Block Size (4 bytes BE) No. of Items (4 bytes) *Room Number (1 byte) *Offset (2 bytes) While the SCUMM V7 Directory blocks are equivalent to SCUMM V5, which looks like this: Block Name (4 bytes) Block Size (4 bytes BE) No. of Items (2 bytes) *Room Number (1 byte) *Offset (4 bytes) Are you sure that the SCUMM V7 Directory blocks use 4 bytes for the Offset field, while SCUMM V8 (which is newer) uses only 2 bytes? Seems to me rather odd...
  19. Now AkosView Alpha 3 is out. I've added support for codec 16 (which I vaguely understand now) and a "zoom" feature for the low-resolution games.
  20. Getting AkosView to extract costumes from resource files by itself is my top priority right now, followed by getting the frame's position on the screen correct, fixing palette issues in several codec 5 images, and implementing codec 16. I believe it's also possible to get AkosView to play back animations, but I know almost nothing about the AKSQ blocks, among other things. I once had some code written that opened SCUMM resource files and found AKOS costumes. Unfortunately, it was flakey, had trouble differentiating SCUMM V8 and V7, and crashed for no reason whatsoever...but the main problem with it is that I LOST IT! I'll have to write it again! It would help if the Index File specification was cleaned up. bgbennyboy's has several innacuracies, I believe (I think it has SCUMM V7 and V8 mixed up somewhat ). But another source for information is the ScummVM source code, so I'll look into that. Previously, I detected SCUMM V8 (which uses 32-bit data in some places which V7 used 16-bit) by reading the name of the file opened to see if it said "COMI.LA0". But it turns out that the size of the MAXS block is different for the two versions (V8 is 176 bytes, V7 is 138). I could use that:cool:
  21. New update: AkosView Alpha 2. An off-by-one bug prevents you from viewing the first frame in the costume, so get the new version for the fix.
  22. The newest, windowed version of AkosView is now here, although it's an alpha version. It doesn't have all the features of the final which I will hopefully release in the near future, but it is functional, so go here to get it. Have fun browsing, and I hope you find something truly interesting in all that data.
  23. Thanks. I've finally completed a mechanism for finding costumes in disk files using the index file, so no more ripping it out with ScummRev. Now I'm working on the AKOS drawing code, so pretty soon this program will be painting its first picture! P.S. Thanks, khalek. I've made it check for the other extensions just in case.
  24. AkosView 2. My wonderful new project, which, unlike the original AkosView, will A) run in a window B) have the ability to extract AKOSes from game files by itself C) display codec 16 D) have no problems displaying certain weird frames. My development log can be found at my website , so you can writhe with impatience while I slowly work on the project. With luck, it will come before the year 2004!
  25. On October 21, 2003, "The Complete Far Side: 1980-1994" will be released with every single Far Side cartoon ever! For $135 bucks.
  • Create New...