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.
Exequiel
Posts: 4
Joined: Mon Jul 23, 2018 5:46 pm

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

Post by Exequiel »

This message is directed to the author of this build:

I want to incorporate your build into my front-end emulator launcher (launchbox) because I love it..! That said, I'm having a issue with getting it to launch games in Fullscreen automatically. The issue is that when an emulator doesn't have the option to do it automatically, we use AHK scripts (auto hotkey scripts) to manully fire hotkeys after a certain delay (i.e. wait 5 secs, send {alt+enter} which would trigger fullscreen) but nothing happens using your build. These techniques work on various higans and old bsnes to bypass the issue but on this build it's just not working. I was hoping your could either add an option within the emulator to launch games in fullscreen or enable what the moderators from launchbox have mentioned below:

"Well to be perfectly honest this isn't a "Launchbox problem" it's just something that the emulator doesn't allow for, the vast majority of emulators out there either have a command line option or a toggle to set to load in fullscreen. Even Byuus original BSnes and Higan emulators allow for this for most builds and those that don't will allow an AHK script to toggle it "F11".”

This issue may seem trivial, but I use a regular remote control to launch games and use original snes gamepads... so I have no access to a keyboard once it’s set up...

Hoping this reaches you,
regards

LINK FIXED:
ref: https://forums.launchbox-app.com/topic/ ... ullscreen/
Last edited by Exequiel on Mon Jul 23, 2018 6:19 pm, edited 1 time in total.
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 »

Hmmm, I can believe that the command line option won't work, but I just spent the last few days trying and failing to add resolution changing, so I'm pretty sure that the hotkey for fullscreen works at least. Did you configure the hotkey in the Settings window's Input tab? Unlike the official bsnes, bsnes-mcfly will allow combination hotkeys such as Alt+Enter.

I'll look into this pretty soon.

EDIT: By the way, the URL you linked is broken.
bsnes-mcfly: the bsnes v073 and bsnes-classic killer (GitLab repository)
Exequiel
Posts: 4
Joined: Mon Jul 23, 2018 5:46 pm

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

Post by Exequiel »

I fixed the ref link, my bad

Your hotkeys work when I’m using my actual keyboard but when I use an automated script (which basically send key inputs) then it doesn’t work.. is there something else you want me to try??
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 »

The automated keyboard script won't work? Interesting. Do you know if it works with the bsnes v106r44 beta? And if it does, I think I might have an idea of what's going wrong with bsnes-mcfly... though the question then becomes “why does it work with bsnes v073 and not bsnes-mcfly?”:

The Windows version of bsnes v073 used to come as 3 DLLs and a launcher EXE, where the 3 DLLs correspond to the 3 emulation profiles: bsnes-accuracy.dll, bsnes-compatibility.dll, and bsnes-performance.dll. The DLLs aren't actually dynamic linked libraries; they're really EXE programs disguised as DLLs, and the launcher program is responsible for executing the selected DLL as an EXE. In order to look as much like bsnes v073 as possible, bsnes-mcfly follows the same setup.

If you want to, you could rename one of the DLLs to have the “.exe” extension and run it directly. Though if you do, the Settings window's Profiles tab will stop having any effect (with one exception*). This is just a guess, but maybe your keyboard script doesn't take into account launcher programs that invoke other programs, and renaming one of the DLLs to have the “.exe” extension will fix it? If not, then I'm all out of ideas.

*bsnes-accuracy.dll actually contains both the Accuracy and Compatibility: OpenMP profiles (bsnes-compatibility.dll contains only the Compatibility: Legacy profile, which is deprecated), and it is possible to switch between them without a full restart; just loading a new game is all that is needed for the profile change to take effect. Switching to or from any other profile really will require a full restart.
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 »

Just a fair warning hex, you're probably going to hate the next WIP ...

I've cleaned up the Emulator::Interface a good deal.

Gone are the persistent structs, in their place:

Code: Select all

