bsnes-mcfly: The v073 and bsnes-classic killer

Discussion of hardware and software development for Super NES and Super Famicom. See the SNESdev wiki for more information.

Moderator: Moderators

Forum rules
  • For making cartridges of your Super NES games, see Reproduction.
Post Reply
hex_usr
Posts: 92
Joined: Sat May 09, 2015 7:21 pm

Re: bsnes-mcfly: The v073 and bsnes-classic killer

Post by hex_usr »

I have since gathered more information about the performance profile Cx4 bug: it also affects higan v098, the last version of higan to have the balanced and performance profiles. And just like with bsnes-mcfly, higan-accuracy and higan-balanced can run Mega Man X2 the first time, and higan-performance requires reloading the game in order to work. So this isn't a bug I introduced.

The bug also affects Mega Man X3, the only other Cx4-based game. And when running my homebrew program that dumps the ST018 and Cx4 firmwares and the DSP# data ROMs, bsnes-mcfly outright crashes while higan simply hangs (only with the performance profile, of course).

The scary part is that it likely will work if I bring back high-level emulation of the Cx4 like what bsnes v073 and bsnes-classic have.

...I really don't want to become the next bsnes-mercury. If I bring back high-level emulation of the DSPs and the Cx4, I'll have to modify it slightly in order to still require the firmware in order to activate. I don't want to encourage people to simply ignore the firmwares as they can with bsnes-mercury.

In fact, I once made an April Fools satire of Lunar Magic that I called Lunar SNES. It restored the HLE of the DSPs and Cx4 and disallowed headerless ROMs (offering to convert your ROMs to headered). I made it stop working after April 1st for exactly this reason.

EDIT: higan v094's performance profile also suffers from the same bug. I think it goes all the way back to bsnes v080, when low-level Hitachi DSP (Cx4) emulation was introduced.

EDIT 2: Yep, bsnes v080's performance profile cannot handle the Cx4 either. But unlike with higan v094 and later, reloading the game wouldn't fix it. There was no way to play Mega Man X2 or Mega Man X3 on bsnes v080's performance profile!

