Play movie works fine for me on windows 10. Why dont you let the experts decide what the problem is by giving them the evidence.
Regarding Monster Rancher 2, I've done further research and it was the EXE that was patched. I had a tentative plan to incorporate the contents of the EXE into the disc ID and if I'd done it, it would have caught this. But I was waiting for evidence. I'm gonna wait a while more and see how pervasive this kind of thing is.
that's not the treeview, thats the listview, but it showed me what i needed, as long as it was scrolled up all the way.
bleh
delete msvcr100.dll from your syswow64 and system32 directory and then run the prerequisite installer again.
I just checked a handful of games and found about 5 left-of-screen offsets. I'm not going to add a new cropping method that works for 1/5 of games and I'm not going to add a configurable xstart/xend like there is for the scanlines when I've already made another method and adding a straight-up framebuffer grabber would be about as much work as xstart/xend (even though the framebuffer grabber couldnt get interlaced pictures)
you can't enter gameshark codes in bizhawk.
you can convert some gameshark codes to raw cheats
this code is two parts.
if($B6F18==$0600) //D00B6F18 0600
$B6F18 = $0100; //800B6F18 0100
This can't be converted to raw cheats.
You might be able to approximate it by removing the first part. But it might not work. You might be able to approximate it by manually tweaking that value at the right time in the hex editor, if we had a systembus memorydomain on psx, which it seems we do not. You could probably convert that address to a main ram address using google-fu and a PSX memory map and then use the hex editor.
1.11.1 with PSX, can't open rom Street Fighter EX2 Plus [SLUS-01105]
Your cue is nonsense. Open it in notepad and look. It references a nonexistent .bin file. I'll be fixing this to give a better error message, anyway
xxNKxx wrote:
And with Monster Rancher 2 [U] [SLUS-00917], it alway black screen
Your dump is bad. I have it too. It appears to have been patched, from what I can see, but that's just a guess.
As always, when a disc-based game doesnt work, find another dump. I apologize that Monster Rancher 2 showed up with a green checkmark suggesting it's a good dump... but you can check this in the future yourself by reading the checkmark's status report and then hashing your disc with the PSX menu.
Lil_Gecko wrote:
In Final Fantasy IX, recording a movie from Power-On works fine, but recording from Now, sometimes works fine, sometimes Softlock on the screen transition, sometimes Softlock right away.
That means the savestate contained in the movie file should be broken. If you load it outside the context of a movie (you can unzip the movie file and get the savestate out of it) it should do the same thing the movie does.
No, No, and No. Throw me some more softballs. I guess I should be kind and elaborate
1. No; Portability comes at the expense of quality
2. No; we don't care about hypothetical patent issues. We chose c# because we like it, and because we don't like C, C++, or Java for doing user interface and architectural work (or anything at all, in Java's case), and because in principle a lot of it could be machine translated to another language although the project has grown so much, it would be impractical for a lot of it...
3. No; our goal is to rewrite as much free code as we can, and make as much non-free code appear in a useful frontend environment as we can. Deleting the non-free gains nothing for anyone although of course if someone delivered us a suitable free replacement for any non-free code we'd be all over that shit. We _have_ gone to great lengths to write free replacements in a few instances including the entire c# genesis core which isnt just quite there yet. I'd have to check for some of the other c# cores we've written, which ones supplanted badly-licensed alternative emulators. Note that with our definitions, GPL is non-free and badly-licensed. Badly licensed is just one of many defects, too. The other is generally an unbearable user interface which is inextricable from the core emulation code...
You didnt need to clarify. It's in agreement with what I said. It's highly unlikely to be wrong in all 3 of those emulators. It must be right. The same game engine will be used to display the credits with BG art, so it would be broken for both sets of BG art if it was broken at all. But it isn't broken, the programmers just left out the text for the 2nd set of BG art.
no. That's dozens of hours of work at a minimum, nobody cares that much. Most emulators skip the bios by means of HLEing the entire bios, which is dozens or hundreds of hours of work. Another proposal has been to patch the bios to skip the graphics. That's dozens of hours of work except maybe for a fully ramped up PSX software hacker.
creaothceann, you can learn c#, it's easy! We'll help you.
1st and 2nd sets of credits are different engines, different programmers, and with different rules governing the background art. I dont see why one has to do with the other. However, it's just plain odd to get the 2nd credits the 1st time you beat it, and not the 2nd. Maybe nobody tested that and the script for BG art + Credits are combined, and when the 2nd art was put in, the credits were left out. Or maybe its just odd.
If you got the credits text the 1st time, then I say this is case closed until someone tests it on hardware. Thanks for your tenacity in studying this though.
Yes, you're wrong. The dithering is probably correct. Mednafen is more accurate in this respect. Mednafen is more accurate in essentially every respect in regards to the rendering. I think what's happening is the game is rendering 24bpp colors, not 16bpp. But the PSX framebuffer is generally 15bpp. So Rendering 24 on 15, you can either dither it or not. I think the PSX always dithers it. It looks cool on a CRT. It sounds like the PSXJin option should actually be called "Aways dither g-shaded polygons, like they're supposed to be". Defining "correct" in comparison to the 16bit versions doesn't seem like a good plan.
jlun2, no. It isn't safe. Games may always write data to save memory using it as a cache. On various platforms this ranges from common to forbidden or impractical, but it's generally an unwarranted assumption that it's safe to rip the save data out of a savestate.
On NES it's common, and that's probably why that convention evolved the way it did. It's only been done differently on platforms with slow, removable save memory, because those emulators were used for one platform only and they were willing to accept the risks.
A more generalized view of savestates is that an entire workbench full of equipment is savestated, everything sitting on it, and that includes memory cards. If you ever want to move the savedata off of the workbench then you click it and pick export or import.
hegyak, presently, you have to have the other user's controller configuration matched perfectly to load a savestate. Use 1P only, gamepad, for these savestates.
Reproduced bug on my iso
OpenGL was a huge mistake. With as early as Windows 7 even gpu vendors have also dropped a lot of support for OpenGL. We made OpenGL because we needed to consume some OpenGL-based emulator cores (N64 and saturn) asap and it was time to rewrite all the related code and it wasn't clear how well OpenGL and direct3d could play together. Supporting direct3d in addition to OpenGL is now a top priority.
We won't be adding more video filters. Instead, the process for using custom filters pasted from retroarch will be improved.
It wont be added to the next release, I already did it in another way that more aggressively crops more overscan in more cases and sizes the GUI down along with it. If you're going to be writing a million bugs, you need to learn to make builds from source yourself for testing.
just committed a fix. It took a bit of wrangling to get a solution I liked, since only adding the new number for duplicate seconds results in windows sorting them weirdly with the original screenshot below the other later ones, so I changed it to rename the original one at the moment there's a conflict.
Since it seems like you're going to make ten million suggestions, why dont you put them all in one thread for discussion. We can triage them to the bug tracker as needed.
1. was a quick fix. I just committed it.
2. This would require some internal discussion and may not happen anytime soon. I'm sympathetic to the request, but it seems as if a lot of stuff in bizhawk was designed to limit it to one cheat per address.
there arent layers on the psx.
screenshots of an interlaced screen would not be artificially scaled to full resolution. I'm not sure you know what you're talking about at all. In an interlaced screen, the framebuffer contains only half the visible graphics. The next instant, it will contain the other half of the visible graphics. Whatever you mumble about unfaithful screenshots of a mode is illogical, unless you understand that without using mednafen's interlacing you'll need to apply your own interlacing from two framebuffer captures.
This problem is easy to reproduce with the following steps
1. use tastudio
tastudio isn't finished yet. It lacks a finished critical component, the management of memory. It just chews up memory until it runs out and then falls to catastrophically slow O(N) or O(N^2) or worse algorithms to scavenge memory.
It doesnt leak memory, it just uses a lot of memory, and when it's used as much as it thinks it should, it begins the amazingly slow scavenging process.
This logic was at one point (is it still?) marked as "TODO: someone needs to actually do a good job at this"
If there is or someone adds a manual greenzone clearing mechanism (clear all greenzone earlier than frame 4000, for example) then you could work around this.
Also by default the greenzone states go to disk at some point. This doesn't seem to be what's slow.