arabianm

[Francois Daniel]

http://marp.retrogames.com/index.cgi?mo ... lines=9999

http://marp.retrogames.com/inp/e/a/7/da ... m37b11.zip

This one desynch in first stage with/without sound/nvram.

Francois

[LN2]

I'll give that one a try. The fact in the description he says "option(alt)" key hints he was using macmame.

A PC-MAMEr would only call it the alt key...not option(alt).

----

ok, I tried it in a few macmame 0.37 beta versions. We don't have a 37b11 though so perhaps it is a PC-mame played game. I tried playback of this in b13, and b16.

anyway, in viewing it seems the amount it plays back is dependent on the frameskip value. When I had an automatic frameskip on it played to "34". When I forced frameskip 0, it played a little further to 40-something.

This game at fskp 0 runs at only 35% on my 450MHz Mac. I would need to run it at fskp 8 for that version of macmame to play it at 100% speed. Given you are going back 2.5 years for this play, there is a great chance this person was using a certain level of frameskip. if automatic there is likely no way to play his inp back. I didn't try other frameskip values...cuz odds are even if I have the right one if it's a pc-mame play then macmame might not play it back correctly anyway.

You can try a few different forced frameskip values.

[Chad]

this is a mac inp (no header) and i can't play it back.

[LN2]

ok, I'll try a few other fixed frameskip values then.

I strongly suspect it's where the player used automatic frameskipping though so it can't be played back.

[Chad]

thanks rick, lemme know of success of failure.

[mahlemiut]

I strongly suspect it's where the player used automatic frameskipping though so it can't be played back.

Sounds to me like you think automatic frameskipping breaks any and all recordings.

[LN2]

Sounds to me like you think automatic frameskipping breaks any and all recordings.

No, but it certainly does for games where successful playback requires you have the same frameskip value as used in the recording. For many games the frameskip value doesn't matter for inp playback...but for many it does. I have long been opposed to using automatic frameskip when recording to avoid the issue entirely.

I oppose it to the point that if I ever had my own macmame/mame build, I would force a fixed frameskip when recording. I also would add to a header the sound setting since some game replays won't playback successfully unless the same audio settings are used....and also an auto-ignore saved NVRAM even if one exists for the game when recording and playing back a replay.

Replay files should be where you can just play it back without having to tweak various settings of how you have your macmame/mame setup to run so it runs back at the settings the player had it. At least then if you can't play it back you know what settings they used.

I always include a readme with my inps telling important settings like that unless I know the settings don't matter for successful playback. Most don't though which leaves us to guessing and often wasting time with various attempts to successfully playback their replay file.

When someone uses automatic frameskip with games like this and a dynamic value of frameskip is actually being used, someone else likely isn't going to get that same combo of variant frameskip for it to playback successfully.

I suspect this inp is dependent on frameskip cuz in the 2 values I had already tried(automatic, and fixed at fskp 6) it played back to a different point! It got a bit further with a forced fskp 6.

I'll try a couple other values when I have time to do it...this weekend sometime most likely. Perhaps they used a fixed fskp but I just haven't matched it yet. In my experience with other macmame players though most use automatic frameskipping...so I suspect that is the case here.

[mahlemiut]

