Hi,
> > > Which version of ALSA is best to use to test this? 0.5 or 0.9? > > > > Savegame issues are independant of the sfx driver, so this shouldn't > > matter. It seems to work after your latest update, BTW- thanks! > > Thank goodness for that! I was just wondering which is the 'better' version > of ALSA to install ATM, if you know. I've had problems with both trees and am using 0.9.0beta3 now. These problems might vary depending on sound card (SBLive!), architecture and kernel version (2.4.14), so I'm afraid that I can't give you a good suggestion. Both 0.5.x and 0.9.x are supposed to be supported, though. If your distribution ships with a version of ALSA, you might want to try that first. > > A differently named variable (in one of the cfsml records) can indeed > > break savegames, since the variable name is used as the 'name' part of the > > name/value pair stored in the file. Variables that were _not_ set are not > > tracked, so restoring a record (foo, bar) after having saved a record > > (_foo, bar) would leave 'foo' uninitialized. > > (One of these days, this should be improved, of course...) > > That's certainly something I'm glad to know. Perhaps this should be > documented somewhere if it isn't already? Good point. CFSML still needs some improvements, but I guess I'll stick it into the specification as a warning regarding the current, uhm, 'reference implementation'. That's where it belongs to, anyway... > Sorry for not explaining myself properly, but what I actually meant was > regarding the CVS commit containing the new save game version. CVS picked up > a conflict in sfx_save.c but because the version I was submitting was so > different, whatever change you previously made to that file may not be in > the new copy. sfx_save.c is not critical; sfx_save.cfsml is what matters. llap, Christoph
