Emulator Coder, Site Developer, Site Owner, Expert player
(3576)
🇺🇸 United States
Joined: 11/3/2004
Posts: 4759
Location: 🇺🇸 United States
I goofed and made an "interim" build instead of a release build. Also we noticed that opening the N64 plugin dialog when a game is not loaded throws an exception. So I made a 1.6.0a release that fixes these issues and updated the previous post to link to that binary.
Joined: 3/31/2010
Posts: 1466
Location: Not playing Puyo Tetris
I wanted to thank everyone who works on this.
For those that are curious, 32X emulation will not work at all. Sega CD/Mega CD + 32X games like farenheight, will work properly in Bizhawk. Though, they may be less accurate/graphical due to the lack of 32X handling graphics.
When TAS does Quake 1, SDA will declare war.
The Prince doth arrive he doth please.
I goofed and made an "interim" build instead of a release build. Also we noticed that opening the N64 plugin dialog when a game is not loaded throws an exception. So I made a 1.6.0a release that fixes these issues and updated the previous post to link to that binary.
Thank you! Also since you are housing the binaries at source forge now will google code still be the page for everything else? Like bug reports and feature requests?
Projects:
Interested in TASing N64 Mario Golf.
GBA Mario Tennis: Power Tour is on hold.
Finally a proper GameBoy (Color) emulator that works with TASing! Excellent work! (Sorry VBA...)
Is it on the TODO list to update the bsnes core to v91? While most of the changes since v87 are GUI stuff there has been some minor accuracy improvements if I remember correctly.
Well I would like to see a new version in BizHawk (current version is v94). Adelikat described adding bsnes core a "freebie" so it might happen. I have read the changelogs and their are some minor accuracy improvements notes (whether it's for textures or text or timings etc.).
Projects:
Interested in TASing N64 Mario Golf.
GBA Mario Tennis: Power Tour is on hold.
There's still an issue with the flickering in Paper Mario. It does not flicker when using the Glide64 'Final' plugin in Mupen.
Previous TASes:
Frogger's Adventures: The Rescue
Paper Mario: The Thousand-Year Door any% x 8
Paper Mario 64
Luigi's Mansion
Sonic Heroes - Team Sonic
Mario Kart Wii ILs
No... It uses some other version of it I'll assume.
Previous TASes:
Frogger's Adventures: The Rescue
Paper Mario: The Thousand-Year Door any% x 8
Paper Mario 64
Luigi's Mansion
Sonic Heroes - Team Sonic
Mario Kart Wii ILs
Buddybenj has it right. See this post, which links to a frontend for mupen64plus that includes an updated glide64mk2 that fixes the Paper Mario flickering (in other words, the plugin is confirmed to work for mupen64plus).
Can this glide64mk2 be implemented into BizHawk, either as a replacement for the current one or included alongside it?
I've noticed more of a global issue, namely the aspect ratios on the 2d games are wrong. While the pixel dimensions of course vary, the aspect of every system except for the portables is supposed to be 4:3.
Yet on nes/snes and I'm sure others the screen is too narrow, even in fullscreen mode. Before someone mentions the option that cuts off the garbage pixels, that is stuff that would have normally been in the over-scan area of the tv. The main gameplay area is still supposed to fill a 4:3 crt television.
You are correct. When cropped to 256x224, NES should assume a roughly 4:3 DAR.
I think more flexible output aspect ratio control is something we'll probably be looking at once the new video output changeover is done.
I wasn't aware that you guys were working on the video, my bad. It's a lot of pages to read through.
I don't know if you guys are taking requests but on the lua end of things it would sure be nice if there was a command to get the rom name. Making universal scripts is difficult because of this. Nothing fancy is needed... shoot just pass the command line along to lua and I'd be happy.
I got around not being able to get the file/rom name on the stand-lone emulators via reading the header from the cart, but that isn't an idea solution tbh as the names aren't the same.
howardC, you need to define right and wrong more rigorously. our emulators are displaying 'right', as defined by a 100% of other emulator cores and an analysis of the output of the 2d image generation circuit in the original console. bizhawk is displaying 'wrong', as in, it strays too far from what you would expect to see on a CRT television. Some televisions will let you distort the image to create a variety of aspect ratios. Some televisions are broken and create a variety of aspect ratios. What you want is a filter which mangles the pixel-by-pixel-wise 'right' image to a format where pixels are munged together to take on a shape more similar to what you're accustomed to, a feature which only 2% of emulators have. If that were truly "right", and that was the only option we offered, there would be a chorus of outrage--because it isn't right.
When asking for this feature, you ask for an "aspect ratio correction filter".
With all due respect, these are emulators of home consoles from the 90's and before. At the time, consoles were designed to be ran at one and only one aspect ratio, namely 4:3. Resolution was irrelevant because at this time video going into a tv would be analog and the tv would sync it and stretch it to 4:3.
You mention things like broken tvs and differences in televisions, that's defective equipment for one thing and secondly has nothing to do with the aspect ratio.
These machines were designed to display on a 4:3 crt television, so the only correct aspect ratio is 4;3, period, end of story. There are complications of course... all analog signals have a certain degree of garbage space to compensate for the differences in the televisions you were talking about. But when all is said and done, you get a 4:3 picture.
So you can argue and justify all you want, but again with the upmost of respect, once all compensating and cropping is done, the result is a 4:3 image. That is unless your goal isn't emulation accuracy. You aren't just emulating the digital aspect of the consoles but also the analog aspect, which is how the timing and what-not of an analog tv takes a 240p image or what have you and makes it display as a 4:3 image on screen.
You are displaying the correct pixel dimensions, but again, the incorrect aspect ratio.
HowardC, you don't get to define emulation accuracy. People who have been making emulators for many years get to do that. I guess I made it too complicated. Lets try it more simply. The correct aspect ratio AND the correct digital pixels cannot both be displayed simultaneously in one window. If you want incorrect digital pixels, you can get correct aspect ratio, and this is done by a post-processing AR correction filter.
In the emulation world, `accuracy` has been defined as the correct digital pixels. You can't change this, and I can't change this. If you use the unqualified `accuracy` in your own privately backwards way then you'll just be flapping your lips instead of conversing with people who have correctly apprehended the conventional meanings.
If you wish to use the words 'analog accuracy' to distinguish from just plain accuracy, which is assumed to mean digital accuracy, then you may, without being confusing. In that case, I agree, in many ways both audio and video, bizhawk's 'analog accuracy' is below ideal levels.
By continuing to discuss `accuracy` as if you have a right to define it, you make me imagine more vividly the day when I add a AR correction filter and get to hear you say 'i told you so, now your emulator is finally accurate' which makes me correspondingly less likely ever to do it.
For those that are curious, 32X emulation will not work at all.
Is that just for now, or is it the policy of the BizHawk developers to refuse to add 32X support?
That's kind of harsh, innit? There are about 9 million things I could be doing with my life. Some, I'm doing right now; the rest are goals of various importance and urgency. Am I "refusing" to do anything that I'm not currently in the process of doing, right this very instant?
Out of those 6 options, which one should I choose (that gives the best quality) for dumping on 720p?
These are container formats. Quality depends on their characteristics and settings.
AVI - Can store video of almost any codec (Camstudio etc.) and audio in certain formats (afaik variable-bitrate MP3 (MPEG-2 Audio Layer III) is not supported).
JMD - ?
WAV - Audio only.
FFmpeg - This is a software package that you need to configure - think Handbrake.
Out of those 6 options, which one should I choose (that gives the best quality) for dumping on 720p?
