Yearly Archives: 2005

Free Games That Used To Be Commercial Games

As I read new trivia additions on MobyGames, I see more and more bits about commercial games being open sourced. I figured that there must be some site out there that documents such transitions and lo and behold:

http://www.liberatedgames.com/

I wager there is some custom FMV code in there somewhere. We already know for a fact that:

  • Descent II source contains a 16-bit Interplay MVE decoder
  • Quake II source contains a Quake II Cinematic (.cin) decoder
  • Quake III source contains a RoQ decoder

A number of the games listed at Liberated Games are only free in that the binary executable and data are available, but no source code.

A few more items I would like to investigate:

Update: Trixter sends this intelligence about the titles above:

  • Hexen II — can’t verify if that’s video, but there are Animation credits in the game so it is probably yes. However, most times that stuff is a FLIC file. (BTW, don’t get all bunched up over FLIC — there are two main variants that are easy to support; the rest of all that junk was introduced and supported by only that one company you found the info on.)
  • Stargunner: same thing, most likely a 320×200 VGA FLIC.
  • H&D: no video as far as I know.

Microsoft Video-1 Based on DCT?

I recently learned that Wikipedia has an entry for Microsoft Video-1. The entry makes two assertions of which I was heretofore unaware:

  1. the codec was licensed from Media Vision and is based on a codec called MotiVE
  2. the codec was based on the discrete cosine transform (DCT)

I can accept assertion #1 but I have trouble with the second. I just don’t see it. Per my understanding Video-1 falls into the category of vector quantizer. I did a quick Google search for “media vision motive cosine” to search for supporting details. This page supports the DCT claim. But it also claims that Duck TrueMotion 1 is a vector quantizer (nope). Here is another page that mentions the MotiVE connection but pegs Video-1 as a vector quantizer.

At least the Wikipedia article links to my Video-1 description so interested parties can investigate the details for themselves.

Duck TrueMotion 1 Progress

Reimar Döffinger has submitted some work for FFmpeg’s Duck TrueMotion 1 decoder. Now the decoder can output a frame that looks reasonably correct but only paints the left half of the frame:


Sonic 3D Blast - Left Half

So we’re close, we’re very close on this variant. My guess would be that the OUTPUT_PIXEL_PAIR(), which is used in both the 16- and 24-bit variants, is not doing the right thing in the latter mode.

Further, Kostya has fixed some bugs in the TrueMotion 1 data tables that caused decoding problems with the data files from Phantasmagoria: A Puzzle of Flesh.

One more problem (which may or may not be a single problem): I still have several 16-bit TM1 samples that do not decode correctly. They decode as colorful static that looks like this:


Bug Decoding Bug

Duck TM1 actually produces some very curious artifacts due to its bidirectional predictive coding method and this frame does not do the artifact bug justice. Incidentally, this particular frame comes from the the sampler disc for the Sega Saturn game Bug! and the file can be found in the samples archive: http://samples.mplayerhq.hu/V-codecs/DUCK/ (file is bugsampler-m01-16bit.avi).

What could be the problem? Many of the frames toss off the error message “help! truemotion1 decoder went out of bounds” which is a message I added in the early days of development to indicate that the decoder had exhausted the encoded bytestream. My first impulse is that there must be something wrong with the data tables. Seems unlikely, though, since I more or less ripped the tables directly from the original VpVision source. As for the tables I had to retype, Kostya has apparently corrected mistakes in those.

There are 3 large, important tables found in libavcodec/truemotion1data.h: pc_tbl2[], pc_tbl3[], and pc_tbl4[]. Where’s pc_tbl1[]? Darned if I know but I guess the original source didn’t need it or declare it. Tables #2 and 4 begin with 10 and 9 4-entry delta runs, respectively. Table #3, however, has no 4-entry delta runs. Thus, if table #3 were mistakenly selected instead of 2 or 4 and the bytestream had a good number of low-numbered delta indices, the bytestream would be exhausted sooner than it should be.

Where are these tables selected? In TM1’s overly-complicated header decoding logic. It may be time to review that for correctness.