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.
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.
Since Mupen64-rr is obsolete, there are still some N64 games that can run on Mupen64-rr, but won't run at all on BizHawk, such as BattleTanx. I hope we can get every N64 game to run on BizHawk.
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.
I did see that "Flush saveram" option, but I always assumed it was a bad thing? I mean, flushing sounds like you're getting rid of the save altogether?
Let me see if I understand what you're saying by "clobbered". Basically, I make a save state on point 1, then I make a memory card save on point 2, for some reason I load the save state back to point 1 and the memory card save will be wiped out (or reverted back to whatever it was when you made the save)?
To me that sounds completely logical, but I understand why some people would be confused by it. How about keeping both as an option?
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.
Make it an option sounds better since people can pick and choose. However, it's your choice as to how you want to implement it. I'm all for having options though.
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.
Yes, I tried Wild Arms and over 10 other games, and I wasn't able to save to SaveRAM. I mean, the save was made, and as long as the emu was open I could reset and the save would be there. But if I closed the emu, no SaveRAM was created.
BUT, I had never ever used the Flush saveram option. I just tried it and now the emu did create the .SaveRAM file and the save I made was there after closing/opening the emu.
I know you said you prefer if that process is done manually, but personally I would rather have it work like other cores/emulators, in which the .SaveRAM is created automatically as soon as you make a memory card save.
As for not wiping memory card saves when you Load State, I've found that's more trouble than what it's worth. I've played plenty of games/emus where RAM saves are independent of Save States and sometimes I've wanted to go back to a previous RAM Save, but I couldn't because Loading a State wouldn't revert back to the previous one.
But again, if both options could be implemented then everyone would be happy-er.
I rewrote the framebuffer screenshot option. Doing it right was about 1000x more work and 2x better.
Awesome. I understand it's useless to you, so thanks for taking the time to do that.
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.
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.
Well you can make the option work like you stated by default, but leave an option for it to happen automatically if one so chooses (like in my case, or older people that have used other emus before).
But if you're completely against it, then I can get used to it.
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)
There is already an option to back up RAM (Customize -> Advanced). And it does work for me. What wasn't working was the emulator creating the .saveram in the first place. But I guess that was because I wasn't flushing (ermm...).
But when I manually flush, it works just fine. But it definitely doesn't flush automatically for me when I close the emu.
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.
I just hit the X on the top-right. Or I press Alt+F4.
But I don't have that text console thing. I believe I disabled/enabled some option where only the actual game window opens, and not another separate instance.
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.
Just tried it again, just to be extra sure. I picked an RPG, started a new game, went to a save point and saved. I closed the emu, and the .saveram was not created.
If I manually flush, then it is created just fine.
If that's how it's going to be in the future (manual), then there's no point in getting used to automatic flushing :P
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.
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.
Probably the latter. I try a lot of games, games people wouldn't even dare to touch.
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.
Zeromus, I noticed you (or someone else?) added some deinterlacing option to the PSX options (weave, bob, bob offset). Thanks for that, but could you tell me what the difference is between them?
I noticed that weave is kind of like default. Bob and boboffset makes it look better, but what's the difference between those two?
ReyVGM, google for the difference between bob and weave, theyre standard concepts. I have no idea what boboffset is, it's just something mednafen has and I exposed it. You can ask the mednafen psx docs for details. Deinterlacing styles is one of those opinions are like armpits things, so I just give you whatever options we already have and try not to inhale too deeply.
Kurabupengin, looks like it failed compiling an "optional" shader. I didn't intend for that to happen. Optional shaders should be optional. I just committed some changes which should make it more optional.
there's a lot of problems with the retroarch shaders. main problem right now is the sampler must be named s_p. Other shaders have other problems. The retroarch common-shaders repository seemed completely derelict and I never had the enthusiasm to wade through it because I don't actually care about shaders. So I can't tell what's worth trying to save in there or get interested in figuring out what the retroarch folks even think should be working. Seriously, some of them seem totally bolloxed. Plus, I haven't implemented support for some of the other features (textures, parameters). It'd be nice to have someone go through there and become the subject matter expert though, and feed me things to fix one by one.
My few experiences with retroarch shaders are someone says "this doesnt work" and I say "well, this is wrong, and this is wrong, and this is wrong. Once you fix it, it works". Retroarch appears to use some kind of telepathy algorithm to determine what you want the shader to do without actually having to compile it.
I would be ok with shipping a shader library with bizhawk, if someone wants to stay on top of curating it.
While fully supporting RA's Cg shaders would be nice/convenient, it's not really necessary. As long as the capabilities are there in whatever homegrown thing he wants to implement, porting shaders between individual programs (that is, renaming uniforms, etc.) and even different shader languages isn't usually that difficult (with some caveats, of course).
I'm not sure what zeromus meant by saying the common-shaders repo is "derelict." AFAIK, everything in there works and is up-to-date, though it's obviously not curated. That is, there's a bajillion CRT shaders, another ton of smoothing shaders, a bunch of helper shaders that aren't very useful on their own and so forth. If that's too much, there's always the quark shader repo, which contains mostly-standard GLSL ports of most of RA's popular shaders.
Joined: 1/26/2014
Posts: 49
Location: United States
Wanted to see if anyone could help with this issue we are having...
nathan7878 wrote:
So I tested the credits call on Bizhawk 1.11.3 and the emulator is still crashing.
What would really help me to be able to solve this issue is if when Bizhawk crashed
it would show the illegal opcodes executed by the glitch in the Log Window.
I am still getting familiar with Bizhawk, so if anyone knows how to do this it
would help a lot. I made a video showing what is displayed in the Log Window
when the credits call is performed correctly on PSXfin 1.13, and also what is
displayed in the Log Window when the credits call is performed incorrectly/fails
on PSXfin 1.13... next is shown what is displayed in the Bizhawk 1.11.3 Log
Window when the credits call is performed correctly but fails.
I will also post this in the Bizhawk Emulator Development thread here http://tasvideos.org/forum/viewtopic.php?t=12549&start=950Link to video
my GPU sucks so much