EDIT 3: Exactly as I feared. bsnes v079 and earlier, which have high-level emulation of the Cx4, can run Mega Man X2 and Mega Man X3 in the performance profile. It was the switch to low-level emulation that broke those 2 games in the performance profile. And that means that bsnes-classic has an advantage in this area. Well, at least the Cx4 firmware is legal to redistribute, and the other coprocessors (DSP#, ST010, ST011, and ST018) appear to work just fine with LLE in the performance profile.
bsnes-mcfly: the bsnes v073 and bsnes-classic killer (GitLab repository)
hex_usr
Posts: 92
Joined: Sat May 09, 2015 7:21 pm

Re: bsnes-mcfly: The v073 and bsnes-classic killer

Post by hex_usr »

bsnes-mcfly v106r06 has been released. It is based on bsnes v106r44, but some bugs in icarus have been fixed in order to allow Tengai Makyou Zero's English translation to work (it won't work in bsnes's public beta).

This release also adds high-level emulation of the Cx4 that will only be activated when using the performance profile. This enables Mega Man X2 and Mega Man X3 to work in the performance profile, and they will run faster because they don't have to emulate the HG51BS169 chip. The accuracy and compatibility profiles will use low-level emulation as usual.

Note that this does not give you an excuse to omit the Cx4 data ROM from the firmware/ directory! I tweaked the HLE's checksum routine to actually take a checksum of the data ROM instead of returning a constant. If you remove the Cx4 data ROM, the game will report an “IMMEDIATE ROM ERROR”, but it will probably still work (not tested) after pressing the A button on the error screen.

If, in the future, I add high-level emulation of the DSP# series chips and the ST010, I will do the same thing. I'll even use the SHA256 hash of the supplied firmware in order to select which DSP is active rather than hardcoding it based on the game's internal header. One bsnes-mercury is already too much, I won't make another.
bsnes-mcfly: the bsnes v073 and bsnes-classic killer (GitLab repository)
Near
Founder of higan project
Posts: 1553
Joined: Mon Mar 27, 2006 5:23 pm

Re: bsnes-mcfly: The v073 and bsnes-classic killer

Post by Near »

Tengai Makyou Zero English worked fine when I tested some patch fixes against v106r43 (not in r43, just a branch) ... which changes did I miss that prevent it from running in v106r44?
hex_usr
Posts: 92
Joined: Sat May 09, 2015 7:21 pm

Re: bsnes-mcfly: The v073 and bsnes-classic killer

Post by hex_usr »

icarus does not add "manufacturer: Epson" to the RTC memory node, which higan/bsnes requires in order to load/save the time. Without it, the time always resets to a default value (2000-01-01, if I recall correctly). I think this also affects the Sharp RTC, so Dai Kaijuu Monogatari 2 may suffer from the same bug.

In addition, icarus's checks for the SPC7110 when determining the sizes of the program ROM, data ROM, and expansion ROM don't work if the board name begins with “EXSPC7110” instead of just “SPC7110”. It just assumes a 7 MiB program ROM and 0 MiB data and expansion ROMs.

This happens even if the game is a game pak (cartridge folder); for some reason, icarus overrides the physical sizes of each ROM by concatenating all 3 ROMs together and recalculating their sizes. For example, if you have a 2 MiB program ROM and a 4 MiB data ROM, icarus will forcefully reinterpret a 1 MiB program ROM and a 5 MiB data ROM.
bsnes-mcfly: the bsnes v073 and bsnes-classic killer (GitLab repository)
007
Posts: 89
Joined: Mon May 02, 2016 5:55 am

Re: bsnes-mcfly: The v073 and bsnes-classic killer

Post by 007 »

hex_usr wrote:bsnes-mcfly v106r06 has been released. It is based on bsnes v106r44, but some bugs in icarus have been fixed in order to allow Tengai Makyou Zero's English translation to work (it won't work in bsnes's public beta).

This release also adds high-level emulation of the Cx4 that will only be activated when using the performance profile. This enables Mega Man X2 and Mega Man X3 to work in the performance profile, and they will run faster because they don't have to emulate the HG51BS169 chip. The accuracy and compatibility profiles will use low-level emulation as usual.

Note that this does not give you an excuse to omit the Cx4 data ROM from the firmware/ directory! I tweaked the HLE's checksum routine to actually take a checksum of the data ROM instead of returning a constant. If you remove the Cx4 data ROM, the game will report an “IMMEDIATE ROM ERROR”, but it will probably still work (not tested) after pressing the A button on the error screen.

If, in the future, I add high-level emulation of the DSP# series chips and the ST010, I will do the same thing. I'll even use the SHA256 hash of the supplied firmware in order to select which DSP is active rather than hardcoding it based on the game's internal header. One bsnes-mercury is already too much, I won't make another.

MegaMan x2 x3 now load first try in performance mode! Just a thought maybe change the description on accuracy mode.

I dont have a Liquid Nitrogen cooled super computer and it runs it nicely.

Thanks for another great update.
hex_usr
Posts: 92
Joined: Sat May 09, 2015 7:21 pm

Re: bsnes-mcfly: The v073 and bsnes-classic killer

Post by hex_usr »

In case anyone does not know what 007 is talking about, you can find the following description on the the Settings window's Profiles tab:
byuu wrote:Accuracy
System Requirements: A super-computer cooled by LN2.
Maximum accuracy, no matter the cost.
Use this mode for development or research purposes.
It was byuu who wrote this description for bsnes v073, not me. It is also in bsnes-classic and bsnes-plus. I could change it, but I wonder if fans of the compatibility and performance profiles wouldn't be disappointed to not have their snark bait anymore?

Wait, that's a terrible reason to keep the description. To give users ammo to use when making fun of the accuracy profile's high system requirements?

Okay, I'll change the description for now. Would “Intel Core i7 or AMD FX processor” be a suitable replacement? My Intel Core i7 860 (Lynnfield, I think) can just barely run Super Mario World at 60 FPS.

================================

byuu, you might be interested to know that I found out what was causing the Fast PPU to not honor the Mode 7 horizontal flip flag:

higan/sfc/ppu-fast/mode7.cpp

Code: Select all

auto PPU::Line::renderMode7(PPU::IO::Background& self, uint source) -> void {
  //...

  for(int X : range(256)) {
    int x = !io.mode7.hflip ? X : 255 - X;  //This line is correct. However...
  
    //...

    if(self.aboveEnable && !windowAbove[x]) plotAbove(x, source, mosaicPriority, mosaicColor);  //Lowercase x? This should be uppercase.
    if(self.belowEnable && !windowBelow[x]) plotBelow(x, source, mosaicPriority, mosaicColor);  //Same here.
  }
}
By using the lowercase x on those 2 lines instead of the uppercase X, the PPU effectively performs the horizontal mirroring twice. This is why the SNES Test Program only vertically flips the Super Mario Bros. 3 box art and not also horizontally.

With this bug fix, I think it just might be possible for me to start offering the Fast PPU in bsnes-mcfly.
bsnes-mcfly: the bsnes v073 and bsnes-classic killer (GitLab repository)
007
Posts: 89
Joined: Mon May 02, 2016 5:55 am

Re: bsnes-mcfly: The v073 and bsnes-classic killer

Post by 007 »

hex_usr wrote:In case anyone does not know what 007 is talking about, you can find the following description on the the Settings window's Profiles tab:
byuu wrote:Accuracy
System Requirements: A super-computer cooled by LN2.
Maximum accuracy, no matter the cost.
Use this mode for development or research purposes.
It was byuu who wrote this description for bsnes v073, not me. It is also in bsnes-classic and bsnes-plus. I could change it, but I wonder if fans of the compatibility and performance profiles wouldn't be disappointed to not have their snark bait anymore?

Wait, that's a terrible reason to keep the description. To give users ammo to use when making fun of the accuracy profile's high system requirements?

Okay, I'll change the description for now. Would “Intel Core i7 or AMD FX processor” be a suitable replacement? My Intel Core i7 860 (Lynnfield, I think) can just barely run Super Mario World at 60 FPS.

================================

byuu, you might be interested to know that I found out what was causing the Fast PPU to not honor the Mode 7 horizontal flip flag:

higan/sfc/ppu-fast/mode7.cpp

Code: Select all

auto PPU::Line::renderMode7(PPU::IO::Background& self, uint source) -> void {
  //...

  for(int X : range(256)) {
    int x = !io.mode7.hflip ? X : 255 - X;  //This line is correct. However...
  
    //...

    if(self.aboveEnable && !windowAbove[x]) plotAbove(x, source, mosaicPriority, mosaicColor);  //Lowercase x? This should be uppercase.
    if(self.belowEnable && !windowBelow[x]) plotBelow(x, source, mosaicPriority, mosaicColor);  //Same here.
  }
}
By using the lowercase x on those 2 lines instead of the uppercase X, the PPU effectively performs the horizontal mirroring twice. This is why the SNES Test Program only vertically flips the Super Mario Bros. 3 box art and not also horizontally.

With this bug fix, I think it just might be possible for me to start offering the Fast PPU in bsnes-mcfly.
accuracy core runs all the games at 60 fps even on my i5-4570


If there is a game that doesnt 60 fps for me didnt find it yet.
hex_usr
Posts: 92
Joined: Sat May 09, 2015 7:21 pm

Re: bsnes-mcfly: The v073 and bsnes-classic killer

Post by hex_usr »

007, can you not quote my entire post each time? The second half of my post wasn't meant for you, so there was no need to include it in the [quote] block. And it bloats the page, making for longer scrolling.

As for games that won't run 60 FPS on the i5-4570, try Yoshi's Island. That game's title screen is a frequent benchmark for emulator performance, as it is one of the most Super FX-intensive parts of the game. If even that runs at 60 FPS, try Hayazashi Nidan Morita Shougi 2 instead; it is the one game in the entire library that includes an ARM coprocessor for shougi AI, and you will need the ST018 firmware in order to run it.
bsnes-mcfly: the bsnes v073 and bsnes-classic killer (GitLab repository)
007
Posts: 89
Joined: Mon May 02, 2016 5:55 am

Re: bsnes-mcfly: The v073 and bsnes-classic killer

Post by 007 »

hex_usr wrote:007, can you not quote my entire post each time? The second half of my post wasn't meant for you, so there was no need to include it in the
block. And it bloats the page, making for longer scrolling.

As for games that won't run 60 FPS on the i5-4570, try Yoshi's Island. That game's title screen is a frequent benchmark for emulator performance, as it is one of the most Super FX-intensive parts of the game. If even that runs at 60 FPS, try Hayazashi Nidan Morita Shougi 2 instead; it is the one game in the entire library that includes an ARM coprocessor for shougi AI, and you will need the ST018 firmware in order to run it.
Sorry. Ill trim quotes. Yoshis island on i5-4570 runs 60 fps title screen or gameplay. Hayazashi Nidan Morita Shougi 2 I loaded it let attract mode run 15 min 60 to 61 fps the whole time.

tried both bsnes-mcfly accuracy and higan 106 r44

I think any 3rd gen desktop i5 or later gen cpu can handle accuracy core.

keep in mind a i5-4570 is more powerful than a second gen i7 in many cases.
Near
Founder of higan project
Posts: 1553
Joined: Mon Mar 27, 2006 5:23 pm

Re: bsnes-mcfly: The v073 and bsnes-classic killer

Post by Near »

In addition, icarus's checks for the SPC7110 when determining the sizes of the program ROM, data ROM, and expansion ROM don't work if the board name begins with “EXSPC7110” instead of just “SPC7110”. It just assumes a 7 MiB program ROM and 0 MiB data and expansion ROMs.
Hell. That was the one I forgot from the r33 local fork.

I'll fix both then, thanks!
This happens even if the game is a game pak (cartridge folder); for some reason, icarus overrides the physical sizes of each ROM by concatenating all 3 ROMs together and recalculating their sizes.
I've always maintained it was a massive pain to support game ROMs (files) + game paks (folders) at the same time, and I wasn't being disingenuous.

How do you apply a checksum-verified soft patch or a DRM-disable hack to a folder full of multiple files? They have to be in-memory. The request from the core for the program ROM can't just fopen the file and return the original file contents.

There's ways to support one model or the other that are fairly clean, but both at the same time makes a real mess of everything.
For example, if you have a 2 MiB program ROM and a 4 MiB data ROM, icarus will forcefully reinterpret a 1 MiB program ROM and a 5 MiB data ROM.
No licensed or unlicensed SPC7110 game ever uses a 2MB program ROM, even though the chip itself supports it.

Heuristics are always inherently error prone and imprecise. But people are idiots and want program + data/character ROMs merged, iNES + copier headers merged, BUT NOT FIRMWARE HOLY FUCK DON'T MERGE FIRMWARE ARE YOU INSANE?!

So this is the fallout: if you want the flexibility to make whatever game you want, use higan and game paks. If you just wanna play your licensed games and the most popular hacks, use Snes9X or bsnes.
By using the lowercase x on those 2 lines instead of the uppercase X, the PPU effectively performs the horizontal mirroring twice.
Thanks!
Sorry. Ill trim quotes. Yoshis island on i5-4570 runs 60 fps title screen or gameplay. Hayazashi Nidan Morita Shougi 2 I loaded it let attract mode run 15 min 60 to 61 fps the whole time.
12 year old budget processors run bsnes with the scanline-based PPU at fullspeed. Refurbs you could buy for $50 eight years ago could do so.

The objection desktop people have to the speed of bsnes/higan isn't maintaining 60fps, it's that you can't fast forward at 1200fps like you can in Snes9X. The 300fps you can get with bsnes now isn't fast enough for some people.

Further, although it's getting closer, bsnes is still unusable even at 60fps on $1 ARM CPUs like on the Pi Zero / 3. That's a really huge (and growing) market.

I'm not saying either of these use cases are bad: Snes9X is a great choice for those. The world doesn't need *another* Snes9X ... the one we have is perfectly fine. Well, save for the folks who want to use it commercially.
hex_usr
Posts: 92
Joined: Sat May 09, 2015 7:21 pm

Re: bsnes-mcfly: The v073 and bsnes-classic killer

Post by hex_usr »

I have a major dilemma now.

byuu is making a closed-source, commercially-licensable SNES emulator with speed and accuracy similar to Snes9x (full details on byuu's message board). By using state machines instead of cooperative threading, it will primarily target low-powered ARM CPUs such as the Raspberry Pi. Its commercial availability means that Snes9x will be less at risk of having its license violated by inconsiderate corporations.

To avoid competing with this new performance-focused emulator, I am considering removing the performance profile from bsnes-mcfly. But I have major doubts about whether I should go through with it or not.

At this time, Snes9x has accuracy at least as good, if not slightly better than bsnes-mcfly's performance profile, but it accomplishes this with tremendous speed that bsnes-mcfly can't reach because of its dependence on libco, the cooperative multithreading library. However, Snes9x has absolutely no support for cartridge folders or manifests whatsoever, so users who want to play MSU1 games with a sane file structure where only the containing folder has the game's name... can't use Snes9x unless they rename the ROM, the data track, and every audio track to all have the same name and different extensions. Without manifest support, every time someone makes a new memory map not yet supported in Snes9x, Snes9x needs to be manually changed in order to support it, like what was done with Tengai Makyou Zero's English translation.

On the other hand, If I do remove the performance profile, I just know that AWJ and Revenant will take full advantage of it to promote the continued existence of XML manifests. The elimination of XML manifests and the promotion of higan v107's BML-based manifests are bsnes-mcfly's single greatest mission, and any removal of a feature from bsnes-mcfly that is in bsnes-classic would be a violation of that mission.

I am only concerned with convincing users of bsnes v073, bsnes-classic, and eventually bsnes-plus to use bsnes-mcfly. I am not worried about trying to take users away from the official bsnes or byuu's upcoming commercial emulator. In fact, I would prefer that users satisfied with bsnes's feature set (when v107 is released) use bsnes instead for its stable, relatively bug-free GUI. Qt is horrible with bugs, and the only reason I chose Qt instead of the far superior hiro is to cater to users who mentally associate Qt with convenience and hiro with strict, uncompromising standards compliance. Sounds silly, right? But I can't take that risk.

Reasons why bsnes-mcfly should keep the performance profile:
  • Prevents bsnes-classic, and XML manifests with it, from having an advantage over bsnes-mcfly
  • Allows the use of gamepaks (cartridge folders) on lower-tier hardware, which Snes9x can't do
  • Performance profile can't actually compete in speed with Snes9x and the new emulator, no need to worry about competition on low-end ARMs
Reasons why bsnes-mcfly should remove the performance profile:
  • One less competitor for byuu's upcoming commercial alternative to Snes9x
  • Less work when porting newer higan/bsnes versions
Does anyone have any thoughts to contribute?
bsnes-mcfly: the bsnes v073 and bsnes-classic killer (GitLab repository)
Near
Founder of higan project
Posts: 1553
Joined: Mon Mar 27, 2006 5:23 pm

Re: bsnes-mcfly: The v073 and bsnes-classic killer

Post by Near »

However, Snes9x has absolutely no support for cartridge folders or manifests whatsoever
I imagine it'd be possible to add gamepak loading to Snes9X, but not manifests. The hardest part would be how to load them. The native Windows OS dialog for folder selection is trash.
Without manifest support, every time someone makes a new memory map not yet supported in Snes9x, Snes9x needs to be manually changed in order to support it, like what was done with Tengai Makyou Zero's English translation.
It's the only case I know of that anyone would ever care about, and I had to hack around it too because I kept changing the format. That is just an exceptionally extreme edge case (which couldn't be helped), not only expanding the data ROM to an unusual size, but requiring a third ROM that bypasses the SPC7110 mapper altogether. It's just always going to be extremely awkward to support that game.
I just know that AWJ and Revenant will take full advantage of it to promote the continued existence of XML manifests.
I really don't think either of them care about this.
Does anyone have any thoughts to contribute?
Do whatever you want. Keep the profile or don't, I don't mind either way.
007
Posts: 89
Joined: Mon May 02, 2016 5:55 am

Re: bsnes-mcfly: The v073 and bsnes-classic killer

Post by 007 »

hex_usr wrote:
Reasons why bsnes-mcfly should keep the performance profile:
  • Prevents bsnes-classic, and XML manifests with it, from having an advantage over bsnes-mcfly
  • Allows the use of gamepaks (cartridge folders) on lower-tier hardware, which Snes9x can't do
  • Performance profile can't actually compete in speed with Snes9x and the new emulator, no need to worry about competition on low-end ARMs
Reasons why bsnes-mcfly should remove the performance profile:
  • One less competitor for byuu's upcoming commercial alternative to Snes9x
  • Less work when porting newer higan/bsnes versions
Does anyone have any thoughts to contribute?

bsnes-classic and bsnes-plus are usually offered in accuracy and compatibly mode they already dont offer performance so that is irrelevant.


As for competing with the new bsnes. You cant with you current setup. From the betas I think the new bsnes is already slightly faster and also smart in a way of switching the a more accurate core when required.

I would keep all 3 profiles in mcfly if Byuu doesnt mind them there.

and While snes9x is faster than performance profile it is not more compatible. There are alot of games the bsnes performance emulates that snes9x can not. one example Phalanx locks up in snes 9x but even in dare I say it zsnes it runs.


I just hope that the new bsnes from byuu will still exist for windows when he goes commercial. it looks very promising.

My current snes go to emulators are mcfly and byuus beta. Running mcfly on my gaming desktop and byuus beta on my media center.
hex_usr
Posts: 92
Joined: Sat May 09, 2015 7:21 pm

Re: bsnes-mcfly: The v073 and bsnes-classic killer

Post by hex_usr »

007 wrote:bsnes-classic and bsnes-plus are usually offered in accuracy and compatibly mode they already dont offer performance so that is irrelevant.
Sorry, but that's wrong. bsnes-classic still has the performance profile, and so too does bsnes-plus. You're probably referring to the fact that bsnes-plus does not provide precompiled builds of the performance profile (bsnes-classic does not provide any precompiled builds at all, and no, EmuCR doesn't count). However, it is still possible to compile the performance profile from source, so you can't say that they don't offer it.
007 wrote:As for competing with the new bsnes.
Uh, what I meant to say is that I'm not actively trying to compete with the official bsnes v107. If bsnes v107's feature set is enough for you, then by all means use it. Its use of hiro instead of Qt means fewer GUI bugs, so I encourage it.

But if anyone latches on to bsnes v073 or bsnes-classic because of a feature they support that isn't in bsnes v107 (movie recording and playback, PNG-compressed screenshots, etc.), then that's what bsnes-mcfly is for.

As for bsnes v107 being faster than bsnes-mcfly, I can chalk that up to bsnes using the new parallel PPU that uses OpenMP, whereas bsnes-mcfly still has the older compatibility profile which doesn't support OpenMP. I always planned on having the parallel PPU replace the old compatibility profile.

In fact, I have a new release for you: bsnes-mcfly v106r07. This one is based on higan/bsnes v106r45. This time, I included 4 profiles:
  • Accuracy
  • Compatibility: OpenMP
  • Compatibility: Legacy
  • Performance
Compatibility: OpenMP is simply bsnes's new parallel PPU with OpenMP, so it should be faster than the older Compatibility: Legacy profile with the same compatibility. It also supports natively drawing 256-pixel width in Modes 0, 1, 2, 3, 4, and 7, whereas the other 3 profiles all forcefully use 512-pixel width regardless of the video mode. This should help with the OpenGL shaders. In addition, the Hires Mode 7 option only works with the Compatibility: OpenMP profile. However, it does not yet support 128 KiB VRAM (only the Accuracy and Compatibility: Legacy profiles support that, although the Performance profile has a C++ preprocessor define to enable it).

Swapping between the Accuracy and Compatibility: OpenMP profiles without a full restart is possible, but I had to fix another bug in bsnes to get it to work: while bsnes does allow hotswapping between these profiles, it suffers from a bug in the code that determines how big a save state should be. bsnes registers the active profile in SuperFamicom::system.power(), but in SuperFamicom::system.load(), it runs serializeInit(), which expects the profile to have already being registered beforehand. As a result, the save state's expected size “lags” behind by 1 game load, so when switching from the fast profile to the accuracy profile, bsnes calculates the expected save state size under the assumption that the fast profile will be used. Then when trying to save a state, bsnes allocates the wrong size and crashes. I believe the fast profile's save states are smaller than those of the accuracy profile, so the accuracy profile's save states overflow out of the allocated memory.

The Performance profile now has high-level emulation of the DSP1, DSP1B, DSP2, DSP3, DSP4, and ST010. I had previously created these for Lunar SNES, an April Fools satire of Lunar Magic, but this time around, I made it select which HLE implementation to use based on the CRC32 of the firmware's program ROM, and I took out the hardcoded data ROMs from the DSP1/DSP1B and DSP3 (the DSP2 and DSP4 never had any to begin with). This means that users cannot get away with leaving out the firmwares by switching to the performance profile. The firmware is still required, even if you use HLE.

If all goes well, then this should hopefully be the last release with the Compatibility: Legacy profile.
bsnes-mcfly: the bsnes v073 and bsnes-classic killer (GitLab repository)
Near
Founder of higan project
Posts: 1553
Joined: Mon Mar 27, 2006 5:23 pm

Re: bsnes-mcfly: The v073 and bsnes-classic killer

Post by Near »

I just hope that the new bsnes from byuu will still exist for windows when he goes commercial. it looks very promising.
Yes, absolutely. bsnes is higan, just with a scanline-based renderer for games that don't need pixel-based rendering, and a fallback for the one game that does. It's meant to be the middle ground between Snes9x and higan.
Post Reply