#242 "gvba" does not write the battery file until the game is clo

[Nick Ellery]

Originally reported at https://bugs.launchpad.net/bugs/396792.

Ubuntu 9.04
visualboyadvance: 1.8.0-4ubuntu1
visualboyadvance-gtk: 1.8.0-4ubuntu1
vbaexpress: 1.2-0ubuntu3

This bug report concerns Battery files, those ending with ".sav"
It is not about Save states, those ending with ".sgm"

General description:
When run from the GTK+ interface (gvba), VisualBoyAdvance doesn't create a battery file ".sav", until you close the game, or exit the application. This behavior is different from that observed by running "VisualBoyAdvance" or "vba" directly from the command line, or using the "vbaexpress" interface, which uses the FL toolkit (FLTK).

Run a game from the command line (this calls a bare SDL interface)
vba game.zip

In a few seconds the message "Battery wrote" appears, and a battery file is created
$HOME/.vba/game.sav

The same happens by running
vbaexpress

and loading the game through the interface, File > Open a Game...

Whenever the words "Battery wrote" appear on the screen, either automatically or because you reached a save point within the game, the battery file is created or updated, if it already existed. This can be seen by keeping the file manager open during the save.

If you use the GTK+ interface
gvba game.zip

you can play for hours, but the "Battery wrote" message never appears. If you select File > Close, or File > Exit, the game ends, and the battery file is created or updated immediately after. Again, this can be seen by keeping the file manager open in the directory where the batteries are saved.

This obviously presents a problem, because if "gvba" doesn't exit cleanly, or you reset the game within the emulator, the battery file is never created or updated properly.

Since "VisualBoyAdvance" works correctly with the bare-bones SDL interface, I suspect the problem lies with its interaction with the GTK+ interface, which uses Glade. It actually uses GTKmm and libglademm, since it is in C++.

The "vbaexpress" interface overcomes these problems because apparently it only sets-up the configuration file "VisualBoyAdvance.cfg", and then forks the "vba" process, and thus the FLTK toolkit does not interact with the SDL window.

[Squall Leonhart]

this is the desired behaviour, in all the ports of VBA.
so its not a bug.