nesdev.com

That isn't remotely what I said.


What "loophole"? I'm aware (and completely in agreement) that the XML manifest format isn't particularly elegant or well-documented compared to the current standard, but there's nothing in the XML manifest for that translation that isn't a basic feature of the format being used as intended.

You keep acting like like Tom and co. were somehow forced at gunpoint into some kind of horrible ordeal in order to do this completely voluntary thing. Even if they did feel compelled to support this format, I would have been glad to give them a working manifest within minutes had I known at the time that there was a want/need for one, but they also had the tremendously simple option of not supporting the old manifest format at all. People are allowed to decide not to do things.


I didn't do this, for the most part (in fact, I actually removed existing performance-specific CPU debugging code just so it could use the same interface as every other profile). The relatively few performance-specific additions/changes made since then have all been fairly trivial, mostly in the name of making sure all three profiles had consistent debugging behavior. I don't really expect many people to exclusively use (or target) the performance profile, but it's not exactly a huge amount of effort to keep it in for the time being. (All the same, it's not exactly a first-class citizen, as you can probably tell by the lack of official builds for it.)

I believe one of the reasons why they created an XML manifest for Tengai Makyou Zero is that they wanted to use bsnes-plus for debugging, which would not have been possible if they relied only on heuristics. Yes, they could have “chosen not to”, but then bsnes-plus would have been unavailable, and how many other good debuggers are there? Geiger's Snes9x debugger is closed source (a serious flaw in the Snes9x license that FuSoYa also exploited) and wouldn't support the expansion ROM, and laevateinn uses almost the same exact XML manifest format with minor differences.

