Housecleaning

Today I did some housecleaning for the upcoming beta, which I'm still hoping to release before the end of this month.

I decided to keep the current somewhat buggy MPEG decoding stuff in the beta, which meant that I had to clean up the MPEG ROM detection logic so that it actually works (until now I always used the -dvc option to explicitly force the DVC model).

The MPEG ROM detector will now only use the supplied "dummy" xmpeg.rom file if it cannot find another recognized ?mpeg*.rom file. If it does find such a file, the DVC type will now be displayed in the CD-i Emulator title bar (GMPEG, IMPEG, VMPEG). For GMPEG the AH0x number is also displayed, as the AH00/AH01 cartridges are very different from the AH02/AH03 ones.

Some little-known DVC tidbits:
- The Philips CD-i 370 uses VMPEG hardware but at a different memory address
- The Philips CD-i 615 uses IMPEG hardware but the ROM also contains non-FMV software
- The DVS VE-200 and LG GDI-700 use IMPEG hardware but at a different memory address

More details on the state of the MPEG emulation will be available in the beta release notes.

Earlier I had started using a manifest file to get a newer common controls DLL, thus modernizing the visual "look" of CD-i Emulator somewhat. However, this caused Windows Vista and Windows 7 to stop using "virtual store" redirection of the cdiemu.ini file which broke all settings stuff (including the recently used list).

Today I figured out that leaving out the UAC "requested level" entry from the manifest restores the "virtual store" redirection. This is good enough for this beta.

I also killed the "file registration" code because it would hijack any existing non-beta registration (this has nothing to do with licensing but with the way Windows finds executables to open certain files).

Finally, I added video decode skip validation. This gets a bit technical...

In CD-i players, video decoding steals bus cycles and thus slows down the machine. The amount of bus cycles stolen depends on the video mode, pixel repeat settings and, for run-length modes, on the actual data.

If the emulation starts to lag behind, CD-i Emulator starts skipping the decoding of video frames. Previously, I used a "worse-case" estimate for the number of stolen bus cycles in this case. However, this introduces problems with input recording and playback: if frame skipping differs (which is almost guaranteed to be the case), the playback will start to "drift" from the recording. Over many frames this will result in an incorrect playback.

I coded a "SkipLine" routine that does no actual video decoding like "DecodeLine" but it does decode just enough to accurately determine the number of stolen bus cycles. This routine is now used when the video frame is skipped.

The validation consists of running both routines when the video frame is not being skipped and ensuring that both "steal" the same number of bus cycles.