[Scummvm-devel] SCI: _k_disable_delete_for_now ()

Walter van Niftrik walter at vanniftrik-it.nl
Tue Mar 31 14:23:49 CEST 2009


Lars Skovlund wrote:
> The result is basically that you
> can't implement savegame deletion for SQ4/Floppy unless you duplicate
> the exact naming scheme of savefiles (i.e. savefiles must be named
> SQ4SG.<number>) and the exact file format of the savegame index
> (SQ4SG.DIR). From the earlier discussions on file I/O handling -
> before as well as after the merge - I gather that this is not an
> option.

It sounds like we could intercept file opens of *SG.DIR and construct an 
appropriate file on-the-fly. Similarly we could intercept truncates of 
SCI-style savegame files to actually delete the appropriate savegame. 
Would this work?

> The question then becomes what we want to do. Is the plan to
> eventually bypass the Save/Load UI completely and use the ScummVM
> native one?

Won't this be tricky to do, considering that the games are essentially 
in full control when it comes to presenting the save/load dialog? I 
guess it wouldn't be a problem to do this for saves/restores that are 
initiated from the menu or from F5/F7, but what about 
restore/restart/quit dialogs after dying?

We also need to take into account that some games do not use standard 
SCI savegame dialogs, like Mother Goose. That game is also incompatible 
with our savegame slot remapping BTW, but that's another matter. ;)



More information about the Scummvm-devel mailing list