Thinking on that, it was wrong of me to persuade you to remove manifests from bsnes-plus and use heuristics exclusively (notice I didn't say “bsnes-classic”). However! That still doesn't excuse the continued use of the outdated cartridge folder format where every file shares the same name with different extensions (game.sfc, game.srm, game-1.bst, etc.). That convention only makes sense when not using cartridge folders at all, and it's ridiculous that it's still a requirement when using manifests.

higan v107 will remove filename overrides, which were first added to bsnes v090. Did you know that? That means, in order for a cartridge folder to support both bsnes v073 and higan v107, every file would need to be duplicated, taking up twice the space. And for MSU1 games, that really adds up. Windows does support symlinks, but they're not as well-known as on Linux, and very few archive formats (certainly not ZIP) support symlinks natively.

_________________
bsnes-mcfly: the bsnes v073 and bsnes-classic killer (GitLab repository)

[Deleted hypocritical parody of the first post in this topic, which claimed "to be chill, cool, and non-confrontational" while comparing hex_usr to someone's anus --MOD]

wtf nothing changes. I had stopped following the snes emulation scene many years ago when zsnes still had alot of traffic on its board. this same bullshit was why I stopped folling the snes scene. Thanks for showing me nothing has changed.

bunch of assholes. Im out.

good job killing a community.

I'm just going to ignore/report that. Not really interested in people trying to stir more shit up here.



Fair enough. Like I said, I would have been happy to give them a hand with it, and I apologize if it really was that much of an inconvenience.



No disagreement from me at all there. I'd like to make it clear that I don't actually think the old manifests are actually better in any way, it's just what my personal tool of choice happened to already have. While I'd like to continue supporting it for legacy purposes if at all possible, it's really only inertia and prioritizing other useful features that's kept me from additionally supporting a newer standard thus far. I'd appreciate not being made out to be some sort of die-hard XML traditionalist just because my personal development interests don't always line up 100% with other people's.

I haven't actually looked at bsnes v106 etc. yet, but I'm interested in seeing how it handles all of that.

"bunch"? Any other than this sockpuppet, whose post has since been blanked?

Thank you for not feeding the troll.

Look, I know I'm overzealous, and that I come across as a pompous jerk with nothing better to do than cannibalize other people's software. But I hope you understand how much it means to me to put in this much effort.

I won't name names, but about 5 months ago, I was asked to add a feature to Olympian Magic to convert higan v106 manifests to v073 format. I had my doubts about whether I should go through with it, because I didn't want bsnes v073 to become the next ZSNES with hacks and homebrew that won't take advantage of MSU1 revision 2's audio resume feature or any other improvements just because they aren't available to bsnes v073. Ultimately, that feature never made it into Olympian Magic.

After 2 months of maintaining Olympian Magic, I thought I'd experiment with trying to compile Qt. Wanting to migrate the Qt UI to the current higan version was on my mind for many years, but because of the difficulties involved in having Qt as a dependency, I didn't get around to it until 2 months ago. And when I finally managed to compile bsnes v073, that's when my plan came into being. I would attempt to migrate the Qt UI to bsnes v074, which added low-level emulation of the ST010 and ST011. I would take the opposite approach from AWJ, who merely backported those coprocessors from v074 to v073. And I was successful. I had a working build of bsnes v074 with the Qt UI. I then migrated to bsnes v075. And then v076. And so on.

As I migrated up the bsnes versions, I grew confident. I could make a version of the Qt UI with all the latest bugfixes from higan v106! BML manifests could finally flourish, and XML manifests wouldn't need to be kept around anymore! Olympian Magic wouldn't need to have down-conversion paths, and the only way to go is up! Because as far as I was concerned, the only reason XML manifests are still in use today is that people flocked to bsnes v073 and its forks and wouldn't give later higan versions a chance. All because higan doesn't natively support standalone ROMs and has to outsource that support to an external library, resulting in cartridge folders created in the user's home directory.

When it came time to make the first release, I initially chose the name “bsnes-classic”, exactly the same as AWJ's fork. The last commit to bsnes-classic was on 2017-09-05, and I didn't think the project was still active anymore. So I wanted to carry on its legacy, though with exactly the opposite methodology (forward-porting the UI instead of back-porting emulation improvements). But AWJ PM'd me, told me that bsnes-classic is still active, and asked me to change my fork's name. I did, but that doesn't mean I can't still put in my best efforts to replace bsnes v073 and bsnes-classic with bsnes-mcfly.

The before-mentioned confidence is the reason I push back so hard when people diss my hard work. When AWJ accused me of browbeating him into removing features from bsnes-classic, I vowed to continue making bsnes-mcfly an emulator that anyone will want to choose over bsnes v073 or bsnes-classic, no matter what hoops I have to go through to make that happen. Before all this, I used to be really sensitive and easy to bully. I hope you understand, even if you don't forgive me.

I don't see the official bsnes v107 as competition. I've said this multiple times in this thread, but people who are satisfied with the official bsnes should use it instead. Its GUI toolkit, hiro, is way more stable and bug-free than Qt. I made bsnes-mcfly so that bsnes v073's and bsnes-classic's holdouts, who latch on to features that won't be in the official bsnes, could enjoy all the latest emulation accuracy improvements and would no longer have to deal with XML manifests.

_________________
bsnes-mcfly: the bsnes v073 and bsnes-classic killer (GitLab repository)

I wish 007 was still here. He reported a Windows-exclusive crashing bug that occurs when a user:

• Selects the Direct3D driver
• Turns off exclusive fullscreen and turns off auto-hiding the menu bar in fullscreen
• Activates fullscreen
• Switches to a video filter with a different output size than the previous one

I can't reproduce the bug. No matter which profile I use, no matter how much I change the filters, nothing happens. Even if I use the Compatibility: OpenMP profile, which is the only one capable of outputting 256 columns instead of 512 when using Modes 0, 1, 2, 3, 4, or 7, and play Secret of Mana, which is known to switch between Modes 1 and 5, nothing happens. The emulator just continues as normal.

Without any further bug testing, I'm just going to have to release bsnes-mcfly v106r08 and hope for the best. This version is based on bsnes v106r46.

As previously mentioned, this version includes 7z archive support using the public domain LZMA SDK. The supported compression formulas are LZMA, LZMA2, and PPMd. I haven't completed my rewrite of the GPLv2 parts of libjma, so JMA support is not in yet.

I am also dropping the Compatibility: Legacy profile, so the only 3 profiles are Accuracy, Compatibility: OpenMP, and Performance. I have not dropped the source code for it though, just in case an emergency happens and I need to keep it around longer. If you happen to have Compatibility: Legacy selected, the launcher should automatically select the Compatibility: OpenMP profile instead in order to prevent the program from prematurely quitting because it can't find the missing profile.

The Compatibility: OpenMP and Performance profiles now share the PPU class. Even if I disable OpenMP, the Performance profile has the same speed as before, so enabling OpenMP increases it even more.

In addition, I made a change to the Performance profile's APU (merged SMP/DSP) class inspired by but not taking code from Snes9x. Previously, the Performance SMP had a hidden compiler flag to switch between Opcode timing and Cycle timing, with Opcode timing being faster but incompatible with games that stream samples such as Tales of Phantasia. Now, a mixed timing option is used instead, in which timing synchronization only happens immediately before any read/write operation on the APURAM. This timing is slightly faster while still being compatible with Tales of Phantasia. How does this code differ from what Snes9x uses? I believe Snes9x wrote all the opcode timing by hand, but I took advantage of the little-known generate program and made it generate the timing information for me.

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

Since I mentioned Olympian Magic prominently in my previous post, I'm going to release Olympian Magic v00r07. This is a GUI application for converting higan/bsnes's cartridge folders from older versions to the most current version, v107. It will show you how the manifest will change during the conversion and any filename changes for the ROM, save RAM, and coprocessor firmware.

Previous versions of Olympian Magic supported converting v073 manifests to v092-v095 and v096-v106, and converting v092-v095 manifests to v096-v106. The only down-conversion path supported was from v096-v106 to v092-v105. I deeply regret having ever added that path. The only reason I did was to support the Nintendo Super System, for which higan dropped support after v094r08, but that's a terrible excuse to let the entire SNES emulation scene go stagnant just for the sake of an arcade machine.

From now on, v107 is the only supported conversion target. Olympian Magic will be able to convert manifests from v073, v092-v095, and v096-v106 to v107 and no other version.

When the source version is v073, the supported coprocessors are SA1, Super FX, uPD7725 (DSP1-4), S-DD1, and OBC1. The SPC7110 is the most complicated coprocessor manifest-wise, so I haven't added support for that one yet. It also does not yet support either of the RTCs. I won't worry about the ST010, ST011, ST018, and Cx4, as bsnes v073 did not support low-level emulation of those coprocessors.

Note that MSU1 support is handled internally by higan and bsnes, so there is no need for a manifest to specify that the MSU1 is supported.

Olympian Magic can also convert an entire cartridge folder from v073 to v107, renaming every file except for the manifest and replacing the manifest itself with a converted version. It even creates an “msu1/” subfolder and moves the MSU1 files into there. It will probably handle converting v092-v095 and v096-v106 cartridge folders as well, but this is untested.

_________________
bsnes-mcfly: the bsnes v073 and bsnes-classic killer (GitLab repository)

Renaming bsnes-accuracy.dll worked, but bsnes crashed when I loaded a game.

For a little while, the Accuracy profile was internally known as “Accurate”, because that was the working name for some bsnes WIPs between v106r15 and v106r35. When byuu figured out how to compile both the Accurate and Fast profiles into the same executable, he dropped those profile names, and I reverted back to “Accuracy”. You probably used a bsnes-mcfly version where I used the “Accurate” name, and then upgraded to this one, which now uses “Accuracy”.

What you need to do is edit your settings-qt.bml (which, if you're using Windows, is probably in “%APPDATA%\Roaming\bsnes-mcfly\”) file and change “Profile: accurate” to “Profile: accuracy”. You can also delete this file if you want to configure all of your settings again.

_________________
bsnes-mcfly: the bsnes v073 and bsnes-classic killer (GitLab repository)

It works, thanks.
I've been able to reproduce the crash bug you mentioned earlier.
It crashes with Radical Psycho Machine (US version).
Load the game in full screen, select Scale2x, then phosphor3x, and it crashes.
If Phosphor3x.filter is selected as a filter in the config file, it immediately crashes if I try to load RPM.

Ah, I think I know what the problem is.

I was trying to be too clever. I made the software filters render directly into ruby's video buffer and didn't use an intermediate buffer. I did it that way hoping that I could save on performance by omitting a memory copy every frame. I don't know exactly how the direct method was crashing, but changing it to have the software filter render to an intermediate buffer and then copying it into ruby's buffer fixed the problem.

This fix will appear in bsnes-mcfly v106r09. When not using any filter whatsoever, emulation speed should remain the same, but when using a filter, a speed penalty may be incurred by running an extra memory copy every frame.

Radical Psycho Machine Racing is known to use Interlace mode, which doubles the vertical resolution from 240px to 480px. You're using the Accuracy profile, so the horizontal resolution will be 512px regardless of what game you're playing and what BG mode is active (although RPM Racing uses Mode 5, so even the other profiles will use 512px). This makes for 245,760 square pixels. The Phosphor3x filter's width is fixed at 768 pixels (Modes 5 and 6 use a little blending on the green dots to achieve this resolution), but its vertical resolution is 3× the source buffer's vertical resolution. This means that it was rendering a 768×1440 buffer, or 1,105,920 square pixels. I'm not sure what effect this has on ruby when using the Direct3D driver; I'm just putting these calculations out there in case someone has more insight.

_________________
bsnes-mcfly: the bsnes v073 and bsnes-classic killer (GitLab repository)

Im here. I was just not coming on due to being annoyed with ppl attacking you.


Anyway I know why I get the error and you dont.

I keep my desktop resolution at 1280 x 720 aka 720p because Im playig on a media center on a 60 inch tv from 15 feet away.

That being said I discovered that by setting desktop to 1920 x 1080 bug goes away.

If you set your desktop to 1280 x 720 and do what I did the bug will happen instantly.

I wish bsnes had the option to set pc full screen resolution to different than desktop like snes9x and many other emulators. With certain setups this would be a handy feature.

Ive switched back to my 1280 x 720 desktop after figuring out why the crash would happen, the trick is if running such a low resolution do not cycle through filters in fullscreen mode.

Thanks again for this software. Thanks to you I get to enjoy the bsnes engine with blarggs filter, I love byuu's emulator and blargg's filter and you put them together for me!


With all I said above I dont consider my bug a bug its a side effect and easy to work around, if a fix cant be implemented a note somewhere for new users would help.

Hope to see a 106.48 release of mcfly!

Thanks again.

And as always Ionly report my findings in an effort to help, Im grateful you people make this stuff and would never dare complain.

Sorry about the late response. Migrating bsnes-mcfly to higan/bsnes v106r48 was a bit of an ordeal given the massive changes to nall. But I did it anyway, so here's bsnes-mcfly v106r09 (based on higan/bsnes v106r49). This release should have somewhere around a 7% speedup when using the Compatibility: OpenMP profile (not sure about the Accuracy profile) because of byuu's internal changes to bsnes. In addition, I changed the way video filters work by restoring the video buffer that I had previously removed. I hope that fixes the crashing bug when switching between filters with different output sizes.

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

I spent the past 2 days trying to add resolution changing to the Direct3D driver (because its absence is starting to look like a deal breaker), and failing no matter what I try. I used the following code to start with:



I run this code before calling the Qt function showFullScreen(). Unfortunately, being the bug's nest that it is, Qt thinks the resolution is still the original desktop resolution of 1920×1080.

If I then edit ruby/video/direct3d.cpp and hardcode the resolution in the _monitorWidth and _monitorHeight variables, I can force the resolution, but one of two things will happen depending on the order of operations:

• No video is output at all
• Only the upper-left corner of the video will be shown (related to Qt thinking the original resolution is used)

In addition to either of those, when I go back to windowed mode, the window's title bar and border are not restored, as if Qt still thinks fullscreen is being used. I have to press Alt+F4 in order to force close the application at this point. And even that doesn't restore the positions of all open windows, which have been shrunk down and forced to the upper-left corner. That's terrible! Who would use a feature that ruins their carefully-adjusted window arrangement every time they use it?

All of this would probably be easier if I had used hiro instead of Qt. I would like so much to use the former, but I have to use the latter for fear that someone would reject hiro outright because they think it's associated with the strict standards compliance of higan and not the feature richness of bsnes v073. The only features that would be lost if I had used hiro instead are:

• The TreeView on the Settings/Input tab (hiro only has an implementation for GTK, and while I did attempt a Windows port, it's woefully incomplete, and no macOS implementation exists)
• Opening menus without pausing emulation (at least on Windows; hiro/GTK doesn't pause emulation when opening menus)
• PNG screenshots with good compression (I wrote a Deflater and PNG compressor for my ramus library, but it doesn't perform as well as Qt)

007, have you asked byuu if he will add resolution changing to bsnes v107 yet? I think it would work so much better with hiro instead of Qt, and it would save me from having to add it myself (it was never in bsnes v073 or bsnes-classic, and I would prefer that people who are satisfied with bsnes v107's feature set use that instead).

_________________
bsnes-mcfly: the bsnes v073 and bsnes-classic killer (GitLab repository)

I have mentioned this to byuu, dont know if he will implement.

Im currently liking mcfly. One thing that I like about it a lot is blarrg's filter which I am not sure if bsnes will ever see.

The resolution changing is a wish not a must have.

Thanks for another great build.

Just trying r09 I see you brought compatibility legacy back.