MAME's state saving is getting more stable...?

[Shoegazer]

I'm not sure if it's just me, but it appears that with the latest releases of MAME, state saving is getting more stable.  I've been relying on this feature exclusively after high score saving was mercilessly ripped out of MAME, and for a while it seemed that each new release would knock out all my high scores since states simply would not get preserved between releases - something like 90% of them would just not make it.  Now, I've run my own little acid test to see how many of my 50+ saved states would make it from .117 to .118, and I found only two games (gunsmoke and major havoc) that didn't make it.  With that in mind, I have a few questions for someone who might hazard a guess:

1) Exactly WHY is state saving getting more stable, or at least appearing to?  Is it perhaps due to more features being moved away from game-specific drivers and into the core? 

2) What is the reason for games to LOSE their state between releases?  I'm a little baffled that the two aforementioned games lost state with the .118 release, especially given that there did not appear to be any work on their drivers during the .117-.118 cycle (check MAWS and you'll see what I mean).

3) Could it be just me who is thinking the state system is getting better, or is it just a matter of coincidence?  I'm wondering if there could be a brighter future for it in the near future.  I love the concept of saving high-scores, and it's especially cool for those of us lucky enough to have real cabinets, but I hate the negative side-effects and hackiness of having them in MAME, so save states could truly be the best of all worlds... so much potential.

Unless/until save states ever reach 100% reliability, I'll continue to spend most of time playing games that save high scores to NVRAM such as the early Williams games, centipede and crystal castles.  Those seem to be just about 100% reliable as I've had my scores in those games for as far back as I can remember!

Shoegazer

[Shoegazer]

Hmmm... Bueller?  Something-doo-economics?  Anyone here have any thoughts on this?  At ALL? 

[SGT]

No response eh?  You can probably get a quicker response here:

http://www.mame.net/cgi-bin/wwwthreads/wwwthreads.pl?action=list&Board=mamegeneral

If you ask the question over there, I wouldn't mention the high-score hack as some there can get a little testy about that.

[Shoegazer]

Yeah, just wanted to avoid (gasp) cross-posting if possible... also this forum seems to have more folks interested in high-score saving than the MAME forum, so I figured it was a better bet.  Shows how much I know.  :p

[SGT]

Yeah, just wanted to avoid (gasp) cross-posting if possible... also this forum seems to have more folks interested in high-score saving than the MAME forum, so I figured it was a better bet.  Shows how much I know.  :p

Yeah, definitely more people here implement high score saving.  However the other site is frequented by the actual Mame developers that would know the answers to your questions regarding save state stability.

[Havok]

Yep - we're all leet Hax0rs here...

 

[SGT]

Yep - we're all leet Hax0rs here...

Is this according to MooglyGuy? 

[u_rebelscum]

I'm not sure if it's just me, but it appears that with the latest releases of MAME, state saving is getting more stable.  I've been relying on this feature exclusively after high score saving was mercilessly ripped out of MAME, and for a while it seemed that each new release would knock out all my high scores since states simply would not get preserved between releases - something like 90% of them would just not make it.  Now, I've run my own little acid test to see how many of my 50+ saved states would make it from .117 to .118, and I found only two games (gunsmoke and major havoc) that didn't make it.  With that in mind, I have a few questions for someone who might hazard a guess:

1) Exactly WHY is state saving getting more stable, or at least appearing to?  Is it perhaps due to more features being moved away from game-specific drivers and into the core? 

2) What is the reason for games to LOSE their state between releases?  I'm a little baffled that the two aforementioned games lost state with the .118 release, especially given that there did not appear to be any work on their drivers during the .117-.118 cycle (check MAWS and you'll see what I mean).

3) Could it be just me who is thinking the state system is getting better, or is it just a matter of coincidence?  I'm wondering if there could be a brighter future for it in the near future.  I love the concept of saving high-scores, and it's especially cool for those of us lucky enough to have real cabinets, but I hate the negative side-effects and hackiness of having them in MAME, so save states could truly be the best of all worlds... so much potential.

Unless/until save states ever reach 100% reliability, I'll continue to spend most of time playing games that save high scores to NVRAM such as the early Williams games, centipede and crystal castles.  Those seem to be just about 100% reliable as I've had my scores in those games for as far back as I can remember!

Shoegazer

I'm don't know, but I'll throw in my veiws anyway.

