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
tepples
Posts: 22708
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

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

Post by tepples »

byuu wrote: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.
Would it be practical to pack the files that make up a gamepak in a zipfile, as I suggested a couple years ago? That's what Java (jar), Winamp (wsz), StepMania (smzip), Office 2007+ (docx), and OpenOffice/LibreOffice (odt) have done. It was also suggested for NES ROMs as part of the ZapFC proposal, with a zipfile containing the PRG ROM, optional CHR ROM, and optional manifest (called the "board" file; if missing, the emulator would consult a database of licensed games or fall back to NROM). The biggest drawback that I remember was difficulty to support on SD and CF adapters such as PowerPak and EverDrive, where a decompressor for DEFLATE isn't very practical to write in 6502 assembly language. But if it is decided that gamepaks shall be unzipped for SD and CF adapters or zipped for anything that uses the Windows file chooser (such as Snes9x), that can still be made to work.

Then the question becomes what middle ground corresponds to Snes9x-Geiger.
007
Posts: 89
Joined: Mon May 02, 2016 5:55 am

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

Post by 007 »

byuu wrote:
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.

When you put the beta out I threw a few titles at it to observe the behavior.

ASP seems to go to pixel based render
Super Off Road is known to need memory randomization and this seems to happen!

Those were my first two checks.

Since then Ive thrown a ton of titles at it and I must say I love the bsnes beta.

One thing I wish you will add to it one day is Blarrg's NTSC under Direct 3d mode.

But anyway I love this new emulator. Mind you I also love higan.
User avatar
olddb
Posts: 188
Joined: Thu Oct 26, 2017 12:29 pm
Contact:

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

Post by olddb »

Sorry to go in a tangent, but I think this is good place to ask.

Is one able to use bsnes for a Steam release, without a license, given than the modify source is distributed with the game?

Keeping in mind that the game ROM or game source wouldn't be distributed alongside.

I have seen conflicting answers about this.
...
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 »

Would it be practical to pack the files that make up a gamepak in a zipfile, as I suggested a couple years ago?
Sure if you wanted to. You already know the downsides of using ZIP to reimplement a folder.

I also thought about making a new storage container that let you omit certain things that complicate ZIP (Zip64, AES, Deflate, filenames [we could use numeric IDs, known ordering, or something like that], timestamps, file permissions, etc.)

But I personally decided that I want to use folders, so that's what I do.

I always thought a virtual-drive type software package that would make ZIPs look like part of the regular filesystem would be cool. Eg c:\foo.zip\file.txt just opens as if foo.zip were a folder instead. But nobody does that and it'd need deep OS integration, probably.
But anyway I love this new emulator.
Happy to hear, thanks!

We'll see how video filters go in time. No promises yet.
Is one able to use bsnes for a Steam release, without a license, given than the modify source is distributed with the game?
I really don't know, but Piko does it anyway. I guess I'm fine with it, if the source and credit is there. There's not really anything any of us can do about it, so ...
User avatar
olddb
Posts: 188
Joined: Thu Oct 26, 2017 12:29 pm
Contact:

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

Post by olddb »

byuu wrote:
I really don't know, but Piko does it anyway. I guess I'm fine with it, if the source and credit is there. There's not really anything any of us can do about it, so ...
Great! Thank you.
...
calima
Posts: 1745
Joined: Tue Oct 06, 2015 10:16 am

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

Post by calima »

IANAL, but I know the GPL fairly well. You can.

But you must take it into account that anyone competent can extract the ROM, since they know how you modified the emulator to hide it. It's not an effective form of DRM.
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 »

Going to guess in Piko's case, he's just leaving the SNES ROM out of the source code release.

Which gets you into questions about whether that needs to be included too (probably), or even open source too (probably not.)
007
Posts: 89
Joined: Mon May 02, 2016 5:55 am

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

Post by 007 »

@hex_user

I noticed on the latest build you changed the description on accuracy but its still misleading.

JUst tested it on a machine with an Ivy Bridge and was able to maintain 60 fps no problem.

I think rather than naming a processor it would make sense saying needs more cpu time.

Also noticed a minor bug.

In D3D mode, in full screen, switching video filters during emulation causes the program to halt 90% of the time. To test just run any game go to full screen and shift through the filters.


Not complaining just reporting back.
User avatar
FitzRoy
Posts: 144
Joined: Wed Oct 22, 2008 9:27 pm
Contact:

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

Post by FitzRoy »

tepples wrote:Would it be practical to pack the files that make up a gamepak in a zipfile
Yes. A double extension (.sfc.zip) archive can be a loadable item. It doesn't need a custom load window, so any emulator could use it. It doesn't need extraction after download to play it. It doesn't need to be written to, nor should it be. It would work exactly like a stand-alone file where ram and states are written outside of it. And if you enforced clean contents by failing to load archives with non-compliant files inside them, the archives you downloaded would always be free of garbage because no one would distribute a non-working archive.
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:In D3D mode, in full screen, switching video filters during emulation causes the program to halt 90% of the time. To test just run any game go to full screen and shift through the filters.
Interesting. If I had to guess, it probably has to do with the fact that some filters have different output sizes than others. And in order for you to switch filters in fullscreen, you wouldn't be using exclusive mode, because the menu bar is unavailable in exclusive mode, and there are no hotkeys for switching filters.

Does the bug also happen if you switch from one filter to another that has the same size?

(Width×2) ⋅ (Height×2)
  • 2xSaI
  • Super 2xSaI
  • Super Eagle
