Jump to content

Home

checkmate

Members
  • Posts

    92
  • Joined

  • Last visited

Personal Information

  • Biography
    Just another average guy.
  • Location
    Somewhere
  • Interests
    Programming, daydreaming, etc.
  • Occupation
    Student; President of Nosedog Productions

Contact Information

  • Homepage
    http://www.geocities.com/nosedog2003/

checkmate's Achievements

Newbie

Newbie (1/14)

10

Reputation

  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.
×
×
  • Create New...