Drmd Loosing Its Savestates...
#1
Posted 12 December 2005 - 07:13 AM
I'm having trouble with DrMD. I am launching a rom ( for instance, Sonic3), playing a tad, then making a savestate ( L+R to go back in menu, i select "save state", choose slot0, menu says slot is used, perfect, fine).
I can then load it just fine, it works flawlessly.
However, sometimes, when i load back DrMD, it says that no savestate is used... i know somebody which had the same bug, all savestates disappearing.
I have trouble reproducing it though ( sorry reeesy, can't give you more info).
Anyone else has the very same problems ?
#4
Posted 12 December 2005 - 10:41 AM
Perhaps it's more complicated than that, but I'm guessing that there's something in there to make DrMD commit changes to the SD card when you exit. Maybe it could do that for each write instead? That'd be one for Reesy - it seems right to me but may have other consequences I don't know about.
But yeah - see if you have more success if you make sure you exit the emu properly when you've finished with it.
#7
Posted 12 December 2005 - 12:43 PM
The first time, I went to save state in a game I had saved in once before, on the same slot, overwriting the save, and it simply said "failed" and locked up. This was in Phantasy Star IV
The second time, I was playing Shining Force II and hit L+R to go into the menu. It said "auto-saving SRAM" at the bottom of the screen, and locked up.
I've been really impressed with DrMD so far, but I think I'm going to give it a little more time before I start playing serious RPGs in the thing
-OCA|
#9
Guest_Reesy_*
Posted 12 December 2005 - 01:42 PM
I've just tried some quick experiments and I think it's a sync issue. It seems to work fine if you exit DrMD properly, but not if you turn the GP2X off while still in the emulator.
Perhaps it's more complicated than that, but I'm guessing that there's something in there to make DrMD commit changes to the SD card when you exit. Maybe it could do that for each write instead? That'd be one for Reesy - it seems right to me but may have other consequences I don't know about.
But yeah - see if you have more success if you make sure you exit the emu properly when you've finished with it.
Interesting idea. At the moment I'm just using the standard file system api:
fopen - open file
fwrite/fread - write or read file
fclose - close file
I'm assuming that when I call fclose it should finalise all of the changes and update the file correctly. I never leave a file opened for more than a nano second. I have no idea if there's another linux command I should be using to force an update, maybe there is something you change. I know in WinXP you can change a setting to make removeable media be written to straight away, so you can remove the media as soon as you see the file copy process has ended. Maybe there is something similar in Linux but I have no idea.
#11
Posted 12 December 2005 - 02:20 PM
I'm assuming that when I call fclose it should finalise all of the changes and update the file correctly. I never leave a file opened for more than a nano second. I have no idea if there's another linux command I should be using to force an update, maybe there is something you change. I know in WinXP you can change a setting to make removeable media be written to straight away, so you can remove the media as soon as you see the file copy process has ended. Maybe there is something similar in Linux but I have no idea.
I think they have write caching enabled, although I have no idea why. IIRC you can call:
system("sync");
to force it to write the data out.
BTW, pretty much everything I have that saves data out has this problem, including all the other emulators, so don't feel like it's a bug that's specific to yours.
#12
Posted 12 December 2005 - 02:34 PM
Same behaviour on Tilematch. I noticed that sometimes turning the console off while Tilematch is open doesn't write the hi-scores table to disk, even though I fopen, fwrite, and fclose each time the player gets a high score and enters his/her name. Exiting Tilematch and then turning off seems to work fine.Interesting idea. At the moment I'm just using the standard file system api:
fopen - open file
fwrite/fread - write or read file
fclose - close file
I'm assuming that when I call fclose it should finalise all of the changes and update the file correctly. I never leave a file opened for more than a nano second. I have no idea if there's another linux command I should be using to force an update, maybe there is something you change. I know in WinXP you can change a setting to make removeable media be written to straight away, so you can remove the media as soon as you see the file copy process has ended. Maybe there is something similar in Linux but I have no idea.
As Mysterial says, it's probably due to asynchronous writing, so using system("sync"); should do (but I haven't tested it yet), as it turns writing to synchronous.
#14
Posted 12 December 2005 - 04:34 PM
Maybe not clear ... fclose does not call fflush it lets the os flush the stream when it wants - which might be straight away or in 1 to whatever seconds, calling fflush causes an interupt (slow in relative terms) and demands
#include <stdio>;
void lba_game_save(void) {
FILE *file;
char *save_location;
asprintf (&save_location, "%s/.lba/saved_state.lba", getenv ("HOME"));//GNU_LINUX printf to allocated string
file = fopen(save_location,"wb+");
if(!file) {
fprintf (stderr, "Error writting savegame!: %s\n", save_location);
exit (1);
}
free (save_location);//deallocate file location now its been used
fprintf (file, "AAAAAAAAAAAAAAAAAAAAAAAAAAAAAA");
fflush (file);//flush file
fclose (file);
}
Edited by babbagesmachine, 12 December 2005 - 04:45 PM.