1)    My guess is two fold.  More people testing the savestate now that hiscore is not officially supported, thus bugs found quicker, reported quicker, and fixed quicker.  The games that have savestate are easier to test other bugs, especially if the errors are far into the game, and between computers.  Once the  bugs are fixed, the savestate should be much more stable.  However:

2) Every bug fix, be it in the game driver, or the sound, cpu, or core code, might mess up the savestate (if the savestate was saving something wrong).  With savestate's aid in finding and fixing bugs, adding savestate might increase the number and rate bugs are reported & fixed (and reducing the number of hidden bugs).  Each fix can effect the stability of the statesave saves. 
Some might say "But it was working before!"  It wasn't working correctly though.  Example: friend & I didn't know exactly how to play checkers, so we started with the red pieces on the red squares, and the black pieces on the black squares.  We happily played fine for about an hour, jumping over each other crosswise, and thought we were sooo smart being able to figure how to play on our own.  Then our day care lady saw use playing and taught us correctly.  If we had "saved" a game of our incorrect play, it isn't compatible with correct play.  Same with savestate.

3) I think it's a trend, but I don't think savestate will be totally stable until mame 1.0 (aka "until pigs fly").  As long as mame is developing and making fixes, savestate can't be guaranteed to work between versions.  But... I think games & savestate will generally have this cycle: 
Game added (unstable, lots of bugs)
Game major bugs fixed (stablizes some)
Game adds savestate (savestate fairly stable)
Game finds & fixes more bugs (savestate gets less stable)
Most bugs found (savestate & game play stablizes)
Major revision in CPU, driver, sound, timing, etc (may break savestate)
Game finds & fixes more bugs (savestate gets less stable)
Most bugs found (savestate & game play stablizes)
(...repeat as needed...)

I think we're at the last step, just recovering from all the recent major revisions.

[Shoegazer]

Thanks as always, Robin, for saving this thread from being lost to ambivalence.    I've always felt that as much chatter on this subject as there has been, there has never been much said about stability, specifically. 

Anyway, I agree with your suggestion that savestate stability for any given driver may be attributed to the fact that bugs are getting easier to find and squash.  I also liked your checkers analogy, as you touched on something I hadn't even thought of: when a state gets lost it's probably for the best anyway.  You really SHOULDN'T have any bragging rights to Elevator Action if, for example, the game originally ran faster than MAME's driver runs it.  It's a real purist's perspective but hey, if it means I can compete evenly with the day care lady, who practices on the real machine, then great.

Here's the thing, though: as I mentioned, only two out of roughly 50 games I tested lost their savestates somewhere between .117 and .118 (again, gunsmoke and major havoc).  However after going through MAWS to see specifically what was done on those drivers that may have caused this, I found that no work at all had been done to them - they were literally untouched.  So it's a complete mystery to me as to how they could have lost their states!  See for yourself:

http://www.mameworld.net/maws/set/gunsmoke

As you can see, this driver hasn't been touched since .112u1.  Got any guesses as to why the savestate may have been lost?

One other question for you: got any suggestions as to why we had such a high rate of success with savestates between .117 and .118 when .118 introduced a totally revamped input system, affecting literally ALL drivers?  I was bracing for impact there, since I figured all savestates would be wiped out. 

Shoegazer

[u_rebelscum]

...Here's the thing, though: as I mentioned, only two out of roughly 50 games I tested lost their savestates somewhere between .117 and .118 (again, gunsmoke and major havoc).  However after going through MAWS to see specifically what was done on those drivers that may have caused this, I found that no work at all had been done to them - they were literally untouched.  So it's a complete mystery to me as to how they could have lost their states!  ... this driver hasn't been touched since .112u1.  Got any guesses as to why the savestate may have been lost?

This is why I mentioned "CPU, driver, sound, timing, etc".  If any of the parts that the driver uses to emulate the machine gets changed, the game can be effected even if the driver itself wasn't touched.

