One of my contacts notified me that he has reverse engineered the Smacker multimedia system. Hopefully we will get a description published soon and put a fresh open source implementation out in the wild.
This is great. This is one of the oldest and most enduring multimedia systems in the field, and one of the most widespread– The official website boasts of its use in over 2,600 software titles.
Could this lead to legal problems?
IIRC the ScummVM project wanted to reimplement Smacker as well to support cutscenes from Broken Sword and RAD told them this wouldn’t be a good idea. I think the reason was that they didn’t want people to use Smacker for free when other developers paid for it or something.
john_doe: “I think the reason was that they didn’t want people to use Smacker for free when other developers paid for it or something.”
I really fail to see how that’s our problem…
True, they probably feared someone would take the code and put it into a game and sell it. And I’m also not sure if this was exactly the reason or if it was something else. I’ve posted a note on this in the ScummVM forum because now they got the source to Feeble Files that uses Smacker a lot, not only for cutscenes but also as sprites/background animations.
Aside from that, I’m really curious to see how Smacker works :)
According to my contact, “Just huffman over 4×4 blocks. It’s _very_ simple.” It’s hard to claim innovation by applying a coding method developed in the 1950s.
The algorithms might not be revolutionary but RGT has always made its living by making great tools and libraries for game developers so that said devs do not have to worry about the intricacies of FMV,
I totally support RAD and the non-theft of their tools, because they make good cheap stuff, but in this case I don’t consider it theft because it’s just playback that is affected. It’s not like they get much smacker royalties anyway in 2006.
Besides, it should be fairly obvious from the output that all of the real intelligence is in the compressor. When I worked on my 8088 video project, the decompressor had to be simple because I didn’t have any spare cycles. The compressor, however, did a brute force exhaustive search for the best possible codebook lookup — took seconds per frame on my Athlon 2500+. That was where all of the major development went into.
This is the relevant ScummVM forum:
http://forums.scummvm.org/viewtopic.php?t=137&start=15
A poster claims that RGT has no trouble with the RE thing, just the re-implementation part. I find that a little hard to swallow. But, since my primary interest right now is documenting stuff that others have RE’d, such a policy should fit into my plan.
Found a tidbit on Usenet from Jeff Roberts, the author of Smacker: “Smacker basically uses bit pattern quantization blocks (a little like BTC) with a really, really good 16-bit entropy encoder (two palette indices are compressed as one 16-bit value). There are a ton of little tricks, but that’s the gist.”
Other Usenet searches show some other information, like the compressor uses Wu quanitzation to reduce color, and there is a halftoning step — the compressor is incredibly complex.