Re: [hatari-devel] order change in "machine type" enum

[Nicolas Pomarède <npomarede@xxxxxxxxxxxx>]

Le 08/06/2016 à 19:45, Thomas Huth a écrit :
>  Hi,
>
> On 08.06.2016 00:24, Nicolas Pomarède wrote:
> > with recent changes, thomas added a "mega st" machine type IIRC.
> >
> > But in configuration.h , I see the following changes :
> >
> >  typedef enum
> >  {
> >    MACHINE_ST,
> > +  MACHINE_MEGA_ST,
> >    MACHINE_STE,
> > +  MACHINE_MEGA_STE,
> >    MACHINE_TT,
> > -  MACHINE_FALCON,
> > -  MACHINE_MEGA_STE
> > +  MACHINE_FALCON
> >  } MACHINETYPE;
> >
> > The problem is that previous machine types are not the same anymore ;
> > before, STE was 1, now it's 2 for example.
> > And nMachineType is saved as an integer in memory snapshots,  but also
> > in config file. This change could cause problems when reloading previous
> > snapshot/config as the values were re-ordered.
>
> Actually, I did that reordering on purpose: The code in the gui-sdl
> dialog gets somewhat easier if the enum is in the same order as the
> radio button entries. Also it's nicer in case you edit the config file
> manually if the numbers there match the order of the dialog - then you
> can easier figure out which number to use for the wanted machine type.
>
> Concerning the compatibility issues with the config file and memory
> snapshots - of course I'm aware of them: For the config files, the new
> values are now saved as a different entry called "nModelType" instead of
> "nMachineType", so there is no conflict between old and new model types.
> For a smooth transition, the current code can still load the old
> nMachineType entries, too, and converts them to the new type (see
> "configs_System_Old" in configuration.c).
>
> However, I did not add additional logic for the memory snapshots - they
> have never been portable between releases anyway, so I don't think we've
> got a real issue here, do we?

Hi

My bad, I didn't see the code to read old config file ; as config files 
are consistent through release, this is indeed important that Hatari can 
read previous version.

As for the memory snapshot, I agree that so far we did a poor job at 
keeping compatible between hatari versions. I don't know if many people 
keep some snapshots to save game state, but that's something we should 
improve some days (this was discussed in an older thread, idea would be 
to have some kind of independant chunks with their own version tag ; 
this way if the video part need more variables for example, then it 
doesn't break the whole snapshot as it does today, it just extends the 
size of the current video part's chunk and using the chunk's version, we 
know how to parse it).

But as every Hatari release was not compatible with previous snapshot, I 
don't think it's a real blocker. By the time next Hatari is released, 
there will certainly be more variables to add to the memory state :)

Nicolas