You can see in latest revisions I'm attempting to screw around with this. Currently my efforts have revolved around snipping the wanted data out of the larger NTSC framebuffer mednafen generates. I've got that working pretty well, but the code is very dirty, and I may have to dump it some day. I'm not very happy with it, but I'm following the experiment through to the end and I learned some stuff about how mednafen's put together I needed to learn anyway.
It's not entirely clear how this should work for interlaced modes. If you want to see the actual framebuffer that could be arranged, but it will alternate between lower-resolution fields for interlaced modes. If you want the higher resolution interlaced image, then it needs to be interlaced separately (not going to happen) or the snipping approach needs to be used.
The code to just literally dump the framebuffer would be far simpler. There are some conceivable downsides, besides the interlacing thing: some games may be rewriting part of the framebuffer after it's scanned out, and some games may be changing the framebuffer mid-frame (split screen maybe, or with a NES-style status box). There are probably at least twice as many things which would be inconceivable until you saw a game do it. (some PCE games are even changing resolutions mid-frame)
I may add code to drag the framebuffer out later, but it would be part of a VRAM view debugging tool.
If the option is already there, what's the harm in making it clip the entire overscan instead of just a part of it?
It's been done the way it's been done for reasons I don't know but I assure you ryphecha has studied it more than you have. The harm would be: flouting those reasons.
The amount of "overscan" is kind of arbitrary I think, the concept is generally ill-defined. NTSC may specify it but games may disobey it and consoles may stretch it. Therefore the amount of overscan chosen originally for mednafen was some kind of compromise which cuts out as much as is safe in most cases, I would assume.
It's cool that feos found some knobs to twist, and that he found something it doesn't work right for within the first 2 seconds of the console being booted. Primo example of what I'm talking about there. There will be other cases.
Maybe I could add an option to the display options that will let you crop any console's video by a specified amount.
OK, since you're never ever going to get a special screenshot mode, what you actually want is another PSX "resolution management" option called "ReyVGM's Undo Mode" which undoes a bunch of hard and cutting edge work mednafen does to emulate a stable television picture. I'll file that under todo: never, mostly because nobody's going to be mangling mednafen sources to the degree required to achieve that any time soon. In the meantime, use imagemagick.
I'm talking about all consoles. I'm not going to add a hack to the screenshot code just for PS1. Besides that, every mode in every game is changing the resolution settings. Games are putting content in "overscan" sometimes and leaving gratuitous empty spots other times. Chrono Cross is fiddling with the video registers to wiggle the screen within the overscan area during some earthquake effects.
Even if I analyzed the mednafen code to find a way to determine what was "overscan", which I'm not going to do, it would still be unreliable. Moving that information out of the PSX core and to the point where a screenshot can do it is architecturally outrageous.
"No emulator takes framebuffer screenshots with overscan added to them": Overscan isn't "added". Overscan is a natural consequence of more precise emulation. Emulators without that overscan are bugged.
You don't understand. Overscan isn't as simple as pointing at black and saying "I don't want that." With this, I am done talking about overscan.
If you're about to do millions of screencaps of a single game, you need to invest in a process. I can write a program in about 5 minutes that will crop every file I drag onto it to a fixed rectangle. Imagemagick can do it out of the box.
I don't think anyone will ever do this.
Given that theres so many different differing black bars between various consoles and games, I think the only way I would ever implement this would be by an 'auto-crop screen shot' function which would scan for continuous bar areas and remove them. This would be annoying in many cases and would default to off. I've never heard of a feature like that before in any emulator.
I explained from the very beginning that this is a holy wars subject. Some people want it one way, other people want it another. Thus it has always been and so shall it ever be. Don't waste breath trying to change minds, you may as well be trying to convince a PC user that macs are great or vice versa. Your fresh view is welcome on any _other_ subject.
So let me get this straight. You're looking at a screen that contains a directory called "Nintendo - Nintendo Entertainment System". You could click that. But you want a button that says NES to click.
We will not edit this dialog box. Optional and out of the way is the only way it will ever show up.
If you invested the time in learning how to use your computer that you invest in complaining about how slow it is to do something on it, I'm sure youll discover that eventually you'll be good enough that it won't be slow any more.
disassembling a PSF is easier, no unrelated graphics or logic code to go through. Not that I've ever done it before.
I do intend to rip the entire instruments and then replay them in my own modular synthesizer. I told you it's a long term plan...
Why are you interested in bizhawk's psf anyway? I've added it because of a long term plan to disassemble some music drivers and add SPU/SPC visualizers, and probably make some instrument ripping tools.
Nisto, it was failing to load tagless PSFs. I just fixed it. I made my own c# xSF loader, to increase the odds that it can be reused for other platforms. So it's a little untested. I've been told there are some mednafen core playback issues with xenogears and chrono cross, in case you test those. I wouldnt be fixing that.
got4n, I don't see why not.
Don't worry. This is no exaggeration: using the normal windows file open dialog is one of the top ten inviolable eternal priorities for bizhawk established on day one. That's how much we hate rom loader dialogs. This will never change. Optional and out of the way is the only way it will ever show up. Avoiding an emulator's rom loader dialogs is commonly seen as one of the main advantages to using that core in bizhawk instead of using the emulator itself.
I'll gladly fix any disc image someone sends me that's throwing exceptions. I'm pretty sure it has nothing to do with validation though. Validation happens long after that exception. More likely your old disc images came from someone who dumped eccentric cues that all fail the same way. Also note theres been no changes to how saturn games are identified, so that couldnt be the cause of those failures.
Nobody who works on bizhawk likes rom list dialogs. We all like to mess with multiple folders to choose roms every time, since it lets us use our "mess with mulitple folders" skills which are very strong on account of having to use them every day to get any work done on a computer. Having things magically all show up in one list is for grandmas who just got their computer yesterday.
I don't even want to think about it. If someone wants to make one, I think they'd be welcome to try.
there's no plans for comprehensively revising any platform's resolution management.
That dialog says what platforms would be sent an iso when you pick it in case no other determination can be made. Other determinations are readily made. No platforms support iso. Some platforms may magically work with an iso, I don't know. Don't use iso, and don't waste your time butting your head against dialogs which look like they help you use iso. That dialog is one of outdated, built for the future, or confused. If you write about every inconsistency in bizhawk, this thread will be 10,000 pages. Please limit yourself to inconsistencies that actually mess you up.
There's no plan for comprehensively revising the tg16 resolution. it may happen randomly one day
iso is a garbage file. we don't want to hear about problems from users with isos, so we dont support iso. run it through discohawk and take your chances.
TG16 isn't setting the "VirtualWidth" property correctly, while NES is. The idea is to distort pixels from being square in a way that matches the hardware. That whole subject is weird. It's best not to worry about it, you're not doing anything wrong.
OK, if you ran kula world from a .cue file, then it's a 100s of MB .??? file renamed to .cue, most likely a .???=.bin. Go find a different rip or quit clicking the .bin on accident.
I just loaded a kula world cue
"Kula World" (not from the .cue file) must be another way of saying "KulaWorld.bin" which will never be supported.
Master branch SHOULD NOT have had that fix, since it won't be fixed.
Master branch SHOULD NOT have had the fix for the second bug you posted just now, because it's different than the other bugs you posted earlier which I said had been fixed.
Spyro 2 bug has now been fixed.
Well, your PSX test didn't make it as far as trying to start up the c++ code, so it wasn't useful data for whether the vc++ prerequisite is installed.
Search for c:\windows\SysWOW64\msvcr100.dll or c:\windows\system32\msvcr100.dll to make sure those dlls are installed. But even if they're installed, they could be broken.
Stop trying to use archive files, that will simplify things.
Forget what you want to focus on, sometimes focusing on other things will collect more data than butting your head into a wall
Try a gameboy game.