So I'm playing Majora's Mask and I've noticed 2 graphical bugs (Pure Interpreter, Jabo 1.6.1, Z64 Hle video:
1. When you pause the game and leave it on the pause screen for a few seconds, the background becomes black instead of transparent, and when you unpause, the window appears a bunch of times over itself, like on an old Windows computer when you would drag a window around and it would duplicate itself wherever you dragged it.
2. When talking to the old lady in the Stock Pot Inn, when she starts one of the cutscenes (Carnival of Time or Four Giants), it doesn't display the proper graphic; instead, it displays a picture of the last time you paused the game.
There's also a minor audio bug; occasionally, the sound will bend in pitch oddly for a few seconds.
we need to start a separate thread for n64 aesthetic emulation fails, with a sticky stating the rules for the thread
1. test what happens in mupen64plus
2. if it's jabo, test what happens in mupen64 using jabo as well.
did i get that right?
Unfortunately, I was unable to test on either mupen64 using jabo or mupen64plus. Using jabo in mupen64 resulted in nothing but a black screen (with perfectly functioning audio), and I have no idea how to set up mupen64plus. I didn't know how to set the controls or other options, and as such, I didn't make it past the title. I tested with the other video plugins on N64Hawk, and found that both glide64 and glide64mk2 work (neither of the glitches happen). Rice doesn't, but the glitch is different; instead of showing your last pause, it just renders the game normally, as if there were no cutscene. There's also the issue that I have no save on the other two emulators, which disables me from doing the old lady glitch. Unsurprisingly, the unrelated audio weirdness occurs no matter which plugin I use.
Furthermore, we should have a separate thread for SM64, OOT, and MM.
Anyway, if you can't verify the behaviour in mupen64plus, then there's nothing we can do. It is bizhawk's job to emulate exactly like mupen64plus. No better and no worse. But there is a large amount of lore about MM in mupen64plus, so perhaps you can find out what the state of the art is without having to test it yourself.
So... that's it? Like I said, I'm fairly certain the problem lies within the combination of N64Hawk(mupen64plus) and Jabo D3D8 1.6.1. Is there just nothing to do about that? Surely someone else can perform some more extensive testing and figure out the issue, or at least tell me what to do to test them.
He who cares most should test most.
Er.. test jabo in project64, where it originally came from. I misspoke earlier.
You can't be certain the problem lies in bizhawk+jabo until you test mupen64plus on its own and jabo in its native environment. It takes a high amount of lore to get those games to emulate well in any emulator. If you had enough lore to be fairly certain, youd be fully certain.
It looks like save files should be portable between mupen64plus and bizhawk, but I havent confirmed that.
That one is actually known.
But OceanPrince (at least I think it was him, man my brain is mush) couldn't find a way to fix it and since it only happened after 10 seconds and TAS will never spend that much time in the menu, it was seen as low priority.
That's kind of a problem.
Jabo doesn't work in mupen64plus and never will, so there is no correct emulation in mupen64plus with this plugin. The only benchmark for this one is PJ64 and PJ64 doesn't have these bugs.
I had already corrected myself, but OK. If theres no similar bugs in mupen64plus, nor in jabo in pj64, then it's a candidate for bizhawk debugging. But it sounds a lot like an emergent bug between mupen64plus and jabo that we wont be able to fix and at any rate I doubt it's gonna be debugged at all unless someone delivers a savefile.
I just tested in PJ64 2.1 using Jabo 1.6.1 (I used the same .dll as the one in my BizHawk directory), and found that the pause graphic bug still happened, meaning it's a bug with Jabo, and not N64Hawk. I didn't test the old lady bug because that would require beating 3/4 of the game, but I feel rather confident it would still happen because the game looked identical in all aspects on PJ64 (this logic is very shaky, I know). So we can assume it's a bug with Jabo--what do I do now? Also, I resent the logic that a bug is given low priority simply because "TASers never stay on the pause screen that long"; it's an emulation bug and should be properly dealt with. I know it seems weird to say it on this site, but TASers are certainly not the only people who like to use BizHawk (myself included).
The logic isn't very shaky. it's certainly not solid, but it's probably a good guess.
Your logic about priorities is much less sound. I already explained bizhawk's job here: it's to emulate as good as and no better than the original n64 emulators. Our job is to bolt a bearable frontend on them. We dont have the expertise or time to fix n64 emulation bugs. The 'low priority' mentioned earlier probably means a low priority on studying which combination of hacks results in that particular scene working better. That's your job, if you care about that scene; and nobody else's, if they don't.
What now? nothing more than what I've already suggested.
So is it even possible to get anything N64-related fixed, that isn't purely cosmetical? Like wrong physics?
Just asking, because I'm not really sure if it would be of any use if posted such a thing on the issue tracker.
Current project: Gex 3 any%
Paused: Gex 64 any%
There are no N64 emulators. Just SM64 emulators with hacky support for all the other games.
Emulator Coder, Published Author, Site Admin
Zeromus' analogy is spot on, we just bolt these things together and provide it to you. N64 work is the resposnbility of the mupen64plus team.
However there is a chance it is the "bolts" themselves in which case it is our problem. Most likely this isn't the case though. They way to determine that is to see what happens in mupen64plus. And in the case of jabo, since it doesn't exist for mupen64plus (outside of bizhawk), you can use PJ64 as a guide, but even then you are just guessing what the behavior would be.
So in summary, it is good that people are getting interested in mupen64plus and its emulation issues, but you shoudl be vocal with the mupen64plus team, not us. All we can do, is port in updates.
I just want to note how huge of a project BizHawk would be if the devs had to take responsibility for the proper functioning of every emulator it fronts. It's already a big project done entirely by volunteers; let's not make their lives any harder than they are already. :) As adelikat and zeromus have noted, if there's a problem with the function of a specific emulator, then the primary responsibility for that problem lies with the developers for that emulator. And as always, the best way to get a problem fixed is to fix it yourself.
Pyrel - an open-source rewrite of the Angband roguelike game in Python.
Sorry, I overlooked that somehow.
It's more that it's not worth the hassle of searching for days for such a minor graphical bug, which probably wouldn't even yield results, when it doesn't effect normal play at all and will not show up in TASes either, where viewers might be confused.
Grandma's stories are more problematic than the pause menu, but if it's not a bizhawk problem, it's not a bizhawk problem and since you said yourself that this bug even happens in PJ64 2.1, it probably isn't.
With some luck there'll be a new version of GLideN64 in 3 months, that emulates this game without a problem, anyway.
Location: Teresópolis - Rio de Janeiro - Brazil
Weird, since version 1.7.4 the Lua is gone and I just noticed because of your post... maybe lack of updated scripts? If so, we can copy an old folder and it should suffice.
Is this correct? (Version 1.8.3, September 25)
I am old enough to know better, but not enough to do it.
Location: Not playing Puyo Tetris
Yes. The version and date are correct. I always put the date a little farther ahead of schedule just incase major error popup and we need to delay a release.
The LUA scripts will be coming back in 1.8.4 or 1.9.0 (Which ever comes first).
It's supposed to be 1.8.2 but I guess it was so good, it skipped that and became 1.8.3
When TAS does Quake 1, SDA will declare war.
The Prince doth arrive he doth please.