Finalizing input record/playback

Today I resumed working on the input record/playback code to get it towards its final specification for this beta.

I want the record/playback code to be generic, by which I mean:

1. Recorded input files must be dumpable (e.g. by cdifile) without having to know intimate details of the recorded devices and messages. This can be achieved by labeling all input channels with name and type and recording the formats of all input message types, which is now mostly done.

2. Recorded input files must contain all the information required for faithful playback, which includes things like CD-i player model, DVC cartridge type, extension roms, PAL/NTSC and special startup options and emulated disc insertions.

The ideal is that "wcdiemu -playback" will just work without the need to fiddle with emulator options to reproduce the recording environment. This is now also mostly done except for the disc insertions (they are recorded but cannot yet be played back).

3. It must in principle be possible to play back on a different CD-i player model or with a different DVC cartridge. This means that the input channel matching must be somewhat "intelligent". The groundwork for this is in place but the actual channel matching is not yet there.

All of the above are needed to get the feature usable for extensive compatibility testing, which is a goal of this beta: it should be possible to exchange input recordings that reproduce crashes or rendering bugs, even when they require some time to reproduce. Emulator state snapshots would make this even better, but that is too much work for now.

Recorded input files are in IFF format with the following generic structure:
- each file contains a single FORM chunk of type INPT (recorded input)
- the first chunk inside the FORM is an IVER chunk (version information)
- the next chunk inside the FORM is an ICHN chunk (channel information)
- the final chunk inside the FORM is an IMSG chunk (input messages)

Input messages are recorded in binary format to keep their size small; the first time that a message type is used, the message format string is prepended.

The cdifile dumping code will not be released with this beta, there's too much unfinished code in there (i.e. the -dir[ectory] option to display the directory of a CD-i disc image file).

I will attempt to finish this tomorrow, but it's just barely achievable...

Until then, you'll have to do with this picture:

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.