And yet, you'd think then, that that would be so for ALL Taito F3 games. Trust me, it's not. Then again, I don't know what weird-ass changes there are in MacMAME. There are differences in drivers, I'm sure. There certainly are between MAME and XMAME - even though there shouldn't be. The one time I tried to apply a u1 patch to XMAME, it didn't patch cleanly to some drivers (it was fixable, but still, I'd expect drivers, at the least, to be the same across ALL ports).

Anyway, there are a few F3 games that have had playbackability problems, although this would not appear to be one of them, judging by the number of confirmed recordings. Most problems with this hardware seem to be in post-0.70 versions, as far as I've noticed.

[LN2]

And yet, you'd think then, that that would be so for ALL Taito F3 games. Trust me, it's not.

Not sure of your point here. I am not saying in any shape or form that all game playbacks require a fixed frameskip or that all of any certain CPU(s) either.

However, until you test it with each game you really have little clue if that particular game is dependent on frameskip or not.

I just say why worry about it at all?!? If mame auto-fixed frameskip when recording and playing back an input file and sets the frameskip based on header info in the replay file then the player no longer needs to worry about this issue. Also for confirmers, they don't need to worry about what settings were possibly used if no readme was given and no info in the submission description at MARP.

Then again, I don't know what weird-ass changes there are in MacMAME. There are differences in drivers, I'm sure.

Again I don't get your point and what it has to do with this playbackability case.

The ONLY reason I suggest playback of replay files for THIS particular game are dependent on frameskip is because it got out of sync at DIFFERENT spots for the 2 frameskip values I tried. If the frameskip setting doesn't matter, then I would expect it to playback identically at both frameskip settings.

I have not said anything beyond this...yet you are off into talking about various other games and macmame vs mame vs xmame etc.

Anyway, there are a few F3 games that have had playbackability problems,

First, the playbackability issues of which there were a few threads here at MARP for versions 0.63 to 0.73 or whatever that was and the playbackability issue pc-mame has with some games with sound on....which forces players to record with sound off so it can be replayed with sound off...is NOT an issue in MacMAME at all. I have experienced games where if you record at a 22kHz sound setting that you must use the same setting for playback. If you use 44 kHz instead for certain games it will lose sync at some point. Sound rate dependence is the same for pc-mame and xmame as well for these particular games.

Sometimes it's very hard to detect also. For example, my 6.5 million Punch-Out replay file. I would need to check again but I think I used 11 kHz or 22 kHz. If you play the replay file back at the wrong sound setting, it seems to playback just fine...but it doesn't actually. It loses sync around 4.5 million after a few hours of playback into the game! At the same sound setting it plays back in its entirety correctly. This game is even more picky in that you must play it back with the speed throttle on. With the throttle off playback quickly loses sync within the first few fights.

However, I have yet found a game in macmame that won't playback successfully using the same sound rate setting yet does playback with audio off if recorded with audio off.

Centipede is a good example here. I have no problem playing and recording with sound in centipede, and any of it's various clones...and millipede as well. All replays of it playback fine in macmame. I have had another test one of my replay files and he could view it fine.

Major Havoc is another example. In pc-mame, it seems you must record and playback with sound OFF. In macmame, it works fine with sound on. QT Quazar had watched a couple of my Major Havoc replay files on his Dad's mac and confirmed they do playback correctly.

Hopefully if he gets active at MARP again he can confirm more of my replay files for MARP.

So overall at this point it seems pc-mame actually has more issues with replay file playbackability than macmame does.

[Chad]

So overall at this point it seems pc-mame actually has more issues with replay file playbackability than macmame does.

can't beat up rick for the inconsistancies of macmame, there are other people to point the finger at there. but at the same time you certainly can't say a blanket statement like that one above, rick. There's no where near the playback experience of macmame recordings verses pc ones. Every recording i made with xmame worked, so that must mean xmame is superior in playbackability, nah i don't think so. It's more likely that you haven't encountered such a game where turing sound on and off is an issue, (have you made recordings for all mame games and have you tried them on different macs or just with the sound turned off?), i'm betting there are games that mac mame has this problem with, you just haven't found them yet.

[LN2]

but at the same time you certainly can't say a blanket statement like that one above, rick. There's no where near the playback experience of macmame recordings verses pc ones.

Yes, you have a point here...cuz there could be playback issues in macmame also that I just haven't stumbled on yet that aren't issues in pc-mame. I did say it "seems" though. I didn't make a conclusive statement...just all evidence thus far supports that case.

However, I have viewed between my own and the other macmame replays at MARP and TG for confirmation some 400+ rom sets in various versions of macmame and the couple I had issues with playback turned out to be cuz of NVRAM usage or some other known issue that results in loss of sync on playback...where the player was e-mailed about it and confirmed it doesn't even playback properly for them!

At a macmame forum I have read many that had issues playing back a replay file etc. and in each and every case I was able to solve it for them. In most cases it was simply the NVRAM issue...in a couple though it was the use of automatic frameskipping(which is On by default in macmame)...for another it was the sound rate setting in recording or playing back the replay file where the player hasn't matched the same settings. For another it was the version of macmame used was misreported.

Every recording i made with xmame worked, so that must mean xmame is superior in playbackability, nah i don't think so.

Well, do you have to play centipede with sound off for the replay to playback successfully? perhaps that's a windows/msdos specific issue then. I made no comment about xmame at all above. I referred to "pc-mame" meaning dmame or mame or mame32 or wolfmame etc....not mame for linux. macmame is more based on xmame anyway....with assembly code optimizations to increase performance for some of the game CPUs.

It's more likely that you haven't encountered such a game where turing sound on and off is an issue,

Well, I have only encountered one game that had playback issues even playing back a recording I just made. However, it was the same with sound off also. This was for gtma...which was reported to have playbackability issues in pc-mames also...for "some". Some could play them back ok..others couldn't. I need to try gtma in the latest macmame to see if it's still an issue or not.

The other issue you definitely have with pc-mame playbackability is the OS used. I see so many reports here where a replay is viewable in win98 but not winxp etc. There are no issues like that for macmame. For older versions that ran in several macos versions, I could view in any OS version os 8, 9, X, X.1, X.2 and it was the same in each.

Also, when I have tested for many of these issues in MacMAME I am specifically testing using the rom sets that are reported to have playbackability issues in pc-mame.

If it was a pure mame issue, then it should happen on each platform. That isn't the case for some games as pointed out in these forums.

As Barry noted it's likely a driver difference issue. Drivers vary versus platform which would support the fact some replays playback fine in win98 but not win2k or winxp etc. This would also explain the sound issues in pc-mames that aren't in macmame and if I infer from your above isn't an issue in xmame either.

However, since when do drivers have to do with use of frameskip and if the way a game's timing is done on playback etc. is dependent on the frameskip value?

I'm not knocking mame for this fault at all. players just need to realize that using automatic/dynamic frameskip is risky for the playbackability of an input file for certain games. If they test each game beforehand for this then no problem...but most don't...and most likely just use whatever the default settings are. For macmame automatic frameskip is on by default so unless they are aware of the potential playbackability issue they will use automatic frameskip for everything....and eventually have a replay file that no one else can playback successfully.

I say remove that issue entirely by deactivating or giving some warning when automatic frameskip is on and you are about to record or playback an input file.

I'd bet even half of the pc-MARP members that don't participate in these forums likely aren't aware of the frameskip issue that some games have.

[Chad]

cool, well any luck with this recording? :)

[LN2]

cool, well any luck with this recording?

I haven't tried it more yet....other than posting here yesterday I didn't touch macmame. I worked on other stuff.

might get to it today...although I have a lot I want to do today also.

It's not exactly a first place score or a high score where it's that big of a priority.