forums.marpirc.net

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.
<p>

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.

<p>

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).

<p>

=Angry=

--
greggg@ix.netcom.com

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.
<p>

Regards,

<p>

** Steve Krogman **

--
skrogman@concentric.net

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.

<p>

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.

<p>

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.

<p>

Here's what the header looks like,

<p>

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

<p>

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

<p>

- Mike -

--
mhaaland@hypertech.com

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?

<p>

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.

<p>

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@thq.com

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.

<p>

Regards,

<p>

Steve Krogman

--
skrogman@concentric.net