auto information() -> Information;
auto videoInformation() -> VideoInformation;
auto ports() -> vector<Port>;
auto devices(uint portID) -> vector<Device>;
auto inputs(uint deviceID) -> vector<Input>;
auto connected(uint portID) -> deviceID;
auto connect(uint portID, uint deviceID) -> void;
The overscan boolean was moved to VideoInformation.

Port no longer includes vector<Device>, and Device no longer includes vector<Input>. The Input::type is more specific as well now.

connected(port) solves two problems at once:
1) for new configuration files, this can be called before calling connect() to get the default, sensible device for said port. This avoids the "controller ports default to none" problem higan has had for a long time now.
2) for handling devices such as the NES FourScore, this works in place of needing the core to call into Emulator::Platform.

For the latter, here's what I propose: put "Four Score" into both controller ports in the menu and devices() results. Whenever the user picks any item from the menu, call connect(port, device) and then immediately call connected(port) for all ports(). When the NES core sees a connect([Controller1 *OR* Controller2], FourScore), it will actually connect both controller ports to the FourScore device ID. Then when the UI polls connected(), it sees this and both options end up selected in the menu. When the user then picks something OTHER than FourScore on EITHER port, the core will then set the other controller port to Device::None, and the UI will see this via calls to connected().

As for what to do with the input settings window, I don't know ... probably put all the inputs under Controller1::FourScore, and return no inputs for Controller2::FourScore. Maybe call devices(Controller2)::FourScore "Four Score (virtual)" or something? Could also make a dummy single digital input under Controller2::FourScore named "Use Controller Port 1 :: Four Score", but... yuck.

Also, vector<Media> is gone. Now that there's separate Interface classes per core, it serves no purpose. You can get the preferred filetype extension for a system via information().extension now.
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 already migrated bsnes-mcfly to v106r51. It's worth noting that bsnes v073 supported the asciiPad, a turbo controller with switches with “Off”, “Turbo”, and “Auto” settings. Support for this device was never internal to the Super Famicom core itself, only in the Qt GUI. Even in bsnes-mcfly, the ports and devices vectors were largely unused because the asciiPad's existence means that I can't use those vectors directly. What I'm saying is, v106r52's planned changes to Emulator::Interface probably won't be as much of an impact as you think.

And besides, I'm not afraid of breaking changes. Remember v106r47's wide-reaching changes to nall (loss of the rrange() function, et al.)? I incorporated that change into bsnes-mcfly. It helps that I use a directory structure where the “higan/” directory is completely unchanged from higan. I have a separate “bsnes/” directory (soon to be renamed “bsnes-mcfly/”) where I put all my evil hacks (such as frameskip for the fast PPU and simultaneous up+down and left+right).

I'm glad you came up with a way to support the Four Score (and the Mega Drive's EA 4 Way Play). nSide's future is looking pretty bleak right now (the main reason I still haven't put it up on GitLab yet is that it still has an older manifest format, but more details in a PM), so I can rest easy about discontinuing the Famicom part at least.
bsnes-mcfly: the bsnes v073 and bsnes-classic killer (GitLab repository)
Exequiel
Posts: 4
Joined: Mon Jul 23, 2018 5:46 pm

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

Post by Exequiel »

Hey,
I confirm launching to fullscreen works with bsnes_v106r44-windows.
I tried renaming from .dll to .exe and launching one of them but it still doesn't work :/
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 »

Well, that's very interesting. I wonder if Qt is somehow interfering with the keyboard script? I can't think of any reason why it wouldn't work; hotkeys work by polling ruby's Input driver, which is also included in the official bsnes, and if the script works on the official bsnes, then I'm truly stumped on finding the cause.

Here's bsnes-mcfly v106r10 (based on higan/bsnes v106r51). This version restores the missing --fullscreen command line switch. To run a game in fullscreen, simply run the following command, substituting the game's path:

Code: Select all