GunSmoke uses the YM2203 for sound (see the #include lines in the source file).  MajorHavoc uses pokey and TMS5220 for sound, and atari's analog vector gun (??: it includes "video/avgdvg.h", see the #include lines in the source file).

I did a simple diff between 0.117 & 0.118, and these five files are included in the diff: src/emu/sound/2203intf.c, src/emu/sound/pokey.c, src/emu/sound/tms5220.c, src/emu/sound/tms5220.h, & src/mame/video/avgdvg.c.  The first is used by GunSmoke and later 4 are by MajorHavoc.  Which of these changes is the cause (or is it "are"/"causes"?), I don't know, and there probably are other dependencies ("parts") I don't know about without going farther into the drivers.    We'd have to check the other games that also use the same parts and see if their savestates were not effected to see that was not the cause (just because they were effected, though, doesn't mean it wasn't something else effecting that game).

The short is you can't just look at the driver, but all the other emulation parts that the game uses.

One other question for you: got any suggestions as to why we had such a high rate of success with savestates between .117 and .118 when .118 introduced a totally revamped input system, affecting literally ALL drivers?  I was bracing for impact there, since I figured all savestates would be wiped out.

How the inputs work is internal to mame (IOW hidden to the game), and changes here shouldn't effect savestave.  Note I didn't say "can't".  

Back to the checker analogy.  It doesn't effect the savestate if we played using our right hands to move the pieces vs our left, or if we said "Bam!" every time we jumped a peice or not, even if "bamming" or not might effect the game play.  OTOH, if we slammed the pieces down instead of lightly placing them, the slams might make the other pieces jump to other positions, which if saved might effect if it was valid to later versions.  These are "inputs".

We are lucky the input changes were of the left hand/right hand type.

[Shoegazer]

Hey Robin, thanks for the info.  You really went out of your way to explain, and it's very much appreciated.  What you said made perfect sense.  Regarding your checkers analogy - I do hope that there aren't too many piece slamming scenerios in future MAME driver updates!

Seriously though, perhaps someday the savestate system itself could be updated for more resilience.  I was thinking about some insanely radical ideas that have probably been thought about before (and quickly discounted).  Most notably, the use of something akin to a savestate wrapper around drivers that could be invoked whenever the "cancel" operation is detected within a running game, which might alleviate the need for game-specific states to be saved.  Could something like this ever be accomplished, or are these the foolish ramblings of a depraved mind?

Shoegazer

[u_rebelscum]

Seriously though, perhaps someday the savestate system itself could be updated for more resilience.  I was thinking about some insanely radical ideas that have probably been thought about before (and quickly discounted).  Most notably, the use of something akin to a savestate wrapper around drivers that could be invoked whenever the "cancel" operation is detected within a running game, which might alleviate the need for game-specific states to be saved.  Could something like this ever be accomplished, or are these the foolish ramblings of a depraved mind?

There is a generic savestate in mame.  It doesn't work completely on almost every game; the devil is in the details, and each game has very different details. 

Thus if the game only has the generic savestate, mame lists savestate as "unsupported", and disables autosavestate (probably so they don't get hammered with "why doesn't my autosave work", which is harder to answer than "why don't I have savestate?").  But you can try to use the numbered savestate.  Probably won't work, but others have used it on some games; and if savestate is explicitly added to the game the old ones will most likely not work in the new version.

It possibly easy for single system emulators to have a generic/general way of saving the state of the system, but with mame's 6000+ games on about 1000 sytems, it's just

[Shoegazer]

Wow, I honestly had no idea there was even a generic savestate.  I just figured there were either game specific saves or nothing at all - and that the numbered save states only worked on games that actually supported them on a per-game basis.  Do you suppose there would be any value, then, in having mame attempt to autosave on exit with EVERY game, using the generic savestate only when no game-specific savestate is detected?  Perhaps not since this could introduce confusion about non-working games, as you suggest, but still it should at least be an OPTION, even if it is off by default, no?

Also, there's this: last night I played Paperboy for the first time in quite a while and got a high score, and just for S&Gs reset the game.  Sure enough, my initials and score were still there.  Since Paperboy doesn't yet have game-specific savestate support, I believe this is due to its use of NVRAM, though I had no easy way of knowing other than to just play the game, get a high score and find out.  So I'm curious to know if there's a way to create a filter, such as the ones on the left-hand panel in MAME32, for games that support not only game-specific savestates, but also NVRAM high score saving.  Perhaps there's a way to do this other than manually entering each game? 

EDIT: The recent u releases have really blown away my theory that save state is getting more stable.  Almost ALL of the games that currently support save state failed to load after upgrading from .118 to .118u3.  Ah well.

Shoegazer