00450: .inp file problems.

ID	Category [?]	Severity [?]	Reproducibility	Date Submitted	Last Update
00450	Save/Restore	Major	Have not tried	Jan 29, 2008, 16:30	Feb 2, 2008, 12:10

Tester	-Misc Reporters-	View Status	Public	Platform
Assigned To		Resolution	No change required	OS
Status [?]	Closed			Driver
Version	0.61	Fixed in Version	0.119u3	Build
		Fixed in Git Commit		Github Pull Request #

Summary	00450: .inp file problems.
Description	This is a growing list of games which have problems saving .inp files. Comments are available when we have extra information besides it just not working correctly. Please let us know if you find other problems in other games. (all gun games) opwolf: Operation Wolf (and all gun games) require frameskip 0 for inp playback, and it will actually tilt if you pause during playback. More info: I'm not entirely sure about speed as such, but changing frameskip level will give playback problems. I just did a quick test, and made an opwolf inp using auto frameskip. It won't playback, it will tilt early on regardless of if it is played back using -noafs or not. Then I made another one using -noafs to keep it at a steady frameskip of 0. Then I played it back with -noafs, works perfectly. Playing it back with auto frameskip works until it starts skipping frames. I induced frameskip by hovering the mouse pointer over the close button, and it immediately tilted. I guess speed is not a problem, as switching speed throttling on and off with F10 has no effect (assuming no auto fskip of course). (atetris.c) atetris: See the attached .inp file, it plays to 3,485,868, but on Round 24, the game ends with random pieces that weren't actually in the game I played. http://www.mametesters.org/files/inp061ora_file2.zip (ccastles.c) ccastles: Playback doesn't work correctly unless sound is disabled when you record them. (cloak.c) cloak: (esd16.c) multchmp: The inp files for this game saves wrong. You can not replay the record to the end because it playbacks wrong. (exidy.c) mtrap: Playback doesn't work correctly unless sound is disabled when you record them. (cave.c) ddonpach, dfeveron, esprade, guwange: Playback doesn't work correctly unless sound is disabled when you record them. Will lose sync if there is sound enabled. This is, I believe, also caused by sound IRQ callback from the sound chip. It can be "fixed" by commenting out the reference to the IRQ callback function in ymz280b_intf and replacing it with zero. This has the side effect of some sound effects not playing, and I'm sure it wouldn't be considered to be used in an official MAME build. But it may at least point to some way to properly fix it. (mhavoc.c) mhavoc (news.c) news: The attached file is an .inp that is supposed to play to 29,580. Instead, it plays to 5K. http://www.mametesters.org/files/inp061ora_file1.zip (polyplay.c) polyplay (ssv.c) srmp7: Often loses sync after a few hands. I think this may be related to sound IRQ callback from the sound chip, which is currently kludged to work in MAME. This game won't run with sound disabled, it hangs on the score totalling. It would appear that using a sample rate of 11025Hz allows it to record and playback correctly. Check http://www.mametesters.org/files/inp061ora_srmp7_inp.zip, should play through to the second opponent, losing on that first hand there. (system1.c) flicky, seganinj, 4dwarrio, possibly others: Require a steady frameskip of 0 to playback correctly. Will lose sync if the frameskip starts to change. (gun games) If you do a recording with the gun games using -record and them attempt to play it back using -playback then pause the playback using p the crosshair still moves around the screen even when its paused, I guess this isn't the desired behavior. (I could be wrong but it certainly seems weird to me). I tested it with NyCaptor (the reported game) but it also happens in oneshot, bbusters and probably more. *Update by AWJ:* .inp files of several games in cave.c, including ddonpach, dfeveron, esprade, and guwange, have a nasty habit of desyncing on playback unless sound is disabled both when the .inp is recorded and when it is played back. The affected games have the following things in common: 1. They use the YMZ280B sound chip. 2. They do not have a sound CPU; the YMZ280B is connected to the game's main CPU. 3. As is usual in shooting games by Cave, they are largely CPU-throttled rather than Vsync-throttled: what would be called "slowdown" in most games is the normal state of operation of a Cave shooter. The YMZ280B is a multichannel PCM/ADPCM sample player which is capable of generating an IRQ when a sample finishes playing. I believe that the cause of the desyncing issue is the way the chip's IRQ generation is emulated by MAME. In MAME's sound/ymz280b module, the IRQ generation is handled in ymz280b_force_update(), the same function that produces the actual sound output. The problem is that ymz280b_force_update() is not called with regular timing with respect to the emulated CPU(s); it is called as needed whenever MAME needs to update the sound buffer, which depends on the host CPU speed and CPU load, the sound buffer size, et cetera. The upshot is that the number of CPU cycles that elapse between the CPU telling the YMZ280B to play a sample, and the YMZ280B generating an IRQ to tell the CPU that it's finished playing that sample, can be different (possibly wildly different) between when an .inp is recorded and when it is played back. The CPU could be in one routine when the IRQ occurs during record, and in a completely different routine when the IRQ occurs during playback. The fact that Cave's games are largely CPU-throttled exacerbates the problem--it is very very easy for the game to gain or lose a frame due to a sound IRQ occuring earlier or later than it occurred during record. The solution to the problem is to change the YMZ280B emulation so that IRQ generation occurs with reproducible timing, independently of the sound synthesis. What might work is precalculating the duration of a sample at the time the play command is sent to the chip, and arranging to trigger the IRQ (n) milliseconds in the future (I don't know how to do this in MAME, or even if it's possible) This would get more complicated if the YMZ280B is capable of pitch-bending a sample that is already playing. (I tried to find a datasheet for the YMZ280B on the web to get a better idea of exactly what its capabilities and interface were than I could glean from the MAME module, but no luck. One site that had the datasheet was a pay site, and the other wanted to install an ActiveX control that it claimed was a PDF. No thanks, buddy.) I hope that this helps MAMEDev and that I am not merely restating already known information...
Steps To Reproduce
Additional Information	Posted by roncli / Barry Rodewald / Chad / [Haze] / QTQuazar / Luja / AWJ
Github Commit

Flags
Regression Version
Affected Sets / Systems

Attached Files