[openMSX-devel] Save states

[Maarten t. H. <ma...@tr...>]

Hi,

I'll try to summarize the discussion about save states. I have my own opinion, 
so it won't be fully objective, but you can correct me in your replies.

I think it's useful to list some use cases for save states:
- saving your progress in games
- sharing saved games with other people (to help them along or to show off)
- debugging your own MSX software
- testing patched MSX software (translating or cheating games)
- debugging openMSX
Did I miss one?

When evaluating a design, these use cases are one of the things we should look 
at.

These were the questions I originally posed about save states:
1. should save states be exchangeable between different machines [read: PCs] 
running the same openMSX version?
2. should later openMSX versions be able to read save states from earlier 
versions?
3. how to handle system ROMs, cartridge ROMs, disks etc?
   embed them? store file paths? store SHA1? a combination of these options?

People disagreed about how important point 1 is, but since solving these 
issues (endianess, 32/64 bit, maybe more) is not that hard, we should just do 
it. The future will tell us whether this feature was important or not.

There was consensus that point 2 is desirable. And as Daniel told us, users 
seem to expect it as well.

The option of an external conversion tool for old save states was mentioned, 
but this has disadvantages:
- separating the conversion code from the class the state belongs to is not 
desirable: there is the risk it gets out of sync and also of code duplication
- for the user, it's inconvenient to have to run an external program to be 
able to use save states made before the openMSX upgrade, or the user might 
decide not to upgrade instead

So we should support save states from older openMSX versions and that support 
should be built into the class that is loading the state.

About point 3, there was no consensus yet.

The advantages of embedding ROMs:
- less error handling when loading a save state, because there is less that 
can fail ("ROM not found")
- easier to send save states to other people

The disadvantages of embedding ROMs:
- save states would include copyrighted material and unless you're playing a 
freeware ROM with C-BIOS, it wouldn't be legal to for example put your save 
state on a web page
- save states will be bigger; this may not be significant for MSX1 games on 
MSX1 machines, but if you play Solid Snake on GT, you'd have 5MB of ROMs 
embedded in every save state

To me, the advantages seem less strong than the disadvantages:
- unless we plan to embed tape and disk images as well, there will still be an 
external dependency when loading a save state, so not having such a 
dependency for ROMs doesn't make error handling much easier
- the "easier to send" advantage conflicts directly with the disadvantage of 
embedding copyrighted material: if the receiver has the same ROMs, there is 
no point in embedding them, if the receiver doesn't have the same ROMs, then 
he might not have permission to use them legally either

So I think we should not embed ROMs into save states. Instead, we can link 
ROMs using both SHA1 and file names. When loading, SHA1 is tried first; if 
there is no matching ROM, file name is used and a warning is issued.

I was hoping I could also start with the implementation discussion in this 
mail, but I'm out of time now, so it will have to wait.

Bye,
		Maarten