512 ⋅ (Height×2)
  • HQ2x
  • LQ2x
  • Scale2x
(((Width - 1) / 3 + 1) × 7) ⋅ Height
  • NTSC-RF
  • NTSC-Composite
  • NTSC-SVideo
  • NTSC-RGB
768 ⋅ (Height×3)
  • Phosphor3x
512×480
  • Pixellate2x
“Width” is 512 in any profile other than Compatibility: OpenMP, or if Modes 5 and 6 are being used in said profile, and 256 otherwise.
“Height” is 240 in progressive mode and 480 in interlace mode. A hack is used to enforce this convention in every profile, even Accuracy.
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

Correct Happens when not in exclusive mode because its the only way to do it.

Also correct with statement on sizing difference causing the halt.


Dont know if this would really be considered a bug or worth being concerned about just reporting.

If I see something I think a developer would want to know I just post it.

I just figure it could help.
Revenant
Posts: 462
Joined: Sat Apr 25, 2015 1:47 pm
Location: FL

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

Post by Revenant »

byuu wrote:
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.
Seriously, piss off with this passive-agressive nonsense. I've already explained the reasoning for what bsnes-plus currently does, and I don't appreciate being represented as someone actively trying to either promote XML manifests or take some kind of stand against BML manifests or cartridge folders just because my priorities for this time-waster hobby project are currently elsewhere.

I can't speak for AWJ here, but I have absolutely zero interest in "competing" with other bsnes-related projects or participating in whatever imaginary "XML vs. BML" holy war you seem so eager to place the two of us in every time this topic has come up recently. Please stop.
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 »

Not gonna happen. I have worked tirelessly to upgrade the Qt UI from bsnes v073 up through v074, v075, v076, v077, v078, v079, v080, v081, v082, v083, v084, v085, v086, v087, v088, v089, v090, v091, v092, v093, v094, v095, v096, v097, v098, v099, v100, v101, v102, v103, v104, v105, v106, up to the current v106 WIPs leading up to v107, each time adjusting the code to account for breaking changes in Emulator::Interface, all for the sake of allowing the Qt UI to be used with higan v107's emulation bugfixes and gamepak format. I am not going to throw all that hard work out just because my efforts hurt your feelings. v073's XML format was just a prototype, and it cannot properly handle the S-DD1 and SPC7110. It was a miracle that the Tengai Makyou Zero translation team found a loophole in the v073 manifest that would support the 1 MB expansion ROM, and I very much doubt another miracle like that will come again the next time someone creates an unusual memory map. So I'm making bsnes-mcfly so that fans of the Qt GUI won't have to deal with this deprecated format ever again.

I'm pretty sure bsnes-plus enjoys a fair bit more popularity than bsnes v073 and bsnes-classic, and I do intend to start adding debugger functionality to bsnes-mcfly once higan v107 is released. It's really tempting to start earlier, but I'm forcing myself to wait in case bsnes-mcfly somehow gets locked into a v106 WIP just like bsnes-plus has been locked into v073. Which is unlikely (I maintained a laevateinn fork for years), but I'm not taking chances.

If you're worried about backwards compatibility with MSU1 games and hacks that only came in v073 format and no later version, just point me to those games and hacks, and I will personally hand-convert them to v107 and provide download links. Also, I do have Olympian Magic, which can do the conversion automatically (though I'll have to bring it up to the current WIP; I left it dormant for a bit).

Why did you add debugging functionality to the performance profile, anyway? By its very nature, the performance profile was not intended for development of hacks and homebrew, because it takes a lot of shortcuts that break some timing-sensitive games, and it could very easily lift some restriction that the accuracy and compatibility profiles have, something along the lines of writing VRAM during active display (this specific example comes from ZSNES and is not actually a bug in the performance profile). You don't want hacks and/or homebrew to work exclusively with the performance profile, do you?
Revenant wrote:on the off chance that byuu ever decides to support some sort of BML-based manifests for the standalone ROM support in "new bsnes", I'd happily add support for that as soon as possible.
byuu added gamepak support to bsnes v106r40 and BML manifest support to bsnes v106r42. If you want to make good on your promise to add support for BML manifests “as soon as possible”, then you better get cracking!

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

On that note, I just added 7z archive support after I figured out that the LZMA SDK is in the public domain. It uses a later version of the LZMA SDK than the one included in snesreader and includes support for the LZMA2 and PPMd algorithms. With this change, bsnes v073 will have one less advantage over bsnes-mcfly.

While I was at it, I tried adding JMA support as well, but the biggest obstacle is the fact that Nach licensed libjma exclusively under the General Public License version 2. There is no “or any later version” clause in the source files. This is a problem because bsnes-mcfly is licensed under the General Public License version 3, which is not compatible with the previous version without that “or any later version” clause.

To be more specific, most of libjma's source files actually use the LGPLv2.1, which is compatible with the GPLv3, but exactly 5 files use GPLv2 instead: jma.cpp, jma.h, portable.h, jcrc32.cpp, and crc32.h. Rewriting the last 3 is easy (I can shim the CRC32 algorithm with nall's implementation), but the first 2 contain the bulk of the libjma API, and that is a little daunting to rewrite.
bsnes-mcfly: the bsnes v073 and bsnes-classic killer (GitLab repository)
lidnariq
Posts: 11432
Joined: Sun Apr 13, 2008 11:12 am

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

Post by lidnariq »

He did not say "Please stop developing your software".
He said "Please stop being abrasive"
Post Reply