Joined: 4/22/2014
Posts: 59
Location: United Kingdom
I was playing Mega Man 8 (PAL version) the other night, and like Spyro 2: Gateway to Glimmer, memory card data wouldn't be saved when the emulator was closed. Is memory card saving still in the works?
I was playing Mega Man 8 (PAL version) the other night, and like Spyro 2: Gateway to Glimmer, memory card data wouldn't be saved when the emulator was closed. Is memory card saving still in the works?
I'd try updating. Used to happen to me but updating seems to have worked with another game.
The PSX can make the 320x240 framebuffer shimmy all around your television within some legal NTSC frame bounds, so that's what's being emulated.
So you'd say that grabbing the 330x240/350x240 picture and rescaling it to exact 4:3 is how it'd look on TV? Overscan being what wasn't manually tuned out of the visible TV area? Like, the image on TV stretches two-way, removing the borders. I wonder what we must use as a final preference (with overscan or without it).
Warning: When making decisions, I try to collect as much data as possible before actually deciding. I try to abstract away and see the principles behind real world events and people's opinions. I try to generalize them and turn into something clear and reusable. I hate depending on unpredictable and having to make lottery guesses. Any problem can be solved by systems thinking and acting.
i cant say how it would look on anyone's TV, every tv looks different. Televisions may be stretched both ways. Using the mednafen display mode is what ryphecha thinks is most reflective of what people would want to see on a minimally cropped CRT running according to NTSC specs. I'm not the right guy to ask about this stuff, it pisses me off. I think the intended behaviour is for us to use whatever gets sent by mednafen, squeezed into 4:3.
One thing to do is see if the .SaveRAM file ever gets created and if so, when it gets deleted. That can help isolate the problem.
The .SaveRam file will be in Your BizHawk folder > PSX > SaveRAM.
Joined: 4/22/2014
Posts: 59
Location: United Kingdom
I don't think it's even creating .SaveRAM files. The folder's there, but it remains empty.
I tried deleting the folder, and now it's not even trying to recreate it.
The program may not even check if a directory exists (and explicitly create it when it doesn't). In most programming languages, trying to create a file when the path doesn't exist simply results in an error, which may just cause BizHawk to cancel saving.
Emulator Coder, Site Developer, Site Owner, Expert player
(3598)
Joined: 11/3/2004
Posts: 4738
Location: Tennessee
BizHawk should be automatically creating folders for saveRam files, but there's an easy way to test if that's the problem. Simply create PSX\SaveRam (or whatever it is precisely), and see if that fixes the problem. Also beed28, what revision of BizHawk are you running?
Joined: 4/22/2014
Posts: 59
Location: United Kingdom
Alright, new development. I solved the problem, albeit partially. Going into the File dropdown menu and going into the Save RAM section shows one option, "Flush Save Ram". I tried selecting that, and that created the SaveRAM for the PSX games.
Except it's still not automatic. If I want to save a game normally, I do it through the ingame means, and then have to select "Flush Save Ram". If I don't do this, the SaveRAM remains unchanged.
Using r8638 on a Windows 8.1 platform.
Maybe your emuhawk is crashing at shutdown instead of dumping the saveram. Check whether your ini file is saving changes currently when exiting emuhawk
Joined: 6/25/2007
Posts: 732
Location: Vancouver, British Columbia, Canada
Even if it's crashing, the emulator should update the saveram file on the hard drive at the time you save in-game, not only when the emulator exits. What if your computer loses power or hardware fails in some other way?
RetroArch has a crude solution: an option to save SRAM to disk every given interval. It's not ideal, but it's better than nothing.
The emulator doesn't currently work that way for other platforms. We're not changing it right now for PSX.
What happens if your power goes out? The same thing as always: you lose what you haven't saved in a program. So tell your emulator to save.
Joined: 6/25/2007
Posts: 732
Location: Vancouver, British Columbia, Canada
Fair enough. However, most emulators save when the game says it saved. I don't disagree that the current situation with SRAM is okay for working around issues with other systems like SNES which have games which abuse SRAM somehow, but it must be obvious that the current situation is not ideal for usability with memory card systems, which couldn't possibly have games that abuse memory card save blocks for cheating out more performance, since flash memory cards are traditionally super slow.
I'm not demanding a change or anything outlandish like that, but I'd like to know if anyone thinks I'm making any sense when I say that the user expects the emulator to have saved at the exact point when the software it's running says it's saved some data.
The user of bizhawk may quite reasonably expect bizhawk to behave consistently among cores. The user of any software may quite reasonably expect to be in control of when changes are flushed to disk. Savestates dont appear without the user putting them there. Why should savefiles? Because the user indicated it to the game, OK I get it. That will work, right up to the point where it doesn't.
We'll probably add an option for all the cores at some point in the future, but I'm not sure what the default should be. I'd rather work harder on training the user to be in charge of things, instead of depending on mushly emulation metaphors and automagic.
Beed, maybe it's something weird to do with UAC or having the folder in a privileged area. You tried running EmuHawk with the Windows 8.1 equivalent of admin privileges? (Most recent OS I've used is 7).
^ Probably stuff you've tried but I'd rather try and help than hold back information.
The user of bizhawk may quite reasonably expect bizhawk to behave consistently among cores. The user of any software may quite reasonably expect to be in control of when changes are flushed to disk. Savestates dont appear without the user putting them there. Why should savefiles? Because the user indicated it to the game, OK I get it. That will work, right up to the point where it doesn't.
We'll probably add an option for all the cores at some point in the future, but I'm not sure what the default should be. I'd rather work harder on training the user to be in charge of things, instead of depending on mushly emulation metaphors and automagic.
The intuition of saving in a console is that you can turn the console off and on and the save file is still there.
For the emulator it's the same idea - you should be able to turn the emulator off and on and still have the save file be there. Except now there's a 'meta turn off and on', where you close and re-open the emulator entirely. Technically it's a different operation, but it intuitively feels the same as turning a console off and on.
Savestates are different because they don't exist on a console.
Is this a bug?
1. Have the saveram folder empty
2. Start up game
3. Start movie recording from power on
4. At main menu, check that memory card is empty
5. Play game and save
6. Stop and save the movie file, exit emulator
7. Verify saveram was written to the folder
8. Restart emulator and play back the movie
9. The playback movie shows that saveram is empty
Shouldn't step 9 have desynched and went another path since the emulator should have detected saveram? If this is proper behavior, how would one go about creating a movie where they wanted prior saveram to be detected that was created in that previous movie?
It would be desynched and on another path since the emulator detected saveram, if we hadnt known that would happen and made sure it doesn't detect the saveram when starting a movie. To start a movie from an existing saveram, you need an option in the emulator which it doesnt seem we have yet.
Maybe a question of file access settings Beed28 , perhaps your files are on "read only"?
