Mame32 inp problems

greenspun.com : LUSENET : MAME Action Replay : One Thread

Now that uploads can be identified as being recorded in either Mame32 or DosMame, I thought it would be important to point out a small problem with using earlier versions of Mame32 to record/playback inp's.

Prior to version 34b2, Mame32 did not ignore the data stored in the .hi file, which in many games causes the random variables in the game to be different.

For these earlier versions of Mame32, it is important to delete the .hi files before the recording is made in order for others to play them back properly (the same must be done when playing the inp back, as well).

=Angry=

-- Angry (greggg@ix.netcom.com), December 04, 1998

Answers

hmmm.....

So that's why I can't get a bunch of the older inp's to work... One newer inp I can't get to work at all is the current inp for Brain. Any input is appreciated.

Regards,

** Steve Krogman **

-- Stephen Krogman (skrogman@concentric.net), December 07, 1998.


MAME32 never cared about the data in the .hi file. The .hi file is used the same way as all other MAME platforms, as the code for .hi and .cfg files is in the CORE MAME source code.

What is different now, is the Core has changed. Old .inp file do not play with MAME35b1 or newer, because the key input routines have changed.

The 35bx versions of MAME32 now store additional header information in the first 32 bytes of the .inp to indicate which version of MAME32 wrote the .inp file and what game was recorded. This means that if MAME32 opens a newer .inp that was created with MAME32, it will play the proper game without the user having to select the game before playing back the .inp. If the .inp does not have the extra information, it is assumed the user knows what he's doing and attempts to play back the .inp file using the currently selected game.

Here's what the header looks like,

BYTE name[9]; game directory name padded out with '\0'; BYTE version[3]; byte1 = 0, byte2 = version, byte3 = beta version BYTE reserved[20]; reserved for future use

Hope that explains why MAME doesn't like the MAME32 inp files.

- Mike -

-- Mike Haaland (mhaaland@hypertech.com), February 18, 1999.


I don't dispute your knowledge of the INP related code in Mame32, but are you sure about the fact that Mame32 has *never* cared about the data stored in the .hi files?

My reasoning behind this is that in versions of Mame32 released before version 34b2, games that stored data in the .hi file (mspacman for instance) would pass that data along when an inp file was played back (i.e., the high score would not necessarily be -0-). Specifically in mspacman, this has a definite effect on the results of inp file playback, as the game uses a different set of seed values for the semi-random control of the ghosts.

I do agree with you, however, that the latest versions of Mame32 are incompatible due to changes in the inp file system (but this has been happening since the earliest support of inp files in Mame - inp's have always been very inconsistent between different versions of Mame).

-- Angry (angry@thq.com), February 18, 1999.


Reading the responses to the problems with inp playback in mame32 with the newer ver. of mame, could this be why Skito cannot get my Gallag inp to work properly? I can, but he can't. Can a few other players verify this for him and I? I wan't to know if it was just something he was doing, or if it were in fact the problem with what Angry and Mike Haaland were talking about.

Regards,

Steve Krogman

-- stephen krogman (skrogman@concentric.net), February 18, 1999.


Moderation questions? read the FAQ