imho, theres no solution to this which will please everyone. Until what I think is the long term solution (allow user to independently control options which affect when frames are displayed, what frame-advance hotkey does, and when input is consumed from input log) is in place, chasing a theoretical dragon will only bring grief.
Clean versions arent going to affect this any, and none of those factors you listed are likely to, either (although its barely possible for the scenes getting encoded to affect this)
You can't expect anyone else to get an OutOfMemoryException, and you can't always expect that the spot it's reported from has anything to do with what's eating memory. It's kind of random when it shows up.
However, in this case, we're lucky. The VideoCopy class contains code which allocates new large byte arrays once each frame. This is actually not good practice, and is one of several places in the codebase that would benefit from our writing our own memory manager on top of .net's horribly broken one, for use by multiple components.
For now, there's no way for you to work around it right now, apart from possibly killing as many other tasks as you can.
We know it's slow. It doesnt make sense to put (the) clear button in the lower left of that controller's panel, unless we put it in the lower left of every controller's panel. Just think about it for a while. But your multiple points about the readiness of accessing that function are received. In the meantime, try the contextmenu. I don't think I'd submit bugs about these, theyll get worked out when the code is older than 1 week old.
If it's broken in yabause, then it's going to be broken in bizhawk. All you can do is monitor yabause and let us know when it seems like something substantial has been fixed in it.
But my xinput wasn't/isn't broken for other emulators or games.
Catastrophe wrote:
I can use a dual shock with a usb convertor just fine.
Are these two statements related? Do you know what xinput is? A dual shock / usb converter has nothing to do with xinput.
Catastrophe wrote:
1.7.3 does the same thing too
The fix didnt make it into 1.7.3
I've managed to make this error happen when xinput _isnt installed_. It seems that slimdx executes a most foul mis-step and attempts to operate xinput without checking to see whether it exists. I'll add code to check for existence, not that it matters much since the previous fix was adequate.
The prereqs installer might include xinput as part of directx, i'm not sure. It's worth running anyway. If you do install it, can you check before and after whether c:\windows\system32\xinput1_3.dll or c:\windows\syswow64\xinput1_3.dll exists? That way we'll know if the directx installer dropped that file for you
no. when you see release notes containing something about direct3d or GDI display support, your problem will be fixed
hegyak, his shitty intel videocard driver is incompatible with opengl.
I've always wondered, why are the movie formats frame based and not input poll based? Wouldn't it be stronger against desyncs and more true to hardware emulation? Like, if you're to build a TASBot, it has to work off of the polling.
Tradition and convenience. Poll based input is annoying, since it creates a disconnect between input and frames, and frame-by-frame is a useful way to attack the game. Tradition, because while there is now demand for poll based input, there was originally zero demand.
I believe I solved Issue #2 in r7351. I didnt repro it or even debug it, but by inspection of the stacktrace, it appeared that there was a race condition in static methods for library initialization in the SevenZipSharp code we use, which would need to be solved by locks, which I then found in a newer version of SevenZipSharp. So, I upgraded our SevenZipSharp. Lets see if that fixes it, I'm pretty confident it will.
I downloaded BizHawk for the first time today, and I also got that error on my first run of the program. I'm sure my system isn't broken. (Whatever that means?)
It means exactly what it says. I predict you will find that any other program relying on xinput will malfunction (or xinput will silently fail to work). This would be true however many times you've run bizhawk, since I don't think bizhawk has anything to do with this. It's possible that we have a bug due to polling xinput in another thread, but at the time this exception is thrown, there isnt input in another polling yet
Catastrophe wrote:
This is kind of a big deal if it's true. Doesn't that mean that I can't provide input on a frame which I make a save state?
Do so with my blessings, but youll have to find some consensus on what a stable release is. The number of bugs found in a release may have as much to do with how much use its getting as it does with how many bugs are actually in it.
Presently, this is kind of incredibly sloppy, but different kinds of text get drawn by completely different methods. There's no way to 'fix' this nor shall there be until the methods get unified. These different methods have different performance characteristics as well. This was part of the ongoing effort to openglize things.
We should probably come up with a way to fix antialiasing though. It looks like the cleartype is applied backwards (BGR for the lua stuff and RGB for the stuff drawn by the OS). They both look blurry to me, but it is strange that the subpixel order isnt correct.
alright thanks guys, thats what i needed. this is unrelated to any other movie or snes issues 98% positively, and I'll tackle it shortly.
Issues #1 and #3 seem to be the same thing basically, and the problem is well understood. We're contemplating ways to solve it.
Well, stick with it, I'm sure you'll eventually prevail.
Thanks, but theres no source for SSF. Some other emulator or program utilizing MDF will have to be studied.
When posting an error box containing an explicitly generic error message (issue #2) can you please expand the details button?
Regarding the Issue 3, this is somewhat making some sense and sounds like a reasonable bug. The way bizhawk feeds input to bsnes (or rather, the way bsnes requests it from bizhawk) is kind of weird, and it seems like a good place for a bug. Like, the savestate doesnt remember the last input bsnes polled, and bsnes doesnt poll on every frame.
Well, its pointless to guess what he wants, without him chiming in, but if it's what I said then AutoloadLastState isnt sufficient; it would need to save when exiting the emulator. This is an oft-coveted feature for a certain type of user. Also see https://code.google.com/p/bizhawk/issues/detail?id=214
I set the N64 resolution to 2048x1536 just for shits and giggles and to see what it would look like an bizhawk crashed hard.
Works fine for me. It isnt the hilarious bug you think it is, must be some kind of mucky problem in your videocard/n64gpuplugin+game
Khaz wrote:
Another new error: "System.Exception: Libsnes internal savestate size mismatch!" Upon trying to load a savestate after making a couple trace logs...
Khaz, obviously you're discovering that something about SNES rerecording or the entire core is completely broken in general or in the way youre using it. Can you please make a new thread instead of streaming your consciousness in here?
Could you make fixed window class for BizHawk? It's alway change in every new version, examplle in 1.7.2: WindowsForms10.Window.8.app.0.3d90434_r13_ad1
Patashu wrote:
He's writing a program designed to send input to multiple TASing emulators at once to support the making of 'X games 1 input' TASes.
We can't make a fixed window class. If it's even possible, which I doubt it is, we're not going to subvert the stability of .net by interfering with its decisionmaking for window creation. Someone will have to suggest an alternative means of identifying the bizhawk window. One idea would be for us to use SetProp, and for you to use EnumProps on each of the desktop windows to find the one with the special 'Prop' set. If you can enumerate global named kernel objects (it's possible somehow but I've never done it) then we can possibly reserve a specially named item to communicate through. I am less a fan of dropping files or registry keys, they may be difficult to keep clean.
mdf + mds support is not on the radar. If you want to help, you can find some open source emulators and other programs that support them and link to them here, so we have reference materials. It will probably be faster and less work for you just to use different disc images.
Bishawk 1.7.2 throws SEHException on my 64bit Win7, can't even start.I have already installed the library that Bizhawk requires, and 1.7.1 runs OK on my computer.
Fixed in r7317. Bizhawk now ignores that error, as it did before. XInput still has the error; your system is broken, and this may be causing other problems.
Just to be clear: that some games crash when RAM ranges contain certain values cannot be taken as evidence that the certain values are impossible on real hardware.
Could you make fixed window class for BizHawk? It's alway change in every new version, examplle in 1.7.2: WindowsForms10.Window.8.app.0.3d90434_r13_ad1
Could you tell us why you want such a thing? We might could attach additional information for the window that your thing-which-you-shouldnt-be-using could pick up to identify it.
perhaps your system has a buggy opengl driver. you can use config > cores > n64 video plugin settings and pick a different video plugin. also your windows event viewer application log will have more information.