Something else I just noticed in SNES BizHawk 1.7.2:
If I save a state and then try to play from that state, the first frame of input after the savestate doesn't seem to be recognized. eg/ if have a savestate at frame 140 and I advance to frame 146 then press Y for one frame, it will trigger an attack. If I save state ON frame 146 and hold Y for the first frame advance after loading that savestate nothing happens.
When recording a movie of an Atari 7800 lightgun game, the input display will write over itself while the game is paused, making it very hard to tell what the current lightgun position is:
Also, the ColecoHawk option "Skip BIOS intro" doesn't work at all for some games (like Mr. Do!) and causes a freeze in Venture. It seems to work fine for Burgertime though.
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?
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
I didn't say that the bug was hilarious, just that I set it that high for no particular reason (shits and giggles).
I'd say the most likely cause is that that resolution is actually bigger than the resolution my windows is running on (1366x768). Still, Bizhawk really shouldn't crash, but refuse to go that high, if that is prolematic.
Still, I don't particularly find it bad or in need of fixing, which is why I didn't make a report. I just thought I'd mention it.
Emulator Coder, Site Developer, Site Owner, Expert player
(3572)
Joined: 11/3/2004
Posts: 4754
Location: Tennessee
CoolKirby wrote:
When recording a movie of an Atari 7800 lightgun game, the input display will write over itself while the game is paused, making it very hard to tell what the current lightgun position is:
Ditto for N64 analog, and this has been true for a few releases. What would you suggest to do about it? I have no ideas that don't result in losing features
What would you suggest to do about it? I have no ideas that don't result in losing features
It doesn't do that when a movie is not being recorded. Could the same code that handles clearing the previous input outside of recording be used during movie recording?
Ditto for N64 analog, and this has been true for a few releases. What would you suggest to do about it? I have no ideas that don't result in losing features
What features depend on this, then? It's also true for any LUA drawings/text that is done outside the actual games area (so the black borders). They seem to never get refreshed/redrawn, but I can't imagine this being a feature (unless it's in that way).
Emulator Coder, Site Developer, Site Owner, Expert player
(3572)
Joined: 11/3/2004
Posts: 4754
Location: Tennessee
CoolKirby wrote:
adelikat wrote:
What would you suggest to do about it? I have no ideas that don't result in losing features
It doesn't do that when a movie is not being recorded. Could the same code that handles clearing the previous input outside of recording be used during movie recording?
Here's the problem. If you a movie loaded, input display shows you your previous frame in orange. Which is useful and nice. When you press a button, it shows you that button, which is nice too. If the button you press is a previous button, it "blends" into a light orange. This is all useful stuff, and works just like fceux and desmume for example, when the input is boolean.
For analog, that blend isn't so nice, as you see. I could drop the previous frame input's analog input, which means you don't get to see some useful information. Or I could drop the immediate analog input, and again, you don't get to see some useful information.
Which useful information would you rather not see? I have no ideas on how to deal with this logic without dropping useful information, and don't know what to drop. Hence, I've done nothing about it.
Sorry my not knowing causes fire-kirbies to appear. I'm open to suggestions.
It shouldn't be a big deal though, if you are in a situation where this is useful for you, then you are in a situation where the virtualpad is more helpful than the input display, most likely.
Thank you for explaining the problem to me, and for accepting the issue I submitted!
What if the previous input was moved a line above the current input display, like how VBA's input display works? It looks like there's nothing there now, and it should be far enough away from the frame number for both to be distinguishable from the other.
adelikat wrote:
Sorry my not knowing causes fire-kirbies to appear. I'm open to suggestions.
Lol, I didn't mean anything by the different avatar. He looks to me like he has the same expression as the Wheel Kirby one I normally use for bug reports, so I decided to post the same "mood" with a different hat.
Emulator Coder, Site Developer, Site Owner, Expert player
(3572)
Joined: 11/3/2004
Posts: 4754
Location: Tennessee
There is no "room" above, because the input display position is configurable, as is any OSD messages, so putting it above can clash with any custom settings.
Why not split up the previous input display and current input display in Configure On Screen Messages so both can be user-configurable? That way, A7800 lightgun and N64 TASers could move the previous input display out of the way, both could be visible and we wouldn't have to lose any useful information.
Joined: 11/17/2005
Posts: 278
Location: Massachusetts, USA
zeromus wrote:
ikyokyo wrote:
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.
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?)
Khaz wrote:
Something else I just noticed in SNES BizHawk 1.7.2:
If I save a state and then try to play from that state, the first frame of input after the savestate doesn't seem to be recognized. eg/ if have a savestate at frame 140 and I advance to frame 146 then press Y for one frame, it will trigger an attack. If I save state ON frame 146 and hold Y for the first frame advance after loading that savestate nothing happens.
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?
Release Notes for 1.7.2 wrote:
SNESHawk
*Fix MAJOR movie desync bug introduced in the 1.7.1 release
This worries me. 1.7.1 shipped only a month ago and 1.7.2 shipped 3 days ago. The days of "snes9x v1.43g rerecording v44" were a dark age. (Desync ahoy!) The version notes also indicate that there is a new movie format (bk2) and save state format which is incompatible with the old one. I'm sure the change is for the better, but it's new/bleeding edge etc. I'd rather use the last stable release please.
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.
Using BizHawk 1.7.3 22 July 2014, the NES ROM "Deadly Towers (U).nes" behaves strangely when pausing the game (select button). When unpausing, the screen is corrupt, and moving in most directions sends you to one of the game's hidden dungeons. This issue doesn't appear in FCEUX 2.2.2.
The Japanese version's ROM "Mashou (J).nes" does not have this issue in BizHawk for me.
<Swordless> Go hug a tree, you vegetarian (I bet you really are one)
Emulator Coder, Site Developer, Site Owner, Expert player
(3572)
Joined: 11/3/2004
Posts: 4754
Location: Tennessee
Looks like you are using the quicknes core. Try switching to neshawk by confing to config -> core -> uncheck nes in quicknes
And let us know how it behaves then.
Joined: 3/31/2010
Posts: 1466
Location: Not playing Puyo Tetris
I checked Deadly Towers (U).nes in 1.7.3 with QuickNES, pause/unpause worked for me. When/where did you pause your game? I was in the starting area (with the drawbridge (?) and moat (?) and fireball thingy.
No-Intro says this is a valid dump:
SHA1:D59DA5BF52D5ECF5F407B70FF1C32B99235676D9
When TAS does Quake 1, SDA will declare war.
The Prince doth arrive he doth please.
Joined: 11/17/2005
Posts: 278
Location: Massachusetts, USA
zeromus wrote:
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
But my xinput wasn't/isn't broken for other emulators or games. I can use a dual shock with a usb convertor just fine. I've also tried launching BizHawk with a usb controller plugged in, without one plugged in, without any USB devices plugged in at all, and it doesn't seem to matter. 1.7.3 does the same thing too. For what it's worth I do own a 360 controller, but it's wireless and I've never used it with my PC. Error message: http://imgur.com/BQke4M2
The other two issues - thank you. I'm sorry if I sounded upset, but I just got whacked with https://code.google.com/p/snes9x-rr/issues/detail?id=35 on snes9x 1.51 earlier in the same night and I was frustrated.
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
Using BizHawk 1.7.3 22 July 2014, the NES ROM "Deadly Towers (U).nes" behaves strangely when pausing the game (select button). When unpausing, the screen is corrupt, and moving in most directions sends you to one of the game's hidden dungeons. This issue doesn't appear in FCEUX 2.2.2.
The Japanese version's ROM "Mashou (J).nes" does not have this issue in BizHawk for me.
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).
<Swordless> Go hug a tree, you vegetarian (I bet you really are one)
Also, the ColecoHawk option "Skip BIOS intro" doesn't work at all for some games (like Mr. Do!) and causes a freeze in Venture. It seems to work fine for Burgertime though.