bsnes-mcfly.exe --fullscreen "path/to/game.sfc"
As a side effect of the change I made, it should now be possible to chain a base cartridge with a slot cartridge and load them both together. I remember that being a complaint someone had with bsnes v073. For example:

Code: Select all

bsnes-mcfly.exe --fullscreen "path/to/Same Game.sfc" "path/to/Same Game Character Data Shuu.bs"
This will work with BS Memory cartridges, Sufami Turbo cartridges, and Super Game Boy cartridges.

EDIT: Oh, and by the way, Alt+F4 will now work in fullscreen. It previously wouldn't work before, probably because it's Qt that listens for the hotkey, and Qt considers itself unfocused when in fullscreen mode, so I had to write code to explicitly watch for Alt+F4 and close the program. And if you want a different binding for exiting the program, you can now assign one on the Input tab (it works in addition to, not instead of, Alt+F4).

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

Speaking of the Super Game Boy, there has been something on my mind for the past few months.

A few bsnes v073 users are no doubt aware that bsnes v073 uses gambatte for Super Game Boy emulation, whereas bsnes v074 and later use byuu's own Game Boy emulator, which was once known as “bgameboy”, and then “bgb” (all lowercase to distinguish from beware's BGB). gambatte has... I don't want to say “accuracy”, but it has great compatibility with the Game Boy library, and great performance overall. Whereas bgameboy/bgb has a history of incorporating new findings that later turned out to be incorrect, so its accuracy and compatibility are less than excellent. And like all of byuu's emulators other than the upcoming csnes, the “code as documentation” philosophy means that bgameboy/bgb is somewhat slow. Compound that with the SNES accuracy profile's demands, and I'm sure it doesn't take a genius to figure out the implications.

If I switch bsnes-mcfly to gambatte, then byuu's own Game Boy emulator will not get tested as much and will receive fewer bug fixes. But if I don't, there could easily be users who continue using bsnes v073 or bsnes-classic in spite of everything I have done for bsnes-mcfly.

Decisions, decisions...
Last edited by hex_usr on Tue Jul 24, 2018 5:09 pm, edited 1 time in total.
bsnes-mcfly: the bsnes v073 and bsnes-classic killer (GitLab repository)
Exequiel
Posts: 4
Joined: Mon Jul 23, 2018 5:46 pm

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

Post by Exequiel »

I confirm it works using the bsnes-mcfly.exe --fullscreen command line.
I will update the launchbox forum thread to let them know as well...
Thanks for looking into this :)
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 r8 works fie for me on windows 7 & 10

r9 and r10 crash on exit. tested on 3 systems all windows 7.

not complaining just reporting.
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 did notice something similar, but the symptom was different. Instead of outright crashing, bsnes-mcfly would instead hang in memory. It would look like it closed properly, only to show that it was still running whenever I try to overwrite the current build with a new build.

v106r09 corresponds to higan/bsnes v106r49, while the previous version corresponds to higanbsnes v106r46. Between those, v106r47 was the start of a near-complete overhaul of nall. It's possible that something in there made it much harder for bsnes-mcfly to close itself properly, but this is unproven.

bsnes v106r47 Windows build

bsnes v106r52 Windows build

List of Windows builds for higan/bsnes WIPs. Don't be fooled by the FAILED status indicators; on GitLab, FAILED is shown whenever at least 1 target build fails, which in this case would be the libretro port. The standalone higan and bsnes targets build just fine, and they are available for download.

I will say though, I don't think I've noticed this hanging/crashing after I upgraded to the 20180724 intermediate WIP preceding v106r52.

Oh, and fair warning: I have now completely dropped the Compatibility: Legacy profile from the source code. From now on, the Compatibility: OpenMP profile will simply be known as “Compatibility”. If you need the deprecated profile, bsnes-mcfly v106r09 will have it, but if you find a game that works with Compatibility: Legacy and not also Compatibility: OpenMP, please post about it either here or on byuu's message board.
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

It seems older setting cause this. I went into user folder deleted old files and crash gone. Thought of doing this when I tried it on a system that never ran mcfly before and there was no crash.

