I'm not sure if this is the same ROM or not. The MD5 of mine is 8df0104553f85bc585b2ef7c199e7c13, which doesn't match what hegyak posted.
hegyak wrote:
When/where did you pause your game? I was in the starting area (with the drawbridge (?) and moat (?) and fireball thingy.
That's the same place I was, but I can make it happen in at least the first few rooms (I didn't try too far after that).
does bizhawk say that your rom is a good rom? if not, get a good rom
Thanks for fixing the N64 virtual pad so fast.
But for some reason emulation slows down to about 30fps (which is a slowdown of about 90fps) when the virtual pad is open. That did not happen in previous versions of bizhawk. For example 1.7.0 doesn't have it.
I'm also sad that you have hidden the clear button in a submenu, when on the lower left there is so much space left. It's supposed to be easily accessible and be faster than clearing the buttons manually. The button cimbination isn't great either. It needs the right hand, meaning you have to take that off the mouse.
Those might seem like minor details, but if you have to try out a lot of things it adds up.
Should I submit bug reports for the first or both? Or are there inescapable reasons for this?
Also thanks for accepting my request to turbo to a certain. Frame. I hope it being marked as low priority doesn't mean it will sit there for years. Mupen-rr has that helpful option and it's hard to convince TASers that bizhawk is better when options are missing.
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.
Okay.
Why is it slow? What did you do so much differently? Just interested. :)
Maybe just have the clear button directly under every controller then? I wouldn't mind the virtual controller being a little taller. People who don't want it can just resize the window to hide.
Joined: 3/31/2010
Posts: 1466
Location: Not playing Puyo Tetris
Beed28,
I don't have your exact error but I do have an error when I load a savestate for SGB.
Google Code Bug report:
https://code.google.com/p/bizhawk/issues/detail?id=224
What ROM(s) have you tried? Are they verified good dumps?
When TAS does Quake 1, SDA will declare war.
The Prince doth arrive he doth please.
Joined: 3/31/2010
Posts: 1466
Location: Not playing Puyo Tetris
Fortranm wrote:
FDS All Night Nippon Super Mario Brothers
The game stayed in black screen after I entered any of the four warping pipes in 4-2. I was using Luigi.
I have confirmed that the screen is black for quite a while but it does load the areas for me. I used the warp pipes to World 6, 7 and 8 from the Vine Warp Zone in World 4 and they all loaded. It just took a while. Good SHA-1 Confirmed ROM used.
When TAS does Quake 1, SDA will declare war.
The Prince doth arrive he doth please.
NesHawk's FDS mapper emulates loading speeds as being very very very slow for some games, relative to other emulators like FCEUX. I've looked through what information I can and I believe NesHawk is behaving correctly here; it should really be about that slow on the real console.
Does anyone else regularly have capturing problems when capturing high resolutions of n64 games? 1600x1200 or above, usually on graphically intense scenes and more frequent with glidemk2 as opposed to rice. Banjo Tooie was doing it a lot at one point. I'll capture the error when I see it next.
I'm not as active as I once was, but I can be reached here if I should be needed.
Does anyone else regularly have capturing problems when capturing high resolutions of n64 games? 1600x1200 or above, usually on graphically intense scenes and more frequent with glidemk2 as opposed to rice. Banjo Tooie was doing it a lot at one point. I'll capture the error when I see it next.
Yeah, we're going to need some more specific information on what exactly is going wrong.
Apologies, I was trying to re-create the error but managed to go a day without it popping up.
After which closing the application still leaves it running as a background process.
I've found that in some cases, deleting BizHawk and extracting a clean version will allow me to avoid this error at first, but it's not always the case. It's just more likely to work. It's been a problem for me since 1.5.1, and is still apparent in 1.7.3 as far as I can tell.
I'm not as active as I once was, but I can be reached here if I should be needed.
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.
slowking, half of our users are using computers twice that old which cost half that much when they bought them.
encoding videos of that resolution will burn through 1GB in 2 seconds. If .net falls behind in GC for just a split second, boom, the memory's run out. It's unacceptably stressful to .net no matter how much ram you have.
Apologies, I was trying to re-create the error but managed to go a day without it popping up.
After which closing the application still leaves it running as a background process.
I've found that in some cases, deleting BizHawk and extracting a clean version will allow me to avoid this error at first, but it's not always the case. It's just more likely to work. It's been a problem for me since 1.5.1, and is still apparent in 1.7.3 as far as I can tell.
The FFMPEG writer should do much better on memory than the AVI native writer, for a number of reasons; somewhat more efficient code as well as putting the video compression's memory usage in a different process. Capturing Saturn at 1600x1200, I don't go over 300MB with it in a short test (compare with over 900MB with AVI native writer).
(Note that I still want this in the bug tracker to remind me of things that need to be done).
slowking, half of our users are using computers twice that old which cost half that much when they bought them.
Well it's a laptop, so a normal PC will have similar specs for half that price. Probably not if they are twice as old, I give you that.
encoding videos of that resolution will burn through 1GB in 2 seconds. If .net falls behind in GC for just a split second, boom, the memory's run out. It's unacceptably stressful to .net no matter how much ram you have.
Yeah that 1GB limit seems like the bigger problem. That was what I tried to say originally.
Using Bizhawk 1.7.3, on Ram Search, you can resize the window, but you can shrink it beyond where the buttons are, and thus can longer click the [/O Search ] [Z /O] buttons. Fixable by making the window larger again of course, but it'd help if there were proper minimum sizes defined.
Rewinding also crashes, except without the above message.
After which closing the application still leaves it running as a background process.
I've found that in some cases, deleting BizHawk and extracting a clean version will allow me to avoid this error at first, but it's not always the case. It's just more likely to work. It's been a problem for me since 1.5.1, and is still apparent in 1.7.3 as far as I can tell.
