headers
Oleg Tsarev | 4 Feb 2012 17:07
Picon

save_index file - purposes and current state

Hello guys,

I investigated "save_index" and confused by several things. General questions:

1) Which the reason create save_index file?
If I right understood, only two purposes:
 a) decrease time of open "Load" dialog
 b) decrease time of render clicked save - show preview, game
description, company name, etc.

Perfomance reason, other words. Please approve/disapprove my understanding.

2) Unfortunatelly, right now "save_index" does not used by anywhere in game.

I see just single call of save_index: write_save_index() (I skipped
definition of class and definition of methods):

src/savegame.hpp:	/** Update the save_index */
src/dialogs.cpp:		config& cfg = savegame::save_index::save_summary(i->name);
src/dialogs.cpp:	savegame::save_index::write_save_index();

You can check this by "find ./src -exec grep save_index". From this
point of view, right now save_index nobody used.
I also checked it by stacktraces *(see end of letter)

In typical game usage nowhere is used :(

3) I supposed - save_index used before, but right now code with usage
removed. I investigated revision history by git bisect and can't
confirm this -
(Continue reading)

Permalink | Reply |
headers
Jörg Hinrichs | 6 Feb 2012 08:41
Picon

Re: save_index file - purposes and current state

Hi Oleg,

I will try and answer your questions. Please bear in mind, though, that my
knowledge is from BfW 1.8. If things have changed since then, I might be
wrong on something I tell here.

1)
Yes, save_index was created due to performance reasons. The main difficulty
is presenting the load_game dialog. 

For that, you don't only have to know all the filenames: You also need to
investigate about all the things that are presented when a game is selected
in the list, namely map, turns, hero-icon etc.

To get those, you would have to (fully) parse every savefile which would
take very long.

The save_index stores all that information for every save. It's actually not
that much WML, but as said before, it is tedious to evaluate otherwise.

2)
Save_index is controlled by a class with the same name, that consists only
of static members. It is meant to represent globally available functionality
and you are not supposed to create instances of this class.

This class has a static member save_index_cfg, which gets filled by calling
save_index::load(), which in turn is done in save_index::save_summary as
well as save_index::write_save_index.
This config is meant to hold all the game information that needs to be
presented in the load_game dialog.
(Continue reading)

Permalink | Reply |
headers
Evgeniy Stepanov | 6 Feb 2012 09:57
Picon

Re: save_index file - purposes and current state

Hi,

On Mon, Feb 6, 2012 at 11:41 AM, Jörg Hinrichs
<joerg.hinrichs <at> alice-dsl.de> wrote:
> Hi Oleg,
>
> I will try and answer your questions. Please bear in mind, though, that my
> knowledge is from BfW 1.8. If things have changed since then, I might be
> wrong on something I tell here.
>
> 1)
> Yes, save_index was created due to performance reasons. The main difficulty
> is presenting the load_game dialog.
>
> For that, you don't only have to know all the filenames: You also need to
> investigate about all the things that are presented when a game is selected
> in the list, namely map, turns, hero-icon etc.
>
> To get those, you would have to (fully) parse every savefile which would
> take very long.
>
> The save_index stores all that information for every save. It's actually not
> that much WML, but as said before, it is tedious to evaluate otherwise.
>
>
> 2)
> Save_index is controlled by a class with the same name, that consists only
> of static members. It is meant to represent globally available functionality
> and you are not supposed to create instances of this class.
>
(Continue reading)

Permalink | Reply |
headers
Fabian Mueller | 15 Feb 2012 00:41
Picon
Picon

Re: save_index file - purposes and current state

On 02/06/2012 08:41 AM, Jörg Hinrichs wrote:
>
> You might also be right, that this information is not used anymore. When I
> refactored the savegame functionality together with euschn, I also created a
> new load_game dialog that uses the Gui2-framework of mordante. The new
> dialog was optional and back then could be used by starting Wesnoth with the
> command line parameter --new_widgets.
The situation hasn't changed since then.
Gui1 is the default and you get the gui2 load_game dialog with the 
--new_widgets parameter.
>
>
> The old dialog still relied on save_index, if I remember correctly.
My observations support that this is still the case as well.
Whenever the gui1 dialog is used to load a game in a different difficult 
level, the difficult level the savegame
is from seems to have changed.
This is not the case, so the loading of the savegame must have triggered 
an update to the save_index without
any write access to the file happened.

It would be nice to get rid of both, the gui1 dialog and the save_index.
Gui2 does not support the filtering and sorting of lists, so this is 
still blocked for some time.

I will see what happens to the save_index and fix the bug related to the 
load game with difficulty depending on the outcome.

Fabian
(Continue reading)

Permalink | Reply |
headers
Oleg Tsarev | 15 Feb 2012 03:20
Picon

Re: save_index file - purposes and current state

I found: save_index used.
I reafactored it little.

2012/2/15 Fabian Mueller <fabianmueller5 <at> gmx.de>:
> On 02/06/2012 08:41 AM, Jörg Hinrichs wrote:
>>
>>
>> You might also be right, that this information is not used anymore. When I
>> refactored the savegame functionality together with euschn, I also created
>> a
>> new load_game dialog that uses the Gui2-framework of mordante. The new
>> dialog was optional and back then could be used by starting Wesnoth with
>> the
>> command line parameter --new_widgets.
>
> The situation hasn't changed since then.
> Gui1 is the default and you get the gui2 load_game dialog with the
> --new_widgets parameter.
>
>>
>>
>> The old dialog still relied on save_index, if I remember correctly.
>
> My observations support that this is still the case as well.
> Whenever the gui1 dialog is used to load a game in a different difficult
> level, the difficult level the savegame
> is from seems to have changed.
> This is not the case, so the loading of the savegame must have triggered an
> update to the save_index without
> any write access to the file happened.
(Continue reading)

Permalink | Reply |

Gmane