so there is no bug, just if settings files from old install exist it effected somehow, i deleted all higan and bsnes folders and on all systems all is good now.
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 »

Still, if there is a crashing bug, I would like to know how to reproduce it so that I can fix it.

Because yesterday, I went on a coding spree and converted almost all of the Qt 4 signals/slots in the code to lambdas, which are supported by Qt 5. Exactly 1 file in the source code still requires moc to compile, and it relates to the file browser. All because I'm trying to find out why the crash happens and needed a bit more freedom than moc allows.

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

Regarding gambatte, I won't be able to incorporate it into bsnes-mcfly. Not legally, at least. gambatte is licensed under the General Public License version 2, and it does not contain an “or any later version” clause. bsnes-mcfly, being based on the higan/bsnes v106 WIPs, uses the General Public License version 3, and these licenses are not compatible without that “or any later version” clause. It's the same situation with libjma, the JMA archive extraction library.

I said previously that I will “take any legal means necessary” to replace bsnes v073 and bsnes-classic. Incorporating gambatte is not a legal means, and if I was talented enough to write a whole Game Boy emulator from scratch, I would just help byuu with his Game Boy emulator instead.
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 »

I decided that I would study up on GDB, and debug bsnes-mcfly's exit routine. And I think I have a lead on the crashing bug.

RawInputWindowProc(HWND__*, unsigned int, unsigned long long, unsigned long long)

There seems to be a segmentation fault in ruby's Windows input driver. And indeed, if I change the input driver to None, then bsnes-mcfly stops crashing. But now I obviously can't play any games, so I need to figure out why ruby is crashing on exit.

The bsnes WIPs don't crash on exit, do they? Make sure you have the Windows input driver selected if you want to test.

EDIT: I think I got it. The bsnes WIPs, on exit, call video.reset(), audio.reset(), and input.reset() on the unique_pointer objects holding ruby's drivers, but bsnes-mcfly was not doing the same. Oh boy, I just went through so many slot→lambda changes, dropping moc from all but 1 file, and the actual fix turned out to be as simple as this? Well, I think these code changes are for the better, so I'll keep them.
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 v106r11 has been released. This version is based on higan/bsnes v106r52... sort of. nall is based on v106r53 and has a new header that has something to do with SIMD. I don't know exactly what it does, but if you have an Intel Core Haswell or later (I have the ancient Lynnfield), and you compile bsnes-mcfly from source (which requires Qt 5 to be in your PATH), it might influence bsnes-mcfly's performance somehow.

This version, to the best of my knowledge, fixes the crash on exit that 007 and I both experienced. Not deconstructing ruby's drivers was indeed the cause of the crash... and then there was another crash on exit. And another one. And another one! My Qt windows weren't deconstructing their widgets (and menus in the case of the presentation window) properly! So I wrote custom deconstructors to handle that properly, and I replaced every Qt slot with a C++11 lambda. Only 1 file in the entire source still requires moc to compile, and it's a template class for the file loader that defines custom events.

I may have missed a window somewhere, but for now, I'm not getting any crashes on exit anymore. Let me know if you still have a crash on exit. If you do, don't delete your settings this time; they might be crucial in reproducing the crash.

And finally, there was an order of operations issue with saving your configuration settings and deconstructing ruby's drivers, so that's been taken care of.

Aside from crash on exit fixes, this version also makes a slight adjustment to the way frame skipping works in the Compatibility and Performance profiles; previously, a bug meant that instead of skipping frames, it was skipping scanlines. The symptom was that when using fast forward in the Compatibility or Performance profile, sometimes only part of the screen would be updated, divided into horizontal bars. It was most noticeable during fades to black. Now, it skips frames like it's supposed to. Note that the Accuracy profile doesn't have frame skip, so it was not affected.
bsnes-mcfly: the bsnes v073 and bsnes-classic killer (GitLab repository)
Post Reply