criticom formats the saveram before the title screen even shows up, and the .saveram flushes just fine when the emulator exits. I suggest you delete your config.ini where youve broken something.
OK, then either your system is haunted, or you're the luckiest guy in the world who keeps picking only the half dozen games which are haunted in bizhawk.
It definitely doesn't flush automatically for you when you close the emu because the game hasn't saved yet. If you say otherwise, then your system is haunted. We'll have to wait until someone else's system is similarly haunted to collect more data.
I get "with .SRM" by pressing A at the main menu. Whether or not there's .srm seems to be irrelevant.
The only problem I see is NG for "RTC BACKUP". Does this work on bsnes 0.87 or lsnes? I find it hard to believe bizhawk is doing anything different here than bsnes 0.87. I think you havent setup anything wrong.
Flush as a technical term means save stuff that's been changed.
You understand clobber correctly. I already mentioned an option and explained that I don't like it. This option is confusing and it hasn't been well received in the past when other emulators have tried it. Most people aren't aware of the issue at all and won't use the option. But if theyre forced to manually save, more people will have an inducement to learn whats going on and take charge of something which they really need to be in charge of.
If I do force users to flush saveram manually, I will probably still add a system to automatically dump a backup saveram every time the emulator exits (except for you, since it apparently never happens for you) so that in case someone freaks out, they wont have a complete data loss--they could manually fix it from the backup. That's in keeping with a bizhawk methodology of crappy out lots of backup files just for safety's sake. But anyway that's all controversial and we'll need to discuss it more.
How are you "closing" the emulator, anyway? It positively is ordinarily flushing the saveram when it exits. Maybe some codepath doesnt flush the saveram. Closing the text console window doesn't, and theres almost nothing we can do about that, so don't close the emulator that way. Closing the text console window is about like killing the process.
client.SetGameExtraPadding() seems unusable to me, so I want to explain here why. I think I would have prefered a "client.SetGameExtraMargin()".
I don't know what the difference between padding and margin is. Anyway, the stretching was caused by a bug I just fixed. It should have only been visible in >1x window scales.
MUGG wrote:
Furthermore, my GUI is moved up which I don't want
You must mean "buttons" (and not text) when you say "GUI". But you got precisely what you asked for: a new space above the game, and things moved into it. So the buttons moved up and you didn't want them to? Then move them back down. If that takes more than 0.5 seconds of work, then youve coded your script wrong.
Unfortunately, I think GUI.Text presently doesnt work on the "emu" surface, it works on the "native" surface. So when you add GameExtraPadding, some things will move, and other things won't.
I just added client.SetClientExtraPadding which should let you add the padding at the other layer.
Shouldn't the emu create the .SaveRAM as soon as you save a game like on a real PSX? Or at least create the file after the emu is closed?
(First option is better though, in case there's a crash.)
It's working fine for me. Skip 2 paragraphs to find out why what's going wrong for you, probably.
Bizhawk flushes when the program is closed or when you do it manually through the file menu. I'm thinking about trying to press for automatic savefile flushing to be removed entirely. The whole concept is problematical. Flushing continually means that whenever you loadstate, your saveram is also clobbered. Some people expect this. Some people don't, and theyre baffled and surprised by it.
The only way to resolve that is to make flushing a manual step, or make it an option. I prefer the former, because it's just like any other program, right? Edit your document, save your changes. I think it was _mistake_ for emulators to do it any other way. We've got used to it, but it's a bad idea.
The PSX core does work a little differently with saveram than the other cores. Unless the game actually modifies save ram, nothing will get flushed. So you won't get a saveram file until a game actually saves something. If you've been testing a game that doesnt save, or testing it before the point where it saves, then you may never see saveram go out to the disk. Please confirm whether this is the case.
I rewrote the framebuffer screenshot option. Doing it right was about 1000x more work and 2x better.
I have a .cg shader that works in retroarch, but bizhawk asks for .cgp. I rename it and it tells me length must be greater than zero as an exception.
.cgp and .cg are completely separate things. Create a .cgp which references the .cg. In principle it is impossible to load a .cg without a .cgp but I suppose a built-in boilerplate .cgp can be used in case a .cg is referenced directly. That must be what retroarch is doing, I just have to figure out the correct boilerplate. I'll do that eventually.
Here's a .cgp I tested with:
There are problems with your .cg:
1. There's garbage near the first call to sin which breaks compilation
2. the sampler must be named s_p. It's not possible to generally make a retroarch shader without using the correct uniform names. I might could add an exception for the sampler, but I don't see why I should, when the other uniforms still need to be named correctly. I'm not sure whether retroarch is violating it's own spec here as I don't think the specs are all that well written and it's not covering this question precisely.
Note that many of the shaders in retroarch's shader library are broken. You can't always rely on them for examples. Retroarch may also be lax in its implementation of its ambiguous specs.
You can see the results of compilation in the console log window, but the line numbers are a little bit off.
so don't name it function, name it a.
you can't just write a at line 5. since when do you call a function by just writing the name of the function? you call a function by writing the name of the function and then (). if a is a function, then a() is calling function a.
You know how to make a function, because you wrote the drawPosition function, so why is the very first line of your script attempting to create a function some other garbledy way?
why are you trying to name the parameter a()? parameters dont have names with ().
This kind of thing is typical of shoddy programming. Direct3d has this stupid feature where if the system sleeps or ctrl+alt+dels, you have to re-initialize basically everything yourself. I forgot to do that.
When I tested it, the emulator prevented me from doing that. With both keys and with named states. Perhaps you're using a version of bizhawk from 1 million years ago.
The SNES core is not freezing or crashing frequently, or for most roms. Your system is definitely hosed. Other emulators, doesn't matter. Count your blessings if you can use them on a hosed system.
Loading times in mednafen and (other emulator) positively differ, and are inaccurate in either case. I'm not sure what the politics here will be, that's not my department.
fyi, TAStudio isn't finished. I'm not sure how you're able to use loadstate with it. The emulator is designed to prevent loadstating when TAStudio is involved. If you've found some way around that, I'm not surprised it malfunctions.
When tastudio crashes in the middle of saving a movie, it should be no surprise that the movie is then broken.
"some error message" & "some error message about dragging movies"--you can do better than that.
Can't reproduce your issue with ram watch minimizing while clicking back to the emulator for fullscreen. I doubt it very much. At any rate, config > customize > accept background input should let you issue gamepad input while ramwatch is focused. "Have to select a small window" <-- that's the way most people do it.
Emulator crashing all the time sounds like a problem with your computer, although the SNES core is reportedly kind of frail and can crash. Size of the game screen glitches sounds impossible though. You know, some games can change the size of the game screen. If the game is crashing in the emulator, it can make the window size go nutso. None of our cores are especially vulnerable to that, unless youre using corrupted or badly programmed homebrew roms. Screen going white at the same time the size is glitching is certainly in accord with this theory.
Emulator crashing all the time and games (which one?) crashing all the time sounds like major overclocking stability issues.
Running at 2fps sounds like major dusty fan overheating issues.