And yeah, after a while, they all add up. So there are many instances I give up those 2% - 3% speedups. So anything I can do to simplify it, is worth doing. And I'm not smart enough to handle what I've already created. adding to the complexity of the program as a whole. So I just see these kinds of performance speedups as. So I started rendering empty tiles and the game predictably did not look right at all. One game, Super Buster Bros, detected a reset and would not reload the VRAM. Then I had this bug where a soft reset would flush the tile cache but not the VRAM.
#BSNES VS BSNES MERCURY CODE#
The result was about 40 lines of code and a 2% speedup.
And in this way, grabbing pixels to blit out was a lot simpler.
It was updated on VRAM writes automatically for 2bpp, 4bpp, 8bpp modes. I used to have a tile cache that decided bitplane to bitmap. Yeah, so this is a lot of the contention between our philosophies. If you don't bother with pointers, you won't need much extra code, either I'd estimate about 30 lines for a 2-3% speed boost (Mercury gets about 5%, but its direct pointers take more than 30 lines). I don't believe that most of the people even bringing up that point actually care that much about multi-patching - it's a red herring.Įven without my use-pointer-directly optimization, reducing cache pressure would help a bit.
And that's likely why many keep acting like BPS can't multi-patch, even though it can. I think they were trying to justify reasons to stick with IPS instead of using something newer and better. You really should be using some other kind of system, like a GUI version that loads assembler patches that can relocate code so all the patches apply safely. it's an -error- if two files change the same byte of the source file. But if I *had* to support it, the ideal way would be, you pick the *original* ROM, then you pick all the patches you want at the same time, which all have the original-file checksum as it should be, and then when the patcher applies them all. Both IPS and BPS have the identical problem that the byte will be the result of the second patch.īoth are a big problem. UPS had the problem that if two patches changed the same byte, the end result would be invalid no matter what. Personally, I don't like multi-patching at all. You *can* optionally create one, and then give all your songs whatever filenames you like, eg "02 - Boss Battle.pcm" however that is optional, and will break compatibility with everything else, so it's not really recommended.Īnd I believe said some are cave dwellers from the era when our feature patches used IPS. So you can produce an MSU1 package that will run in all emulators and on real hardware by going with the latter.Īlso, note how there's no longer any XML or BML manifests required.
#BSNES VS BSNES MERCURY PATCH#
(* sd2snes game folder support was a patch by qwertymodo unclear if ikari will accept it.)įor game files (higan, Snes9X, sd2snes), it's: We do have an official, set-in-stone standard at this point:įor game folders (higan, sd2snes*), it's: I can't do anything about people clinging to six-year old emulator builds The problem is that a lot of people decided to stick with bsnes v073 (or forks of it), which was released in 2011 or so.
#BSNES VS BSNES MERCURY HOW TO#
It took a while to perfect how to implement game folders, so unfortunately there was a lot of variance right at the beginning (specifically in the fine tuning of the manifest syntax.)
My only real concern about this is that there seem to be an ungodly ammount of ways MSU-1 can implemented in a hack
0 kommentar(er)
