bsnes-mcfly seeks to port the Qt GUI of bsnes v073 upwards to modern higan/bsnes versions, so that the long list of features in this GUI are usable with the latest SNES emulation improvements, both with traditional ROM files and with higan v107-style gamepaks (cartridge folders). The goal is to get users to migrate away from bsnes v073 and bsnes-classic, so that its ancient cartridge folder format with XML manifests can finally be put to rest permanently.
What bsnes-mcfly does NOT do is compete with bsnes v107. I will not actively encourage users of bsnes v107 to migrate to bsnes-mcfly, because bsnes v107 combines the most important features with a relatively bug-free GUI, and I have no desire to harm bsnes v107 in any way.
Current release version:
v106r14b (based on higan/bsnes v106r63)
This version of the Qt GUI has the following features (an
! indicates an evil hack that modifies part of the Super Famicom emulator core):
- Compatibility with higan/bsnes v106r63, including v107-style gamepaks (cartridge folders)
- Low-level emulation of the HG51BS169 (Cx4) and ARM6 (ST018)
- Newer MSU1 features such as audio resume
- Concatenated firmware in game ROMs, as well as a "firmware/" fallback directory.
- No cartridge folders are created within the user's home directory. It is all handled in memory.
- Database lookup of SNES and Super Famicom cartridges. The database is embedded right into the application along with heuristics for games not in it, so icarus is not required.
- Compressed archive support
- Built-in: Zip, GZip
- With archive-reader: 7z, BZip2
- 7z support by Igor Pavlov's LZMA SDK, available in the public domain
- BZip2 support by Rob Landley under the zero-clause BSD license
- Copier extensions: SMC, SWC, FIG, UFO, GD3, GD7, DX2, MGD, MGH, 048, 058, 068, 078, BIN, USA, EUR, JPN, AUS
- All of these extensions are also available for use with BS Memory and Sufami Turbo slot cartridges.
- Optional 512-byte copier header
- WASAPI and ASIO audio drivers
- Exclusive mode for Direct3D and WASAPI
- Separate directories for save RAM, save states, and other mutable game files
- Turbo buttons
- asciiPad (more advanced turbo switches with Off, Turbo, and Auto settings)
- !Simultaneous up+down and left+right (must be enabled in the settings file)
- IPS, UPS, and BPS soft-patching
- IPS and UPS patches are applied before removing the copier header, and BPS patches are applied after.
- Movie recording and playback
- Cheats
- Raw/Pro Action Replay (AAAAAA=DD, AAAAAA=CC?DD, AAAAAA:DD, AAAAAADD, AAAAAA/DD)
- Can omit the address/data separator, use an equals sign, or use a colon; higan supports the equals sign only.
- Game Genie (GGGG-GGGG)
- Will remember that you inputted the code in Game Genie format instead of converting it to Pro Action Replay on save and reload.
- Cheat search (works only on WRAM at 7e-7f:0000-ffff)
- !Enabling/disabling of individual PPU layers and DSP channels (the former only in the Compatibility and Performance profiles, the latter in every profile)
- Software filters
- 2xSaI, Super 2xSaI, Super Eagle
- HQ2x, LQ2x, Scale2x
- Pixellate2x
- blargg's snes_ntsc (with 15-bit precision instead of 13-bit precision)
- Phosphor3x (was included in some bsnes v08x versions)
- OpenGL shaders
- Curvature and Edge Detection from higan v092
- HQ2x, Pixellate, Scale2x
- HDR-TV, Watercolor (these were marked “Archive” in bsnes v083 and not restored when bsnes v085 went back to XML from BML)
- Sepia (converted from Direct3D)
- Only 1 copy of nall for the overall project instead of a separate copy each for bsnes, snesfilter, and snesreader
- Performance profile speed hacks (accuracy and compatibility profiles not affected)
- High-level emulation of the DSP1, DSP2, DSP3, DSP4, ST010, and Cx4, but firmwares are still required
- SMP and DSP are merged into a single APU class that references blargg's SPC_DSP
- Mixed opcode/cycle timing for the SMP; slightly faster while still supporting Tales of Phantasia
- Only the Super Scope and Justifier use cothreading instead of every single peripheral
- JOY1/JOY2/JOY3/JOY4 registers handled on a controller-by-controller basis
Features missing from bsnes v073:
- Compressed archives: Z (compress), RAR, JMA
- All of these have restrictive licenses. Need to think carefully on how to implement them...
- Selecting one of multiple files in a single Zip archive
- snes_ntsc configuration dialog
- Because the palette size was increased from 32768 to 524288, changing a setting causes bsnes-mcfly to freeze while it recreates the palette. This dialog had to go.
- Binding the Pause/Break key to an input
- Direct3D shaders
- As consolation, the Sepia shader was converted to OpenGL
If anyone has any reason whatsoever to switch back to bsnes v073 or bsnes-classic after trying my emulator, please let me know. I will rectify that situation as soon as I can. My goal is to kill XML manifests, and anything that causes bsnes-classic to remain popular is also something that keeps XML manifests alive, so I will take any legal means necessary to stop that from happening.
That said, the official bsnes v107 is the preferred option, so if you are satisfied with the feature set of bsnes v107, then use that instead. bsnes-mcfly is only concerned with replacing bsnes v073 and bsnes-classic, not bsnes v107.
==============================
Original post: “Is AWJ still in the scene? Regarding bsnes-classic”
Hello everyone. I was highly reluctant to come back to NesDev after a heated dispute between me and some of the forum members here on NesDev last year, but today, I will make a one-time exception.
AWJ made a fork of bsnes v073, which he called “bsnes-classic”. In it, he revived the Qt-based GUI and backported low-level emulation of the uPD96050 coprocessor used by F1 Race of Champions II and Hayazashi Nidan Morita Shougi from bsnes v074. Since then, he has backported a few of higan's emulation accuracy improvements, all to an ancient version of bsnes, all for the sake of a feature-rich GUI based on a bug-plagued toolkit. bsnes-classic was further forked into the debug-oriented bsnes-plus.
I believe that this practice is unsustainable. As higan's accuracy increases, so too does the effort needed to keep track of its changes and backport them. Most importantly, bsnes-classic preserves a badly-aged XML-based manifest format for cartridge folders; today, higan uses a slimmer syntax named “BML” for manifests, and many years of experience have shaped the syntax into what it is today, so that ROM hackers have greater control over their memory maps than they did back in the days of bsnes v073. Unfortunately, the convenience of the Qt GUI means that ROM hackers such as Tom (Far East of Eden: Tengai Makyou Zero) must force themselves to hack the older XML manifest which, given its age, is prone to errors and failure. The situation is not unlike ZSNES, by far the most popular and simultaneously the most bug-filled emulator, whose tremendous userbase holds back progress with translations and ROM hacks that won't work on real SNES hardware.
Therefore, I seek to do the exact opposite: to forwardport the Qt GUI and make it work with higan v106 and later versions. I have documented my efforts
on byuu's message board. The current working name for this fork is “bsnes-classic”, exactly the same name as AWJ's fork, and that is not a coincidence.
It cannot be denied that what I am doing is predatory; I am writing a higan fork with exactly the same name as another fork and with the same goals, with the sole exception that it be based on higan v106 instead of bsnes v073 and use the former's BML manifest format both with traditional ROM files (both headered and headerless) and with cartridge folders. Therefore, I believe I owe it to AWJ to inform him of the existence of my fork named “bsnes-classic” so that he can share his opinion on whether I should keep using the name and what he will do with his fork.
And therein lies the reason for my return to NesDev, despite my better judgement: AWJ has been offline from NesDev since October, and neither has he shown any signs of life on GitHub. Even on Freenode's #retroarch channel, hunterk searched and could not find him. If I cannot get in contact with AWJ, then the future of bsnes-classic (my fork, not AWJ's) and the ideals that come with it look bleak.
I hesitate to ask NesDev about this after the way a few of its key members have treated me in the past, but for now, I will steel myself against any flames that come my way. Does anyone here on NesDev know about AWJ's current status within the emulation community as a whole?
I haven't had any correspondence with him in at least as long either, but I can PM you his email address if you want.
Thanks for giving us a second chance.
Do you have a different set of initials you can use as a suffix after "bsnes-"? Several years ago, FCE Ultra was getting forked left and right, and there were FCEUD, FCEUXD, FCEU-mm, FCEUXD SP, etc., until the alphabet soup resolved itself into FCEUX.
I would prefer not to use e-mail if I can help it. Perhaps you could e-mail him on my behalf, Revenant?
Regarding alternative names: I'd prefer to use “bsnes-classic” if I could be assured that it could replace AWJ's work entirely. I already have a local Git repository using the name, documenting all of my changes as I migrated to each successive version after v073. But if all else fails, I could choose to use the name “bsnes-Qt” instead.
Another fork by that name exists, but its maintainer is Themaister (of RetroArch fame) who is certainly still active, and it only has a grand total of 3 commits since its creation at the end of 2010.
The questions asked were: 1) is AWJ still in the scene, and 2) how can I reach AWJ. The answers are 1) probably but you'd have to ask him, and 2) I'm not sure (it sounds like you've exhausted your avenues, which means you've done your due diligence in attempting the Right Thing(tm)). One thing I will mention is that sending a PM on nesdev, unless the user has changed their settings otherwise, by default will send an Email to the account holders' Email address with the subject "New private message has arrived". If you haven't tried that, I'd suggest it as a final avenue.
On the subject of project naming conflicts: meanwhile,
we have other software that changed its name to avoid name conflicts. Open-source etiquette and netiquette would strongly advocate you not use the name of an existing project (it doesn't matter if it's dead or alive/active), but obviously nothing *requires* you do that. Though I will say, your choice of words ("It cannot be denied that what I am doing is predatory") will certainly not sit well with some folks. But in the end, do whatever you wish.
Maybe higan-classic, since the big differentiating factor is that it's based on higan rather than bsnes?
Alternatively, you could use other words that give the same effect as "classic", like bsnes-vintage, bsnes-throwback, etc.
There's plenty of names that haven't been used yet, so I don't see any benefit to using the same name as bsnes-classic. Rather than replace it, you're more likely to breed unnecessary confusion, not to mention that it just comes off as hostile.
Nicole wrote:
Maybe higan-classic, since the big differentiating factor is that it's based on higan rather than bsnes?
Considering that bsnes is the name of the SNES core in higan, and this newer version is based on only higan's bsnes core, it seems appropriate. Naming issue aside, it's nice to see the Qt-based GUI running the newest higan v106 SNES core. Also nice to see the Qt5 migration is in progress as well.
Try this on for size: "bsnes-10x". It alludes to both the project's goal to put the bsnes core from the higan 100-106 series into the old bsnes GUI and the goal of replacing Snes9x.
tepples wrote:
Try this on for size: "bsnes-10x". It alludes to both the project's goal to put the bsnes core from the higan 100-106 series into the old bsnes GUI and the goal of replacing Snes9x.
*raised eyebrow* People will read this as "10 times the bsnes" or "bsnes 10 times". Comparatively, higan-classic makes a lot more sense, and is what i'd vote for if this was a poll.
I'm inclined to agree with "higan-classic" as well; it's not already in use and does well enough conveying the "best of both worlds" approach behind the project.
hex_usr: I can email AWJ, but as koitsu pointed out you may want to try directly PMing him here on nesdev first, since that should notify him via email anyway (assuming he provided his address).
Perhaps bsnes-100series will do the trick (going off of the bsnes-10x idea)?
Well, I sent a PM to AWJ this morning (shortly before 09:00 PDT). As of 17:00 PDT today, he hasn't responded.
The name “higan-classic” misses the point of this fork. I am reviving the Qt GUI that bsnes v073 had, and it will only be compatible with the Super Famicom (including the Super Game Boy). Recall why byuu renamed his emulator to “higan” in the first place: in addition to the Super Famicom, he created emulators for multiple other consoles (Famicom, Game Boy, Game Boy Advance, and more recently the WonderSwan, Mega Drive, Master System, Game Gear, and PC Engine), and the name “bsnes” became increasingly inaccurate. The rename happened at v092.
I don't really like the ideas that play on Snes9x's name. It is not Snes9x that I hope to replace. Snes9x is at least as accurate as bsnes-performance yet has vastly superior speed because it is not held back by inappropriate use of libco.
There might be some merit to using names such as “bsnes-vintage” or “bsnes-legacy”, but I'll wait a little longer for AWJ's opinion before I make a decision.
You guys aren't wrong for calling this tactic hostile, but I think you deserve to know why I'm doing this. Take a look at the XML manifest for the English translation of Far East of Eden: Tengai Makyou Zero:
Code:
<?xml version='1.0' encoding='UTF-8'?>
<cartridge region="NTSC">
<rom>
<map mode='shadow' size='0x100000' address='00-0f:8000-ffff'/>
<map mode='shadow' size='0x100000' address='80-bf:8000-ffff'/>
<map mode='linear' size='0x100000' address='c0-cf:0000-ffff'/>
<map mode='linear' offset='0x600000' address='40-4f:0000-ffff'/>
</rom>
<spc7110>
<ram size='0x2000'>
<map mode='linear' address='00:6000-7fff'/>
<map mode='linear' address='30:6000-7fff'/>
</ram>
<mmio>
<map address='00-3f:4800-483f'/>
<map address='80-bf:4800-483f'/>
</mmio>
<mcu offset='0x100000'>
<map address='d0-ff:0000-ffff' offset='0x100000' size='0x500000'/>
</mcu>
<dcu>
<map address='50:0000-ffff'/>
</dcu>
<rtc>
<map address='00-3f:4840-4842'/>
<map address='80-bf:4840-4842'/>
</rtc>
</spc7110>
</cartridge>
In the manifest above, it's not immediately obvious where the program and data ROMs end and where the expansion ROM begins, and how all 3 ROMs should be mapped. The method they used to add the expansion ROM to this manifest is a blatant hack. bsnes v073's manifest format was not designed to accommodate this use case.
That Tom and his hacking team had to carefully study this ancient manifest format and come up with this hack, all for the sake of a user interface that died long ago... how else can I describe bsnes v073 other than “the ZSNES of cartridge folders”? No one should ever have to force themselves to write manifests such as the above just for the sake of a few holdouts that don't like the direction higan has taken.
And if my ZSNES comparison is not enough for you, then compare it to Internet Explorer 6, which for years was the dominant web browser (and still is in China), holding back innovations in web design until 2014 when Microsoft finally ended official support for it.
How necessary is this now that
byuu is reviving bsnes?
I've been aware of bsnes's revival since the day it was revealed. I'm actually looking forward to its release; bsnes will include a multithreaded PPU that has the potential to be faster than the current compatibility/balanced PPU, yet has the same compatibility. That is to say, it will not support Air Strike Patrol or the 2 Player mode of Uniracers like the accuracy profile does. If and when this is accomplished, I will replace the balanced profile's PPU with the parallel PPU in my fork.
Besides, I am not personally a fan of Qt as a GUI toolkit. More than anything, it is horribly plagued with bugs that have to be worked around, and it is very easy for some bugs to slip into public releases, which was a frequent problem with bsnes versions 040-073. Anyone who favors stability over extra features should use bsnes instead when it comes out.
The reason I persist in continuing the Qt GUI is for its many extra features, such as rewinding, movie recording/playback, screenshots, extra archival formats such as GZip (might support JMA if I can figure out its license compatibility), and obscure filename extensions such as SWC and FIG. All of which will be excluded from bsnes. If I don't do this, then the badly-aged XML manifest format will remain popular long past its expiration date (5 years in the past when v092 introduced BML and separated the SPC7110's program and data ROMs).
Also, I'm not entirely certain of this, but it looks like while my Qt fork will support both standalone ROMs and cartridge folders, bsnes will support standalone ROMs exclusively, though this is unconfirmed.
What I am planning to support:
* loading ZIP files
* loading SFC and SMC files
* loading BPS patches (with a load dialog option to not apply them)
* loading copier headered images
* loading coprocessor firmware appended to ROM images or from a separate firmware/ subfolder
* recently played games list
* optional per-path selections for games, patches, save files, cheat codes, and save states
* OpenGL video shaders
* dynamic rate control for smooth video+audio without the need for an adaptive sync monitor
* automatic input mapping for XInput controllers
* a parallel PPU that (hopefully) will clock in somewhere between bsnes-performance and bsnes-balanced
* cheats codes + database of cheats from mightymo
What I may support one day:
* loading gamepaks (game folders)
* loading IPS patches (will have to display a dialog asking if the patch is for a headered or unheadered ROM)
* simple SuperFX overclocking
* state manager
* simple rewind
* BMP image captures (at a fixed 512x448/512x480 resolution)
What I don't plan to support:
* software video filters
* per-layer BG/OAM toggling
* per-channel audio toggling
* movie recording and playback
* PNG screenshot captures (no encoder)
* 7zip, JMA, gzip, bzip2, rar, etc
* multi-ROM solid archives
* PPU sprite limit disable
* PPU hires mode 7
* advanced CPU overclocking (it's too tightly bound to the other components like the PPU)
* real-time rewind
* debugger
* netplay
* TAS functionality
* coprocessor HLE
* controlling the UI entirely from a gamepad (eg a raster-based GUI)
* ZSNES emulation
My goal is to make the easiest to use program possible, and I'll be omitting features that complicate the design. I also see no reason to cede ground on battles we've definitively won (nobody uses FIG/SWC/JMA anymore.) I still want to try and advocate for moving the scene forward instead of staying stagnant forever, but my activism is burning out as I get older. I hope this will be compelling to people who just want to play games, and aren't on Raspberry Pis or cell phones.
I'm sure it won't ever replace the endless forks of bsnes and Snes9X out there.
I guess we'll see what people think once it's released and supports at least all the primary desired features.
If you add IPS support, consider providing an option to let the user mark an IPS as using a header or not by renaming it to end in ".sfc.ips" or ".smc.ips".
Why no PNG screenshots? Qt can encode a QPixmap to PNG, if
this answer by Kaleb Pederson is to be believed.
Code:
QFile file("yourFile.png");
file.open(QIODevice::WriteOnly);
pixmap.save(&file, "PNG");
It can, but higan/bsnes hasn't had Qt as a direct dependency in years and I don't think this new official incarnation of it is supposed to either.
bsnes will use hiro as its GUI toolkit, just like higan. hiro does not offer any features not explicitly meant for GUI design, so even though it has a Qt compilation target, it cannot be used to save PNG images. The most complicated part of PNG is Deflate, and while nall (general-purpose header library) has a Deflate decoder, it does not have a Deflate encoder. In fact, nall can create Zip archives, but it uses the Store method exclusively when it does so.
bsnes v073 previously supported UPS as its only patching format, and it applied UPS patches before trimming headers. For bsnes-classic, I'm planning on doing the same thing with IPS patches but waiting until after trimming headers before applying BPS patches.
In case anyone wanted to know what bsnes/higan versions supported which GUI toolkits, here's a chart:
hiro (old):
bsnes v028-v041
Qt:
bsnes v040-v073
phoenix:
bsnes v069-v091
higan v092-v094
hiro (new):
higan v095 and up
bsnes v107 and up
hex_usr wrote:
Well, I sent a PM to AWJ this morning (shortly before 09:00 PDT). As of 17:00 PDT today, he hasn't responded.
Individual is alive and well. Patience is a virtue.
Yep, I just got his private message, too.
AWJ has spoken: his project is still alive, and he wants me to rename my project.
I replied to him that it would be really nice if he could either update bsnes-classic's manifest format to BML, or retire manifests and exclusively use heuristics. I'll still rename my project either way, but I'll be much happier about it if AWJ does either of these things.
Because it was always about the XML manifests; I wouldn't have ever bothered if bsnes v073 had no manifest support whatsoever.
hex_usr wrote:
Yep, I just got his private message, too.
AWJ has spoken: his project is still alive, and he wants me to rename my project.
I replied to him that it would be really nice if he could either update bsnes-classic's manifest format to BML, or retire manifests and exclusively use heuristics. I'll still rename my project either way, but I'll be much happier about it if AWJ does either of these things.
Because it was always about the XML manifests; I wouldn't have ever bothered if bsnes v073 had no manifest support whatsoever.
I don't understand what you intend to gain by attempting to browbeat me into removing functionality from my software.
hex_usr wrote:
Because it was always about the XML manifests; I wouldn't have ever bothered if bsnes v073 had no manifest support whatsoever.
In what way is "no manifest support" supposed to be an improvement over "older manifest support"? It wouldn't improve the situation with, for example, the FEoEZ translation. Likewise, retroactively removing manifest support entirely would just inconvenience actual users by breaking support for numerous existing projects for no particularly great reason.
If "BML instead of XML" were just about language/syntax then I would have done it in bsnes-plus a long time ago, but the part that's not immediately implied is the additional reliance on outright gamepak/cartridge folders, a board database, etc. which are all rather conceptually major changes that I simply don't have the time or desire to prioritize at this point (and I have a feeling AWJ doesn't either).
(I absolutely don't intend to start any kind of additional discourse/debate about this, but 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.)
It really doesn't accomplish anything for AWJ to update from one deprecated format to another deprecated format.
My end goal is for users to not have/need/want actual manifest disk files to exist at all. It's just not possible to express every variation on SNES PCBs (down to literal bodge wiring on production games) with 100% perfection without it being hopelessly emulator-specific.
Manifests are, at best, a way for users to get games working that don't work in higan out of the box. Anything worthwhile will get supported in icarus directly, including Tengai Makyou Zero's fan translation in v107.
We don't even have userbase numbers for mainline higan, let alone any forks, so who knows if it's even worth pursuing. Open source lets people do whatever they want. Some people sell my work and don't share money with me, some people complain about my code yet fork it instead of writing their own, some people go against my wishes and do things I'm opposed to,
and some, I assume, are good forks (but seriously, some forks are pretty great!) It is what it is, and I knowingly agreed to that when I chose my license. I'm trying not to complain so much about forks I don't like anymore, but I've always acknowledged they have every right to do what they want.
If I want people to use my work, I'll just have to give it my all to put out the better release.
Quote:
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.
As of v107, I've removed the board mapping rules from the manifests, and I'm making a promise not to break the format of manifest.bml again. Yes, seriously. I promised to not change BPS, and I haven't. And I promised not to change bass syntax anymore with v15, and I haven't. I promised MSU1 would remain backward compatible to v1.0, and it has.
I'd love it if other projects could utilize my SNES preservation database, because holy
god damn I put a lot of time, money and effort into that, and I'm not even halfway finished yet. You don't need manifest files next to ROMs for that, though. You don't need game folders for it either, as I'm demonstrating with bsnes v107.
But right now, the only thing I'm literally on my hands and knees
begging for, is set maintainers to distribute coprocessor firmware with games. I don't care how they end up doing it, I'll support it. You've got your copier headers, your SMC file extensions, your compressed archives, just
please ... I need the firmware! It's part of the goddamned game, and it's copyrighted -- I can't ship it!! This is leaving me at a permanent disadvantage to HLE-based emulators, where games just "work" out of the box.
byuu wrote:
As of v107, I've removed the board mapping rules from the manifests, and I'm making a promise not to break the format of manifest.bml again. Yes, seriously. I promised to not change BPS, and I haven't. And I promised not to change bass syntax anymore with v15, and I haven't. I promised MSU1 would remain backward compatible to v1.0, and it has.
Totally understandable, hence "on the off chance" - I was pretty much assuming it wasn't actually going to happen, and I respect your decision about that.
(I was also assuming that the v107-and-on format was what hex_usr was referring to in the first place, but I've already forgotten too much about the other previous formats to know if there might have been a more fitting alternative that anyone still uses...)
Quote:
I'd love it if other projects could utilize my SNES preservation database, because holy god damn I put a lot of time, money and effort into that, and I'm not even halfway finished yet. You don't need manifest files next to ROMs for that, though. You don't need game folders for it either, as I'm demonstrating with bsnes v107.
Believe me, I greatly appreciate the work that's been put into this, even though my own fork doesn't directly benefit from it nearly as much as it could/should. And it has never really been my intent for bsnes-plus to somehow undermine or compete with mainline higan either, especially now that it's becoming (in my eyes) more and more attractive to the average user with every new release, not to mention the fact that it's much more actively maintained.
The fact is that I just decided one day to start on a little hobby project based on something I was personally familiar with, for better and/or worse. (Really, the only actual goal was for me to not have to use Geiger's debugger anymore, and I guess mission accomplished?)
Wait, do I read it right that bsnes-plus does not require the annoying cartridge folder?
Quote:
The fact is that I just decided one day to start on a little hobby project based on something I was personally familiar with, for better and/or worse. (Really, the only actual goal was for me to not have to use Geiger's debugger anymore, and I guess mission accomplished?)
You have the one project where I completely understand why you're stuck on the version number you are. It needs such a massive amount of hooks into the core, and the core is constantly changed and cleaned up by myself. Bizhawk comes in second place, but I don't think a once-a-year core update there is asking too much.
Beyond that, it saddens me that we're all duplicating effort here. I know a lot is my fault, I don't work well with others and merge their changes, as I'm picky about my codebase.
But like I said, it is what it is. I'm thankful we're at least sharing changes. I'd much rather have bsnes-classic and the occasional hires math fix or SuperFX timing improvement that we both have to commit, than not have any of it.
byuu wrote:
You have the one project where I completely understand why you're stuck on the version number you are. It needs such a massive amount of hooks into the core, and the core is constantly changed and cleaned up by myself. Bizhawk comes in second place, but I don't think a once-a-year core update there is asking too much.
Even so, didn't the later "laevateinn" debugger provide basically the same interface with a less outdated version of the actual emulator? It was probably just a bit of nearsightedness on my part, honestly.
byuu wrote:
Beyond that, it saddens me that we're all duplicating effort here. I know a lot is my fault, I don't work well with others and merge their changes, as I'm picky about my codebase.
Duplication of effort notwithstanding, I think the fact that all these forks still have quite a lot of your work in common is a pretty serious net positive (could you imagine a world with twenty more closed-source snes9x forks instead?
)
Either way, I'm glad to be able to involve myself in working on something that a handful of people find useful. I hope I'm not somehow considered to be doing harm to the scene because of that, even if some things about my project aren't as close to the state of the art as they ought to be...
calima wrote:
Wait, do I read it right that bsnes-plus does not require the annoying cartridge folder?
I'd call it less a matter of "doesn't require"; higan doesn't necessarily "require" them either since you can just import regular ROMs most of the time and let the rest be handled behind the scenes. The real problem (which I absolutely agree is a problem) is that bsnes-classic/plus don't even
support cartridge folders.
Revenant wrote:
calima wrote:
Wait, do I read it right that bsnes-plus does not require the annoying cartridge folder?
I'd call it less a matter of "doesn't require"; higan doesn't necessarily "require" them either since you can just import regular ROMs most of the time and let the rest be handled behind the scenes. The real problem (which I absolutely agree is a problem) is that bsnes-classic/plus don't even
support cartridge folders.
Handling it behind the scenes still copies the ROMs there. Which I don't like, both because it's ugly and because it puts the cart folders in my home dir, which is on a different disk to where I keep ROMs, and has much less space free.
calima wrote:
Revenant wrote:
calima wrote:
Wait, do I read it right that bsnes-plus does not require the annoying cartridge folder?
I'd call it less a matter of "doesn't require"; higan doesn't necessarily "require" them either since you can just import regular ROMs most of the time and let the rest be handled behind the scenes. The real problem (which I absolutely agree is a problem) is that bsnes-classic/plus don't even
support cartridge folders.
Handling it behind the scenes still copies the ROMs there. Which I don't like, both because it's ugly and because it puts the cart folders in my home dir, which is on a different disk to where I keep ROMs, and has much less space free.
Just create a symlink if it's really that much.
Or change the library path. You aren't required to have the library inside your home directory. In my case, I have an entire hard drive partition set aside just for higan's library, because I also put games for other systems such as the GameCube and PlayStation 2 in there.
Of course, this doesn't help if you store your ROMs on read-only media such as CD-R disks. In that case, you should just use byuu's upcoming bsnes revival or my Qt-based fork.
=========================================
AWJ, I'm sorry if you think I'm “browbeating” you; you're obviously free to do whatever you want. Just as I'm free to write a replacement emulator and do everything in my power to make sure ROM hackers never feel obligated to write hacked-up manifests for the severely outdated XML-based standard ever again.
I also want to focus on replicating bsnes-plus's debugging features, eventually. Just like bsnes-classic, bsnes-plus also uses XML manifests, so it too is on my radar.
For now, I'm using the tentative name “bsnes-mcfly”, a name that represents traveling into the future. This name won't become final until higan and bsnes v107 are released.
It's pointless to debate the game folders thing any longer.
bsnes v107 won't require game folders, and won't import them behind the scenes. It's all done in memory. You can also control the paths for saves, states, cheats, patches, etc. Your games can be SFC or SMC, with or without copier headers, inside ZIP archives or not, with firmware appended or not, pre-patched or not.
If that's what you want, that's why I'm making it. I do sincerely hope you'll like it, but if not, Snes9X is an outstanding emulator these days as well.
I probably will like it, though I also need a debugger. Nowadays my SNES playing is on an Everdrive and emulators are only for dev, but in any case I appreciate the new direction.
I just made my first release under a new name. For now, I'm using “bsnes-mcfly”, but the name won't become final until higan and bsnes v107 are released.
The release thread is on
byuu's message board.
AWJ has made his choice final and will continue pushing for XML manifests and fighting against BML manifests, so I'll have to push ever harder to make my project into something anyone will choose over bsnes v073 or bsnes-classic.
If anyone has any reason whatsoever to switch back to bsnes v073 or AWJ's bsnes-classic after trying my emulator, please let me know. I will rectify that situation as soon as I can. Even if I have to convert Olympian Magic into a library so that XML manifests are converted internally to BML. It's either this, or XML manifests continue existing forevermore, just like ZSNES and Internet Explorer 6.
That said, if byuu's upcoming bsnes revival is enough for you, I encourage you to use it instead because of its choice to use the much more stable hiro toolkit instead of the bug's nest that is Qt. It's only people switching back to bsnes v073 or bsnes-classic that I'm worried about.
byuu wrote:
It's pointless to debate the game folders thing any longer.
bsnes v107 won't require game folders, and won't import them behind the scenes. It's all done in memory. You can also control the paths for saves, states, cheats, patches, etc. Your games can be SFC or SMC, with or without copier headers, inside ZIP archives or not, with firmware appended or not, pre-patched or not.
If that's what you want, that's why I'm making it. I do sincerely hope you'll like it, but if not, Snes9X is an outstanding emulator these days as well.
That sounds like exactly what I am looking for, although I have a couple of questions.
From what I heard, you are developing a new multithreaded scanline-based PPU renderer for bsnes. Will it be possible to use the more accurate, slower PPU renderer that is already in higan? And will the new bsnes continue to (optionally) support existing game folders and manifests for those that do like them?
Quote:
Will it be possible to use the more accurate, slower PPU renderer that is already in higan?
Yes, but I'm worried about shipping it pre-compiled. A problem when I had the profiles, was everyone only ever specified the system requirements of the accuracy profile. I don't want people to think of bsnes as (horrifyingly) slow. The idea is to differentiate the two products. bsnes is more than twice as fast as higan currently.
Quote:
And will the new bsnes continue to (optionally) support existing game folders and manifests for those that do like them?
It doesn't yet support it, but I intend to do so.
byuu wrote:
* advanced CPU overclocking (it's too tightly bound to the other components like the PPU)
How about being able to adjust the memory timings? I'm especially curious about the effect of RAM accesses only taking 6 master cycles.
If you want to alter the CPU's timing to permanent FastROM, edit higan/sfc/cpu/memory.cpp and compile from source (for Windows users, I recommend either TDM-GCC or MinGW-w64). That feature wasn't in bsnes v073, and the only reason it was in ZSNES was as a workaround for the many timing issues that plagued the emulator.
Hmmm, I think it would be better to announce new releases in as many places as I can instead of only releasing them on byuu's message board. With that said...
bsnes-mcfly v106r05 has been released.
This version of the Qt GUI has the following features:
- Compatibility with higan v106r34, including v107-style gamepaks (cartridge folders)
- Low-level emulation of the HG51BS169 (Cx4) and ARM6 (ST018)
- Newer MSU1 features such as audio resume
- Concatenated firmware in game ROMs, as well as a firmware/ fallback directory.
- No cartridge folders are created within the user's home directory. It is all handled in memory.
- Database lookup of SNES and Super Famicom cartridges. The database is embedded right into the application along with heuristics for games not in it, so icarus is not required.
- Compressed archives: Zip, GZip, BZip2
- Support for Zip and GZip available without having to use snesreader
- BZip2 support by Rob Landley under the zero-clause BSD license
- Copier extensions: SMC, SWC, FIG, UFO, GD3, GD7, DX2, MGD, MGH, 048, 058, 068, 078, BIN, USA, EUR, JPN, AUS
- All of these extensions are also available for use with BS Memory and Sufami Turbo slot cartridges.
- Optional 512-byte copier header
- WASAPI and ASIO audio drivers
- Exclusive mode for Direct3D and WASAPI
- Separate directories for save RAM, save states, and other mutable game files
- Turbo buttons
- asciiPad (more advanced turbo switches with Off, Turbo, and Auto settings)
- Simultaneous up/down and left/right (must be enabled in the settings file)
- I needed to use a really evil compilation trick to enable this feature without modifying higan directly.
- IPS, UPS, and BPS soft-patching
- IPS and UPS patches are applied before removing the FuSoYa header, and BPS patches are applied after.
- Movie recording and playback
- Cheats
- Pro Action Replay (AAAAAA:DD, AAAAAADD, AAAAAA/DD)
- Can omit the address/data separator or use a colon, when higan mandates the use of an equals sign.
- Game Genie (GGGG-GGGG)
- Will remember that you inputted the code in Game Genie format instead of converting it to Pro Action Replay on save and reload.
- Cheat search (works only on WRAM at 7e-7f:0000-ffff)
- Software filters
- 2xSaI, Super 2xSaI, Super Eagle
- HQ2x, LQ2x, Scale2x
- Pixellate2x
- blargg's snes_ntsc (with 15-bit precision instead of 13-bit precision)
- Phosphor3x (was included in some bsnes v08x versions)
- OpenGL shaders
- Curvature and Edge Detection from higan v092
- HQ2x, Pixellate, Scale2x
- HDR-TV, Watercolor (these were marked “Archive” in bsnes v083 and not restored when bsnes v085 went back to XML from BML)
- Sepia (converted from Direct3D)
- Only 1 copy of nall for the overall project instead of a separate copy each for bsnes, snesfilter, and snesreader
Features missing from bsnes v073:
- Compressed archives: Z (compress), 7z, RAR, JMA
- Most of these have restrictive licenses. Need to think carefully on how to implement them...
- Selecting one of multiple files in a single Zip archive
- snes_ntsc configuration dialog
- Because the palette size was increased from 32768 to 524288, changing a setting causes bsnes-mcfly to freeze while it recreates the palette. This dialog had to go.
- Binding the Pause/Break key to an input
- Direct3D shaders
- As consolation, the Sepia shader was converted to OpenGL
I said this before, and I'll say it again:
If anyone has any reason whatsoever to switch back to bsnes v073 or bsnes-classic after trying my emulator, please let me know. I will rectify that situation as soon as I can. My goal is to kill XML manifests, and anything that causes bsnes-classic to remain popular is also something that keeps XML manifests alive, so I will take any legal means necessary to stop that from happening.
hex_usr wrote:
I said this before, and I'll say it again: [b]If anyone has any reason whatsoever to switch back to bsnes v073 or bsnes-classic after trying my emulator, please let me know.
Does this include -plus?
hex_usr wrote:
Hmmm, I think it would be better to announce new releases in as many places as I can instead of only releasing them on byuu's message board.
/r/emulation/
I do plan on beginning to replace bsnes-plus once higan v107 is released. I could start earlier, and years of maintaining a laevateinn fork have taught me that it is doable, but I want to wait until higan and bsnes v107 are released first.
Right now, I want to migrate to the recently-released higan v106r40, which
compiles both the accurate and fast profiles into a single executable without a performance penalty and allows automatic selection of profiles when running Air Strike Patrol and Koushien 2. After that, I will try and make it run the English version of Tengai Makyou Zero (whose team put actual effort into hacking up an XML manifest and drove me to create bsnes-mcfly in the first place, as I've said before).
As for the suggestion to post to Reddit,
didn't someone post about it already? Is there any danger of my post being removed because of redundancy?
hex_usr wrote:
Is there any danger of my post being removed because of redundancy?
Well, I don't think so. Especially if it's a status update.
nevermind tested on 3 other systems seems unique to my office desk setup.
Could you possibly add the ability to set config full screen resolution?
Helpful on some setups.
I think there are some fullscreen config options already, aren't there? You will have to use keyboard shortcuts though, especially if you use Direct3D's exclusive mode.
By default, pressing Shift+6 (not the keypad, the horizontal number key) will set either square pixels or 8:7 rectangular pixels* depending on whether you have Correct Aspect Ratio turned on. Either way, this leaves black bars on the left and right sides of the screen. I don't mind the black bars at all, but I heard they really bother a few users, so...
Pressing Shift+7 will completely ignore the console's native pixel aspect ratio and horizontally stretch the emulated screen to fill the entire monitor. I find this horizontal stretching to be really ugly, but it does cover up the black bars if that's what you truly want.
Pressing Shift+8 will chop off parts of the top and bottom to minimize horizontal stretching while still filling the entire screen. Depending on the game, this could chop off important info. In Super Mario World, the HUD is still visible, but a small portion of the top is cut off.
You can also press Shift+1, Shift+2, Shift+3, Shift+4, or Shift+5 to set the resolution to 256×239, 512×478, 768×717, 1024×956, or 1280×1195 respectively. Depending on your monitor, not only will this create black bars on the left and right sides, it also creates them on the top and bottom as well.
*Important note: 8:7 is the pixel aspect ratio of the SNES, or the ratio of a single pixel's width to its height. The overall display aspect ratio is 64:49 when displaying 224 scanlines and 2048:1673 when displaying 239 scanlines. The display aspect ratio of the NES (240 scanlines) is 128:105.
================================
As for Mega Man X2 not loading the first time and loading the second time instead (yes, I saw your pre-edit post): I cannot reproduce this bug, and it sounds like the other computers you tried cannot reproduce it either? In the current development version on my computer, I made a slight change to the load/unload program code to cover up a possible source of bugs, which will appear in bsnes-mcfly v106r06. If it does come up again, be sure to check the firmware/ folder and make sure that cx4.data.rom is intact.
However, the preferred form is to concatenate this firmware directly to the game ROM and make a 1,575,936 byte ROM that still works in ZSNES and Snes9x. If you do that, bsnes-mcfly (and bsnes v107) will ignore the firmware/ folder and use the concatenated ROM instead, which is currently the only way to use a custom firmware if one gets created in the future. byuu has been pushing for concatenated firmware for many years now, yet No-Intro has strongly opposed it for fear of not being able to distinguish where the main program ROM ends and where the firmware begins. Something that icarus proves is a piece of cake, no harder than detecting copier headers.
hex_usr wrote:
I think there are some fullscreen config options already, aren't there? You will have to use keyboard shortcuts though, especially if you use Direct3D's exclusive mode.
By default, pressing Shift+6 (not the keypad, the horizontal number key) will set either square pixels or 8:7 rectangular pixels* depending on whether you have Correct Aspect Ratio turned on. Either way, this leaves black bars on the left and right sides of the screen. I don't mind the black bars at all, but I heard they really bother a few users, so...
Pressing Shift+7 will completely ignore the console's native pixel aspect ratio and horizontally stretch the emulated screen to fill the entire monitor. I find this horizontal stretching to be really ugly, but it does cover up the black bars if that's what you truly want.
Pressing Shift+8 will chop off parts of the top and bottom to minimize horizontal stretching while still filling the entire screen. Depending on the game, this could chop off important info. In Super Mario World, the HUD is still visible, but a small portion of the top is cut off.
You can also press Shift+1, Shift+2, Shift+3, Shift+4, or Shift+5 to set the resolution to 256×239, 512×478, 768×717, 1024×956, or 1280×1195 respectively. Depending on your monitor, not only will this create black bars on the left and right sides, it also creates them on the top and bottom as well.
*Important note: 8:7 is the pixel aspect ratio of the SNES, or the ratio of a single pixel's width to its height. The overall display aspect ratio is 64:49 when displaying 224 scanlines and 2048:1673 when displaying 239 scanlines. The display aspect ratio of the NES (240 scanlines) is 128:105.
================================
As for Mega Man X2 not loading the first time and loading the second time instead (yes, I saw your pre-edit post): I cannot reproduce this bug, and it sounds like the other computers you tried cannot reproduce it either? In the current development version on my computer, I made a slight change to the load/unload program code to cover up a possible source of bugs, which will appear in bsnes-mcfly v106r06. If it does come up again, be sure to check the firmware/ folder and make sure that cx4.data.rom is intact.
However, the preferred form is to concatenate this firmware directly to the game ROM and make a 1,575,936 byte ROM that still works in ZSNES and Snes9x. If you do that, bsnes-mcfly (and bsnes v107) will ignore the firmware/ folder and use the concatenated ROM instead, which is currently the only way to use a custom firmware if one gets created in the future. byuu has been pushing for concatenated firmware for many years now, yet No-Intro has strongly opposed it for fear of not being able to distinguish where the main program ROM ends and where the firmware begins. Something that icarus proves is a piece of cake, no harder than detecting copier headers.
Thanks for the info on the shortcuts.
Im really not sure what was causing my mega man x2 issue. It was only happening on a specific system which drove me mad. I have since formatted and reinstalled windows and fresh drivers system needed it anyway. Can no longer produce that problem.
I currently am not using concatenate roms. But I have the proper verified by crc files in the firmware folder.
Been playing with this emulator alot since discovering it. No issues. On my media center I run the accuracy core however I tried the other 2 modes as well.
I am really really liking bsnes-mcfly thank you for this.
To address No-Intro's concerns: Are there any licensed Super NES ROMs that aren't a power of two bytes in size, 3/4 of a power of two, or 5/8 of a power of two? As far as I'm aware, these are the only sizes for which the internal header checksum algorithm is well defined.
I don't think any licensed SNES games not matching those sizes exist.
The most common firmware (DSP1) is 8192 bytes long, the largest firmware (ST018) is 163,840 bytes long, the smallest firmware (Super Game Boy boot ROM) is 256 bytes long, and the second-smallest firmware (Cx4) is 3072 bytes long. No firmware is exactly the same size as the copier header (512 bytes). All the same, I think it would be best to not consider a ROM that has both a copier header and a coprocessor firmware to be valid. It is best to treat them as mutually exclusive, and if a ROM has both a copier header and a coprocessor firmware, the emulator should reject it.
I will note that, for byuu's preservation database, byuu will check the last 256 kilobytes (2 megabits) of a ROM and chop off the last 128 kilobytes (1 megabit) if they match the preceding 128 kilobytes exactly. Spectre, for example, is 1 megabyte long, but it can be truncated to 896 kilobytes and then mirrored back to 1 megabyte to produce exactly the same ROM. It is the 896-kilobyte version that byuu catalogues. He does this in order to guard against cartridges that, for example, store 4 megabytes when only 3 megabytes are needed. Spectre has no coprocessor, and certainly none with firmware. I don't think any of the firmware games fit this criterion though.
hex_usr wrote:
*Important note: 8:7 is the pixel aspect ratio of the SNES, or the ratio of a single pixel's width to its height.
Vaguely off-topic: Do you handle PAL PAR also?
Yes, actually; the PAL pixel aspect ratio is 2,950,000:2,128,137, or approximately 11:8. You'll need to press Shift+P to activate it, and Shift+N to switch back to the NTSC aspect ratio; bsnes v073 did not automatically select the aspect ratio based on the cartridge region, so neither does bsnes-mcfly.
hex_usr wrote:
Yes, actually; the PAL pixel aspect ratio is 2,950,000:2,128,137, or approximately 11:8. You'll need to press Shift+P to activate it, and Shift+N to switch back to the NTSC aspect ratio; bsnes v073 did not automatically select the aspect ratio based on the cartridge region, so neither does bsnes-mcfly.
Would it be possible to include a readme with the next release that lists all the shortcuts and stuff?
Useful for those of us that dont know bsnes well.
All of the keyboard shortcuts in bsnes-mcfly are customizable. Open the Configuration Settings window and select the Input tab to see which hotkeys are available, and configure them as you please. Unfortunately, Windows users will not be able to use the Pause/Break key.
Some very basic documentation is available by selecting Help/Documentation..., but it does not list any hotkeys. I'd like to build on that documentation in the future.
hex_usr wrote:
All of the keyboard shortcuts in bsnes-mcfly are customizable. Open the Configuration Settings window and select the Input tab to see which hotkeys are available, and configure them as you please. Unfortunately, Windows users will not be able to use the Pause/Break key.
Some very basic documentation is available by selecting Help/Documentation..., but it does not list any hotkeys. I'd like to build on that documentation in the future.
ok nice thanks.
back to my original topic can you add ability to define screen resolution?
Let say I leave my media center at 4k desktop res but want bsnes to use lets say 640 x 480 x 32bit
snes9x does what i mean so does mednafen even when using bsnes core.
Im not neaning resolution of render i am meaning define pc screen res mode.
Oh, that's what you meant? To shrink the PC resolution down instead of stretching the SNES image up?
I don't think that will be easy. I deliberately designed bsnes-mcfly to use as much of byuu's code as possible by converting the Qt-based UI for compatibility with the most current higan/bsnes version instead of having it stagnate at v073 for all time.
Unlike some people.Which means that bsnes-mcfly includes nall (general header library) and ruby (video/audio/input abstraction layer) as dependencies, completely unchanged from the equivalent higan version. To implement your feature request, I would have to modify ruby, and I have deliberately prohibited myself from modifying these dependencies in any way.
You should
ask byuu if he will implement this feature in his upcoming bsnes revival. I don't know if he will agree or not, but if he does, I will be able to pull in any changes he makes to ruby in order to add the feature to bsnes-mcfly.
hex_usr wrote:
Oh, that's what you meant? To shrink the PC resolution down instead of stretching the SNES image up?
I don't think that will be easy. I deliberately designed bsnes-mcfly to use as much of byuu's code as possible by converting the Qt-based UI for compatibility with the most current higan/bsnes version instead of having it stagnate at v073 for all time.
Unlike some people.Which means that bsnes-mcfly includes nall (general header library) and ruby (video/audio/input abstraction layer) as dependencies, completely unchanged from the equivalent higan version. To implement your feature request, I would have to modify ruby, and I have deliberately prohibited myself from modifying these dependencies in any way.
You should
ask byuu if he will implement this feature in his upcoming bsnes revival. I don't know if he will agree or not, but if he does, I will be able to pull in any changes he makes to ruby in order to add the feature to bsnes-mcfly.
Yes exactly what I mean. This allows the computer to have less overhead in emulating.
if desktop = 3840 x 2160 and emulator runs at same it will take so much power however if user can define launch in a lower system resolution it will take less power for same emulation. bsnes/higan being very power hungry would benefit greatly from this.
easy test run bsnes with pc set to highest resolution you and and try at lowest resolution you can.
This very purpose is why most emulators are written to allow this change.
I imagine byuu will eventually see this post. I believe he is currently on vacation in Japan.
I thought you could implement the resolution swap at gui level. I fully understand not wanting to alter the higan code and agree with that thought.
oh and also thanks for bsnes-mcfly
Stretching the SNES resolution to a higher one is usually not done by the CPU but by the graphics card, which shouldn't have any problem with that (unless it's a cheap one from the 90's).
creaothceann wrote:
Stretching the SNES resolution to a higher one is usually not done by the CPU but by the graphics card, which shouldn't have any problem with that (unless it's a cheap one from the 90's).
The system I did my tests on was with an i5-4570 cpu and Nvidia GTX 1050 (and yes I consider it low end but hi end enough to emulate snes)
Not high end, not exactly SHIT.
Monitoring resources I see a difference. Also directly related this effects operating temp.
Instead of putting a pointless comment do some testing.
Hopefully your reply wasn't typed on a $299 Walmart AMD powered laptop.
007, what profile do you use?
I managed to reproduce that bug that prevents Mega Man X2 from running the first time and requires reloading the game in order to work. It happens regardless of whether the Cx4 firmware is concatenated directly to the program ROM or read from the firmware/ directory. But I could only get the bug to happen with the performance profile. With the accuracy and compatibility profiles, Mega Man X2 loads the first time, all the time.
The only reason I found this bug when I did is that I usually don't use the performance profile (I use the compatibility profile for general gaming), but I had it active in order to test some massive code changes in the PPU and SMP that should increase speed without harming what little accuracy is left (if I did it right). I haven't narrowed down the cause of the bug yet though.
hex_usr wrote:
007, what profile do you use?
I managed to reproduce that bug that prevents Mega Man X2 from running the first time and requires reloading the game in order to work. It happens regardless of whether the Cx4 firmware is concatenated directly to the program ROM or read from the firmware/ directory. But I could only get the bug to happen with the performance profile. With the accuracy and compatibility profiles, Mega Man X2 loads the first time, all the time.
The only reason I found this bug when I did is that I usually don't use the performance profile (I use the compatibility profile for general gaming), but I had it active in order to test some massive code changes in the PPU and SMP that should increase speed without harming what little accuracy is left (if I did it right). I haven't narrowed down the cause of the bug yet though.
I been using accuracy profile. Explains why the problem vanished lol.
Just tested and you are correct in performance profile problem is there always and in the other 2 profiles its not.
When I first bumped into the problem I would of been in performance mode.
I was doing my own little test I was comparing your performance profile vs the new bsnes that byuu is working on seeing if one required more power than the other.
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 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.
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?
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.
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.
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:
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.
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:
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.
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.
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
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.
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.
Quote:
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!
Quote:
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.
Quote:
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.
Quote:
By using the lowercase x on those 2 lines instead of the uppercase X, the PPU effectively performs the horizontal mirroring twice.
Thanks!
Quote:
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.
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?
Quote:
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.
Quote:
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.
Quote:
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.
Quote:
Does anyone have any thoughts to contribute?
Do whatever you want. Keep the profile or don't, I don't mind either way.
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.
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.
Quote:
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.
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.
byuu wrote:
Quote:
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.
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.
Quote:
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.
Quote:
But anyway I love this new emulator.
Happy to hear, thanks!
We'll see how video filters go in time. No promises yet.
Quote:
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 ...
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.
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.
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.)
@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.
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.
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)
(((Width - 1) / 3 + 1) × 7) ⋅ Height
- NTSC-RF
- NTSC-Composite
- NTSC-SVideo
- NTSC-RGB
768 ⋅ (Height×3)
512×480
“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.
@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.
byuu wrote:
Quote:
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.
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.
He did not say "Please stop developing your software".
He said "Please stop being abrasive"
hex_usr wrote:
I am not going to throw all that hard work out just because my efforts hurt your feelings.
That isn't remotely what I said.
Quote:
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.
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.
Quote:
Why did you add debugging functionality to the performance profile, anyway?
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.
[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]
hex_lusr wrote:
[Deleted toxicity. It is unfortunate that phpBB3 lacks revision history. Contact a moderator if you need to know what was written here. --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.
hex_usr wrote:
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.
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.
hex_usr wrote:
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.
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.
007 wrote:
this same bullshit was why I stopped folling the snes scene. Thanks for showing me nothing has changed.
bunch of assholes. Im out.
"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.
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.
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.
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.
hex_usr wrote:
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.
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:
Code:
#if defined(PLATFORM_WINDOWS)
DEVMODE devMode;
EnumDisplaySettings(nullptr, ENUM_CURRENT_SETTINGS, &devMode);
devMode.dmSize = sizeof(DEVMODE);
devMode.dmPelsWidth = 640;
devMode.dmPelsHeight = 480;
devMode.dmFields = DM_PELSWIDTH | DM_PELSHEIGHT;
ChangeDisplaySettings(&devMode, CDS_FULLSCREEN);
#endif
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).
hex_usr wrote:
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).
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.
007 wrote:
Just trying r09 I see you brought compatibility legacy back.
I didn't intend on bringing Compatibility: Legacy back; my compilation script compiles it automatically, and I simply forgot to delete the DLL for it before packaging this version. I intend on retiring Compatibility: Legacy and replacing it with Compatibility: OpenMP, so if anyone wants to test both profiles and see if there's a game that Legacy supports and not OpenMP, this will be the last chance to do so. And if you do have a bug report for Compatibility: OpenMP, be sure to forward it to byuu, as this profile comes directly from the bsnes WIPs.
EDIT: Since this post started a new page, I added a link to
bsnes-mcfly v106r09 for convenience. the release notes are on the previous page.
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/ ... y-v106-can’t-fullscreen/
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.
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??
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.
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:
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.
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.
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 :/
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:
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:
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...
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
@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.
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 buildbsnes v106r52 Windows buildList 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.
@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.
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.
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 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.
hex_usr wrote:
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.
I dont know how to compile this but if you want me to compile on my Haswell and submit/test Im willing to learn.
Thanks for another build.
@hex_usr
so tested this. cant make it crash anymore. even switching filters. build feels very stable.
I have one suggestion, the description of compatible core states to switch to accuracy for the few problematic games. however the new bsnes core this is has no known problematic games. maybe reword along the lines to switch to accuracy if you believe you found a incompatible game.
007 wrote:
I dont know how to compile this but if you want me to compile on my Haswell and submit/test Im willing to learn.
You will need
MinGW-w64 and the
source code to Qt 5; Visual Studio probably won't work because it has historically been incompatible with the C++14 standard that higan and bsnes use. I use Qt 5.10.1, but bsnes-mcfly has been tested as far back as Qt 5.7.
Once you have extracted both of those, make sure you have the directories
“<qt-install-dir>\qtbase” “<qt-install-dir>\qtbase\bin” and “<mingw-install-dir>\bin” in your PATH. If you install MinGW-w64 with an installer, the latter directory should be automatically handled for you.
Then, navigate to where you installed bsnes-mcfly's source code and run cc.bat. I designed cc.bat to run the “pause” command if it detects that compilation failed, so it won't automatically close and prevent you from seeing any important error messages like most batch files do. cc.bat will compile the Accuracy and Compatibility profiles into bsnes\out\bsnes-mcfly.exe, so if you want the Performance profile, you'll have to go into the command prompt and run “mingw32-make profile=performance” from within the bsnes\ directory.
007 wrote:
even switching filters
Crashing on switching filters was an unrelated bug, caused by me being overzealous with optimizations and rendering directly into ruby's video buffer instead of using an intermediate buffer. I think I fixed that already in bsnes-mcfly v106r10, didn't I?
007 wrote:
I have one suggestion, the description of compatible core states to switch to accuracy for the few problematic games.
The “few problematic games” mentioned in that description refer to Air Strike Patrol, which requires the Accuracy profile's PPU in order to draw a shadow under your plane, and Koushien 2 and Rendering Ranger R2, which both require cycle-based DSP timing (the Compatibility profile uses sample-based timing).
Go ahead and try to run those games in the Compatibility profile; you'll find that Air Strike Patrol will slow down the emulator to just barely faster than the Accuracy profile, because bsnes-mcfly looks up the internal ROM header's name (“AIR STRIKE PATROL” or “DESERT FIGHTER” for the NTSC-J region) and automatically activates the Accuracy profile's PPU, though it still uses the Compatibility profile's sample-based DSP timing. Similarly, Koushien 2 and Rendering Ranger R2 will automatically activate the cycle-based DSP timing while still using the OpenMP-based PPU in the Compatibility profile. The speed hit will be pretty minor compared to Air Strike Patrol.Note that the Performance profile does not automatically activate parts of other profiles like this. If you run Air Strike Patrol in the Performance profile, the plane shadow will be invisible.
I could name those games directly in the description, but would that be legally safe? Could Nintendo or SETA find a reason to sue me for mentioning which games won't work with certain features? I already have a tooltip for the Double VRAM option that mentions that Yoshi's Island will look like a garbled mess with 128 KB VRAM (hover your mouse cursor over the checkbox to see it), and I'm a little iffy on that, too.
EDIT: Corrected the PATH for Qt.
EDIT 2: Whoops, forgot that I disabled automatic profile switching because of a crashing bug.
@hex_usr
am going to try and compile now.
I re read the descriptions makes sense to leave as is.
Ill come back on with what I compile. Using i5-4570.
Oops, I knew I forgot something. I had hoped that you could just use the precompiled Qt DLLs that I included in the ZIP download, and maybe that's technically true, but you still need to have moc (Qt's meta object compiler) and rcc (Qt's resource compiler) in order to compile bsnes-mcfly. And in order to get those, you'll need to compile Qt yourself.
And the PATH isn't supposed to point to “<qt-install-dir>\qtbase”, it's supposed to point to “<qt-install-dir>\qtbase\bin” instead. Sorry about that.
Did you read the included README.txt by any chance? I included directions for compiling Qt in there. I'll include the relevant section below:
If you wish to compile Qt yourself on Windows, you will need MinGW-w64 SEH.
TDM-GCC has not been updated since 2015 and will not work.
Open qtbase/mkspecs/win32-g++/qmake.conf and change the following properties:
Code:
QMAKE_LINK = $${CROSS_COMPILE}g++ -static-libgcc -static-libstdc++
QMAKE_LINK_C = $${CROSS_COMPILE}gcc -static-libgcc -static-libstdc++
Navigate to Qt's root directory and run the following command with no line breaks:
Code:
configure -prefix %CD%\qtbase -release -opensource -confirm-license -nomake tests -nomake examples -no-opengl -no-zlib -skip qt3d -skip activeqt -skip qtandroidextras -skip qtcanvas3d -skip qtcharts -skip qtconnectivity -skip qtdatavis3d -skip qtgamepad -skip qtlocation -skip qtmacextras -skip qtnetworkauth -skip qtpurchasing -skip qtserialbus -skip qtspeech -skip qtwebglplugin -skip qtx11extras
Navigate to qtbase/ and run “mingw32-make”. This can take a while. You can optionally add a “-j#” option, where # is the number of simultaneous compilation jobs. The number of CPU cores you have minus 1 is a good number.
When it is done, you will find some DLLs in the directory where you installed Qt's source. Here's where each one needs to be copied:
- qtbase/lib/Qt5Core.dll → <bsnes-mcfly>/
- qtbase/lib/Qt5Gui.dll → <bsnes-mcfly>/
- qtbase/lib/Qt5Widgets.dll → <bsnes-mcfly>/
- qtbase/plugins/platforms/qwindows.dll → <bsnes-mcfly>/platforms/
- qtbase/plugins/styles/qwindowsvistastyle.dll → <bsnes-mcfly>/styles/
If you need to recompile Qt, run “mingw32-make distclean -j#” first. (substitute # with the number of simultaneous jobs)
hex_usr wrote:
Go ahead and try to run those games in the Compatibility profile; you'll find that Air Strike Patrol will slow down the emulator to just barely faster than the Accuracy profile, because bsnes-mcfly looks up the internal ROM header's name (“AIR STRIKE PATROL” or “DESERT FIGHTER” for the NTSC-J region) and automatically activates the Accuracy profile's PPU, though it still uses the Compatibility profile's sample-based DSP timing. Similarly, Koushien 2 and Rendering Ranger R2 will automatically activate the cycle-based DSP timing while still using the OpenMP-based PPU in the Compatibility profile. The speed hit will be pretty minor compared to Air Strike Patrol.
Oops, I forgot... I disabled automatic profile switching because of a crashing bug. When enabled, if you load a game in the Accuracy profile, and then load the same game again in the Compatibility profile without a full restart first, bsnes-mcfly will crash.
This bug affects the official bsnes as well (using the Fast PPU checkbox), and it even affects the latest v106r56 WIP release. I know byuu previously attempted a fix to work around the 1-game lag in calculating the save state size, but I guess it doesn't work as expected.
The PPU and DSP are selected within SuperFamicom::System::load(), and serializeInit() is also called within the same function. But in bsnes, hackCompatibility() is called after emulator->load() has already been called... which means that it doesn't even have the intended effect and will run Air Strike Patrol with no visible shadow.
I had a fix for the save state size's 1-game lag, but I dropped it because I thought byuu's fix would work. This was what I used:
sfc/system/system.cpp
Code:
auto System::load(Emulator::Interface* interface) -> bool {
//...
bus.reset();
if(!cartridge.load()) return false;
hacks.fastPPU = settings.fastPPU;
hacks.fastDSP = settings.fastDSP;
if(!cpu.load(system)) return false;
if(!smp.load(system)) return false;
if(!ppu.load(system)) return false;
if(!dsp.load(system)) return false;
//...
serializeInit();
this->interface = interface;
return information.loaded = true;
}
I loaded the cartridge first. This was required in order to read the ROM header. Then I set the hack settings, and loaded the PPU and DSP afterwards.
...but even that doesn't fix this crash bug now. And GDB doesn't help, it just says that the crash happened in a Windows DLL.
I would enjoy being able to load things like the DSP-1 tech demo and Bad Apple demo by Ladida from plain .sfc files. If it's not too difficult to implement in bsnes-mcfly, that is.
If the ROM header is not properly formatted, bsnes-mcfly won't be able to figure out that a DSP1 is required. The same is true of the official bsnes, and when importing the ROM in icarus for use in higan. You will need to either supply a manifest, or edit the ROM in a hex editor.
If you choose to supply a manifest, place the manifest in the same directory as the ROM and name it the same as the ROM but with the “.bml” extension. Here's the manifest:
Code:
game
sha256: 42ff54a03c2c8f42daa1d4e342464abde303df4e90dcf17173f36ec01702e887
label: DSP1 Prototype
name: DSP1 Prototype
//serial: SN-10
region: NTSC
revision: 1.0
//board: SHVC-2Q5B-03
board: NEC-LOROM
memory
type: ROM
size: 0x20000
content: Program
memory
type: ROM
size: 0x1800
content: Program
manufacturer: NEC
architecture: uPD7725
identifier: DSP1
memory
type: ROM
size: 0x800
content: Data
manufacturer: NEC
architecture: uPD7725
identifier: DSP1
memory
type: RAM
size: 0x200
content: Data
manufacturer: NEC
architecture: uPD7725
identifier: DSP1
volatile
If you choose the hex editor route, you will need to go to $7FB0, and overwrite the 48 bytes of FF that you find there with the following:
Code:
30 30 44 53 50 31 00 00 00 00 00 00 00 00 00 00
44 53 50 31 20 50 72 6F 74 6F 74 79 70 65 20 20
20 20 20 20 20 20 03 07 00 0E 33 00 12 07 ED F8
Also, I don't think I need to say this, but make sure you have the DSP1 firmware in little endian format. The preferred form is to concatenate the firmware directly to the end of the ROM that uses it, but you can also put it in the firmware/ directory where bsnes-mcfly is installed. Even though the performance profile has high-level emulation of the DSP1, it requires the firmware in order to validate the DSP program. I made it that way in order to not relieve any pressure on No-Intro to bundle the firmwares with the ROMs that use them.
As for Bad Apple, bsnes-mcfly does recognize that the ROM is an ExHiROM, but unfortunately, the Board database that is borrowed from higan does not define a board for ExHiROM without any cartridge RAM (both Tales of Phantasia and Daikaijuu Monogatari II have cartridge RAM), so Bad Apple won't work without a manifest, or unless you edit the header to indicate the presence of cartridge RAM. For the latter, change byte $40FFD8 from 0x00 to 0x05.
You could ask byuu to add an entry to the Boards database for ExHiROM without RAM, but because no commercial game was ever released using it, I doubt he will agree to add it for you.
ROM hacks / PD ROMs are exactly what manifest support was created for (ROMs shouldn't have to be edited to make them work in certain emulators).
angrylion asked about loading both games as “plain .sfc files”. I just provided an option that would avoid creating manifests, because those are primarily associated with cartridge folders, and I can't assume that angrylion has no opposition to placing a manifest right next to the ROM, even if it technically doesn't need to be in a .sfc folder.
...oh, but Bad Apple works in bsnes v073 without a manifest, doesn't it? Dang, I don't really like the idea, but I did say that I would “take any legal means to replace bsnes v073”, so...
I will create a supplemental boards database in order to fill in the gaps that byuu has left in his boards database. Its first entry will be “EXHIROM” without a “-RAM” suffix, so that Bad Apple will work without the need to edit the ROM or supply a manifest. Unfortunately, there is no way to also support the DSP1 prototype in the same way. Even if the firmware is concatenated, it's either supply a manifest, or edit the ROM. I don't think bsnes v073 supports it manfest-free either (although bsnes v072 and earlier have high-level emulation, bsnes-classic was not forked from those versions), so I shouldn't have to worry about that one, at least.
Annoying reminder: bsnes-mcfly tries to compete with bsnes v073 and bsnes-classic. It does not try to compete with the official bsnes v107. If you are satisfied with bsnes v107, I recommend that you continue to use it so that you don't have to suffer the bug's nest that is Qt.
angrylion wrote:
I would enjoy being able to load things like the DSP-1 tech demo and Bad Apple demo by Ladida from plain .sfc files. If it's not too difficult to implement in bsnes-mcfly, that is.
Do you really expect us to maintain databases of mappings for every quirky unlicensed game out there?
Frankly, it's severely pushing it that I'm even including one for the Tengai Makyou Zero fan translation and Powerfest '94 / Campus Challenge '92.
Quote:
ROM hacks / PD ROMs are exactly what manifest support was created for (ROMs shouldn't have to be edited to make them work in certain emulators).
I just really wish we could have created a standard that wouldn't be subject to constant change.
But even if it were set in stone, it's not a standard if only my emulator supports it.
byuu wrote:
Do you really expect us to maintain databases of mappings for every quirky unlicensed game out there?
How many are there, like 20? The NES is the only system that has a lot of this.
So on one hand, we have a 20-entry unl db. On the other, we have fights and drama and regret and confusion over legacy formats and their tendency to persist, as featured in this thread.
FitzRoy wrote:
How many are there, like 20?
I'd guess it's a bit more...
creaothceann wrote:
I guess it's a bit more...
Are we even talking about the same thing? 99.9% of unl games work with heuristics. I thought we were talking about mappings that go outside the boundaries of licensed boards.
I want to try and compile this, but I have no idea.
Can someone give me a quick tutorial on makefiles?
As I understand, they only work natively on Linux. For Windows, I need something like CygWin?
The procedure for compiling bsnes-mcfly on Windows is a bit involved, and I don't think a beginner should attempt it right away.
For starters, have you ever compiled higan before? You won't need Cygwin; Cygwin is designed to make the POSIX API available for use on Windows, which higan was carefully designed to not need. Instead, you need to use
MinGW-w64 (I think it will work on 32-bit Windows as well, but I'm not sure). Make sure that it is in your PATH. If you use an installer, the PATH should be handled automatically for you.
In case you're wondering, the reason why Visual Studio won't work is that it lags behind on support for C++14, which is used heavily by higan and bsnes, and bsnes-mcfly with them.
Once you have MinGW-w64, attempt to compile
higan v106 or
bsnes v106r57. To do this, navigate into the higan/ directory where there's a file named “GNUmakefile”, then type “mingw32-make”. If you're compiling bsnes, you may need to type “mingw32-make target=bsnes”. If all goes well, you should have higan.exe or bsnes.exe in the higan/out/ directory.
In order to compile bsnes-mcfly, you will additionally need
the source code of Qt 5.10.1. When you have that, follow the instructions in bsnes-mcfly's included README.txt file to compile Qt (also available in
this post).
================================
Regarding unlicensed game compatibility, I have only this to say:
bsnes-mcfly's new unlicensed boards database will fill in the gaps left behind by byuu's licensed boards database, but
only for games that bsnes v073 supported. This includes Bad Apple (ExHiROM without RAM).
It does not include the DSP1 tech demo (malformed header). bsnes v073 was the first version of bsnes to incorporate low-level emulation of the uPD7725 (DSP1, Dungeon Master, SD Gundam GX, Top Gear 3000), so already a cartridge folder would have been required (bsnes v073 did not support concatenated firmware like the upcoming bsnes v107). But even beyond that, the DSP1 tech demo does not have a properly formatted header, so in the absence of a manifest, bsnes v073 and bsnes v072 (the last HLE version) both assume a LoROM without a uPD7725.
I suppose I could force detection of a DSP1 if the firmware is concatenated by taking an SHA256 hash of the last 8192 bytes of the ROM (and therefore allow combination coprocessors such as DSP1+Super FX), but the DSP1 tech demo was not released with a concatenated firmware, so I doubt that would solve anything.
Quote:
I suppose I could force detection of a DSP1 if the firmware is concatenated by taking an SHA256 hash of the last 8192 bytes of the ROM (and therefore allow combination coprocessors such as DSP1+Super FX)
Clever, but yet another caveat is that ... it's ideal if we're gonna do LLE to allow for uPD7725 code that
isn't official DSP1,1B,2,3,4 code. So it could be literally anything there.
You could go off of the file size mask like how I detect it icarus now ... but yeah, the problem is nobody ships the firmware with the games, so it doesn't do anyone any good. For this case, if you really want to support it, I'd probably just add the game's SHA256 sum to an unlicensed database.
bsnes-mcfly v106r12 has been released. This version is based on bsnes v106r57, but with WASAPI dynamic rate control from the 20180808 meta-WIP (the XAudio2 dynamic rate control was omitted because it is currently broken).
It is now possible to input cheat codes in AAAAAA=DD and AAAAAA=CC?DD formats (A: address, D: data, C: comparison), which are supported by the official bsnes and higan. This is in addition to the older AAAAAADD and AAAAAA:DD formats that bsnes v073 supported, the AAAAAA/DD and AAAAAA/CC/DD formats that higan v092 supported, and the Game Genie format. And because bsnes-mcfly
retains whether a cheat code is in Game Genie format and does not convert it to Pro Action Replay format, it can't use the same cheats.bml filename as the official bsnes, at least for cartridge folders.
For now, I'm putting them inside <cartridge-folder>/bsnes-mcfly/cheats.bml, but in the long term, I want to use bsnes's <cartridge-folder>/cheats.bml if and only if every cheat code is compatible with bsnes. If even 1 cheat code is in Game Genie format or uses a colon instead of an equals sign, then the entire cheat file is incompatible with bsnes and needs to use a different path.
Unfortunately, I did not give that same consideration to standalone ROMs. If you assign a separate cheats path, make it different from the cheats path used by Snes9x and the official bsnes if you have those emulators. I hope to fix this in the future. Maybe I'll use the .gg extension if even 1 cheat code is in Game Genie format, and the existing .cht extension if every last one of them is in Pro Action Replay format.
In addition, an unofficial boards database has been added that supplements byuu's official boards database. Currently, its only entry is “EXHIROM”, which refers to ExHiROM without any RAM. This will allow Ladida's Bad Apple tech demo to work as a standalone ROM with no need for a manifest.
As for the DSP1 tech demo, seeing as bsnes v073 did not support it either, I'm not particularly motivated to come up with a way to support it manifest-free. I could register it in an unlicensed games database much like the boards database, but the licensed database includes coprocessor firmwares in its SHA256 hashes, and I will want to do the same for the unlicensed one. And if I do that, I will need to create a shim database for coprocessor games that maps each SHA256 hash without a firmware to a hash with a firmware, and that's going to be rather tedious to do, especially when all the licensed games work with heuristics.
One last thing: the Super Scope and Justifier are now usable with every profile, whereas previously they were usable exclusively in the Accuracy profile and would freak out with the other profiles (this bug also affects the bsnes WIPs). This is because the cursors were optimized for a resolution of 512×480, and if the resolution was 256×240, all your shots would be misaligned. Now, whenever the resolution is 256×240, a 16×16 cursor design is used instead of the 32×32 cursor design in higan and bsnes (in fact, it's the same one from higan v094, except for the color), and the cursor's X and Y coördinates are no longer multiplied by 2. When the resolution is 512×480, the cursor's coördinates are once again multiplied by 2, and the 32×32 design is used. In the cases of 512×240 or 256×480 resolution, the 32×32 cursor design is used (resulting in an oblong shape), but only the X or Y coördinate will be multiplied depending on the resolution.
With that, the list of evil hacks to make bsnes-mcfly more like bsnes v073 are the following:
- sfc/controller/gamepad/gamepad.cpp: support simultaneous up+down and left+right (enforcing the prohibition of opposing directions is now handled by the GUI instead of the emulator core)
- sfc/controller/justifier/justifier.cpp: smart cursor alignment/size for Fast PPU
- sfc/controller/super-multitap/super-multitap.cpp: support simultaneous up+down and left+right
- sfc/controller/super-scope/super-scope.cpp: smart cursor alignment/size for Fast PPU
- sfc/dsp/misc.cpp: support muting individual channels (used to be unavailable in the Accuracy profile, but the fact that Compatibility uses the same DSP as Accuracy makes that difficult to enforce)
- sfc/interface/configuration.cpp: interface for toggling PPU layers and DSP channels carefully designed to not save on exit
- sfc/ppu-fast/background.cpp: support hiding individual layers in Modes 0-6 (Mode 7 currently not supported)
- sfc/ppu-fast/io.cpp: support for 128 KB VRAM (can be disabled with a compile-time flag)
- sfc/ppu-fast/object.cpp: support hiding individual layers
- sfc/ppu-fast/ppu.cpp: frameskip support, set to 9 when using Fast Forward
- sfc/system/system.cpp: load cartridge before PPU and DSP so that automatic profile selection can work for Air Strike Patrol without making the expected save state size lag behind 1 game load
EDIT: Including a comparison value doesn't make a cheat incompatible with bsnes v107, what was I thinking? Comparison values were added in higan v092 at the same time as the slash syntax (AAAAAA/CC/DD), and they were made universally available to all emulator cores that support cheats (the ones that have 8-bit data buses, which excludes the Mega Drive and Game Boy Advance), not just the Famicom and Game Boy.
Seeing as bsnes became feature-frozen with v106r57, I have decided that it's time to put
bsnes-mcfly on GitLab. You can now see exactly how I went about porting the Qt GUI from each version following v073. It was a long ride, so make sure you have some free time before you go looking.
Good Morning. Thanks for the emulator and let's get into the problem.
I have msu1 games that run on SD2SNES, Snes9x 1.56.2, bsnes-plus and bsnes-classic, but they do not run on the new version of byuu bsnes 106r44 nor on the bsnes-mcfly 106r12 version. Is there a way to explain what has changed or what should I do to convert the game format? Is the new format incompatible with SD2SNES and Snes9x? Thank you!
If you have your MSU1 game as a gamepak (cartridge folder), then I should warn you that the format has changed in order to accommodate the
Voicer-kun. Now, the MSU1 data track is stored inside the msu1/ subdirectory with the name “data.rom”, and the audio tracks have also been moved into that same subdirectory.
- game.sfc/
- msu1/
- data.rom
- track-1.pcm
- track-2.pcm
- track-3.pcm
- ...
- program.rom
- save.ram
If you have your MSU1 game in SD2SNES format (where every file shares the same name and are differentiated only by extension), then
it should work just fine, but I'll check and make sure.
EDIT: Oh, I see what went wrong. For the SD2SNES format, bsnes and bsnes-mcfly mistakenly omit the hyphen-minus from the audio track names, so they expect a game in this format:
- Secret of Mana.sfc (program ROM)
- Secret of Mana.srm (save RAM)
- Secret of Mana.msu (MSU1 data track)
- Secret of Mana1.pcm (MSU1 audio track 1)
- Secret of Mana2.pcm (MSU1 audio track 2)
- Secret of Mana3.pcm (MSU1 audio track 3)
- ...
Notice how there's no hyphen-minus separating the game name from the track ID? That's what you would need to rename your audio tracks if you want the game to work with bsnes v106r59 or bsnes-mcfly v106r12.
However, I believe this to be a bug, and that the audio track names are officially meant to have hyphen-minuses separating the game name from the audio track ID (because this is what bsnes v073 and the SD2SNES both expect). I'll fix this in the next release of bsnes-mcfly, but byuu needs to be informed of this right away, before he releases bsnes v107.
While I'm at it, I will also mention that bsnes's Super Game Boy support has a bug where an RTC time uses the “.srm” extension instead of “.rtc” like it should be. That means that if you play Pokémon Gold or Pokémon Silver (Pokémon Crystal won't run on the Super Game Boy), your save file will be overwritten by the file meant to keep track of the date and time.
Code:
manifest.bml
mmx2_msu1-1.pcm
mmx2_msu1-10.pcm
mmx2_msu1-11.pcm
mmx2_msu1-12.pcm
mmx2_msu1-13.pcm
mmx2_msu1-14.pcm
mmx2_msu1-15.pcm
mmx2_msu1-16.pcm
mmx2_msu1-17.pcm
mmx2_msu1-18.pcm
mmx2_msu1-19.pcm
mmx2_msu1-2.pcm
mmx2_msu1-20.pcm
mmx2_msu1-21.pcm
mmx2_msu1-22.pcm
mmx2_msu1-23.pcm
mmx2_msu1-24.pcm
mmx2_msu1-26.pcm
mmx2_msu1-27.pcm
mmx2_msu1-28.pcm
mmx2_msu1-29.pcm
mmx2_msu1-3.pcm
mmx2_msu1-30.pcm
mmx2_msu1-31.pcm
mmx2_msu1-32.pcm
mmx2_msu1-4.pcm
mmx2_msu1-5.pcm
mmx2_msu1-6.pcm
mmx2_msu1-7.pcm
mmx2_msu1-8.pcm
mmx2_msu1-9.pcm
mmx2_msu1.bsz
mmx2_msu1.msu
mmx2_msu1.sfc
mmx2_msu1.xml
This is the list of original files I have. All in one folder.
Do I just need to rename the rom/.sfc and songs/.pcm files, then re-organize into new directories, or I need to convert/create new files? Thank you so much.
“manifest.bml” “mmx2_msu1.xml”
Oh, shoot! You have a higan v106 and bsnes v073 hybrid manifest! higan/bsnes v107 will be the first version to truly sever all backwards compatibility with bsnes v073 because its manifest format does not allow filename overrides. So unless this ROM hack does something tricky with the memory map, I think you should convert your game to the SD2SNES format. Unless you want to use higan instead of bsnes, which requires cartridge folders.
I don't think you need to create any new files, but you might be able to safely delete manifest.bml and mmx2_msu1.xml, unless that ROM hack makes some elaborate change like adding save RAM to this Cx4-enabled game.
This release came earlier than I expected, but here's
bsnes-mcfly v106r13. It is based on higan/bsnes v106r59. This version fixes the MSU1 audio track name bug, so you don't have to rename any files with this version.
If you want to use bsnes v106r59 instead, you'll have to rename mmx2_msu1.sfc to “mmx2_msu1-.sfc” and mmx2_msu1.msu to “mmx2_msu1-.msu”. The reason I want you to rename those 2 files only instead of the audio tracks is so that if and when bsnes fixes the audio track name bug, you can easily revert back to “mmx2_msu1.sfc” and “mmx2_msu1.sfc” without the hassle of renaming every single audio track.
Thank you so much. I tested here by renaming only 2 files, including the hyphen and made a script to remove the hyphen from the songs, and both methods worked.
Although NOT NECESSARY, I will share the script I did, which may help people with similar problems.
Code:
@echo off
cls
echo.
echo. This code is for BATCH file only!
echo.
SETLOCAL EnableDelayedExpansion
::for %%F in (%cd%\*.pcm) do (
:: For Test
for %%F in (*.pcm) do (
echo.0:%%F
set "_newname=%%F"
set "_newname=!_newname:-=!"
echo.1:!_newname!
)
:: Uncomment For Use
REM for %%F in (*.pcm) do (
REM set "_newname=%%F"
REM set "_newname=!_newname:-=!"
REM ren "%%F" "!_newname!"
REM )
ENDLOCAL
:: The command below renames folders
:: for /D %%D in (%cd%\*) do ren "%%D" "2_ %%~nxD"
:: see: https://ss64.com/nt/for.html
:: see: https://ss64.com/nt/syntax-replace.html
:: see: https://ss64.com/nt/setlocal.html
timeout /nobreak /t 5
exit /b
Anyway, the new version bsnes-mcfly_v106r13 does NOT need any changes, and my msu1 is playing loud! Keep Rocking!
once again, thank you very much, cheers!
This is a Higan general question:
Where can I find the enums used in the "settings.bml" that represent the keyboard-keys/input?
The format is "0x1/0/35". I specifically need the source of the last number.
Thank you.
The keyboard IDs vary slightly for each operating system and input driver, so a given ID from one operating system will correspond to a different key on other operating systems. The one constant is that every input driver uses 0 for the Escape key.
For Windows, the keyboard IDs can be found in ruby/input/keyboard/rawinput.cpp. Assuming that 35 is a decimal number, I believe it would be the letter A.
Fair warning: byuu is attempting to add accurate emulation of the SA1's bus conflicts to higan/bsnes. In v106r60, internal code changes have caused a 2% speed hit to the Fast PPU+DSP with bus conflicts disabled when playing non-SA1 games, and a 9% speed hit when playing SA1 games. These same speed hits will also affect bsnes-mcfly's Compatibility profile. The Accuracy profile will also be similarly affected, I'm sure, and if bus conflicts are enabled, the speed hit will be around 51% (I'll leave them disabled for now).
I will make sure the Performance profile does not take a speed hit when merging this change. Although I wish I could remove the Performance profile outright...
bsnes-mcfly v106r14 bsnes-mcfly v106r14b has been released. It is based on higan/bsnes v106r63.
The “bsnes-accuracy.dll” file has been renamed to “bsnes-accuracy-compatibility.dll” to clarify that both the Accuracy and Compatibility profiles are included in the same file. That filename is 32 characters long, so if anyone has a problem getting it to work, tell me and I'll revert the change.
bsnes-mcfly now outputs .cht files that are compatible with bsnes v107 and Snes9x 1.56, so you shouldn't lose your cheats as you switch between emulators. However, in order to maintain feature parity with bsnes v073, bsnes-mcfly needs to remember which cheats are Game Genie cheats and which ones are not, so it outputs an additional cheat file with the .gg extension in order to keep track. In a gamepak (cartridge folder), the bsnes-compatible cheat file is stored in cheats.bml in the root of the folder, while the Game Genie cheat file is stored in bsnes-mcfly/cheats.bml.
One flaw of this method is that, if you change any cheats in bsnes or Snes9x, those changes won't be visible in bsnes-mcfly, and they will be erased when bsnes-mcfly is closed. I'll need to refine this method in the future.
Now, there's something I want to discuss regarding audio:
bsnes v073 did not perform any pitch correction when using Fast Forward. That meant that the audio's pitch would increase with its tempo instead of spending additional CPU time trying to retain the pitch. bsnes-mcfly tries to recreate the effect in order to look and sound like bsnes v073, but it's not perfect. I have to temporarily set the frequency in Emulator::audio to double the normal rate (48000Hz to 96000Hz for example) when using Fast Forward.
But when I do, the XAudio 2.1 driver crashes. I don't know why that is or why the other Windows audio drivers are not also affected, so unfortunately, I need to disable this code when using XAudio 2.1. Furthermore, this makes it impossible to adjust the emulation speed to Slowest, Slow, Fast, or Fastest. The problem is vexing, as this represents a lost bsnes v073 feature when using the XAudio 2.1 driver.
EDIT: Replaced defective v106r14, which would crash for first-time users but not upgrading users, with v106r14b.
uVSthem identified a crashing bug that only affected first-time users who never used any previous bsnes-mcfly version: a regression meant that the program would not define a default profile and would thus only work if the user already used a previous bsnes-mcfly version.
bsnes-mcfly v106r14b has been released in order to fix this regression.
Thanks for this wonderful emulator!
Would it be possible to implement/add this:
Color emulation
Simulates the way a console’s display device differs from modern computer monitor’s colour reproduction. In particular, it simulates the slightly-different gamma correction used by the Super Famicom.
Blur emulation
Simulates the limited horizontal resolution of standard-definition TVs by blurring together horizontally-adjacent pixels. Games like Jurassic Park for the Super Famicom depend on this to emulate a transparency effect.
I have checked but could not find these options in the emulator, I know standalone higan and the RetroArch higan core got these options.
Would be really cool to have these options in the future.
Thanks in advance!
@hex_usr
This is to demonstrate what I mean by Color emulation and Blur emulation:
Default output (like we see it roughly in bsnes/higan)
Color emulation ON with Blur emulation OFF
Color emulation ON with Blur emulation ON
Those rocks looks so much better with Blur emulation ON.
The whole point of bsnes-mcfly is to recreate the Qt GUI from bsnes v073 as accurately as possible while making it work with the most recent higan/bsnes versions. As such, Color Emulation won't be found in the drop-down menus like in higan.
The Color Emulation option is called “Simulate NTSC TV gamma ramp” in bsnes-mcfly because that's what bsnes v073 called it. It's in the Configuration Settings dialog box, Video tab.
And because I'm trying to recreate the Qt GUI, I didn't expose a way to configure Blur Emulation, instead setting it to Off automatically.
I just replaced my computer last week and am still setting up a non-Windows OS (my new computer has Windows 10, which I am loath to use for longer than absolutely necessary), so while I can make a change to add the Blur Emulation option, it's going to be difficult for me to provide precompiled Windows builds in the future.
Thank you very much @hex_usr
I appreciate that the Blurring could be implemented at least, I wish you good luck with your new PC.
hex_usr wrote:
When you have that, follow the instructions in bsnes-mcfly's included README.txt file to compile Qt (also available in this post).
From README.txt:
How to compile bsnes-mcfly on Windows:
Is this still intended to be buildable on and for X11/Linux? On a PC running Xubuntu 18.04, I enabled source code repositories, did
sudo apt build-dep higan, and then tried to adapt the instructions in cc.bat:
Code:
$ cd bsnes
$ make
rcc target-qt/resource/resource.qrc -o obj/resource.rcc
rcc: could not exec '/usr/lib/x86_64-linux-gnu/qt4/bin/rcc': No such file or directory
target-qt/GNUmakefile:58: recipe for target 'obj/resource.rcc' failed
make: *** [obj/resource.rcc] Error 1
Your error log mentions Qt4. bsnes-mcfly is meant to be compiled with Qt5.
I moved to Qt5 at King Of Chaos's request. When I did, I just about migrated the entire GUI source from Qt-style event handlers to C++11's lambdas, which are only supported by Qt5. At this time, only 1 source file still requires moc (Qt's meta object compiler) to compile, and it would be nice if I could eliminate moc as a dependency entirely.
rcc is Qt's resource compiler. I use it to embed higan's Super Famicom games database, among other things. It would be trivial to convert those to
sourcery, byuu's cross-platform resource compiler, but 2 of the resources are Qt-specific images used to style form controls, and I'm not sure how I could get those to work while using sourcery.
...I think it would be a shame to have to revert all those lambdas to Qt-style handlers, especially considering that the underlying higan code requires C++14 and will soon require C++17.
I thought sudo apt build-dep higan would have added everything needed to build it. How would I go about finding which libqt5*-dev packages are needed to build this? Or do I need to set up building Qt 4 applications and building Qt 5 applications in separate chroots so that Make can find the appropriate version of rcc?
I don't use Xubuntu. This laptop I'm using has Funtoo Linux installed on it (its package manager is “emerge”), and I'm trying to get FreeBSD set up on my main computer so that I don't have to use a systemd-based distro. Sorry, but I think you'll have to look elsewhere for Xubuntu help.
higan's GUI toolkit is hiro, which is a cross-platform wrapper around Windows, GTK, Qt4 (with Qt5 support coming soon), and Cocoa (macOS).
Is bsnes-mcfly still getting updates?
I posted this on
byuu's message board, but in case you didn't see it;
hex_usr wrote:
In general, each update to bsnes-mcfly comes shortly after an update to higan, so as long as higan is on hiatus, so too is bsnes-mcfly.
It's not like I don't want to work on bsnes-mcfly. I want to add a debugger so that it could compete with bsnes-plus in addition to bsnes-classic, but I promised myself that I wouldn't do so until higan/bsnes v107 was released.
Okies, that thanks for the reply.
What's up with byuu? He moved to Japan, stopped twitting and now is closing the forums?
...and? Some people just want peace and quiet in their lives. :-)
Yeah, moving to Japan is the best place to be isolated! (why am I even saying that
)
He's tweetting about his rig these days though? Freebsd setting he's trying to figure out for his threadripper or something.
byuu is suffering from FreeBSD lag spikes on his new custom-built computer, which are severe enough to stop higan development if they aren't fixed (“I am dead in the water here until this is fixed”). He is offering a $250+ bounty to anyone who sends him a working fix.
Full details on byuu's mesage board.
Sorry, I was a bit desperate due to the cost of the new server. I found a sysctl workaround for a scheduling issue, and created a kernel patch for an ACPI shutdown issue, so barring more nasty future surprises, I'm good at this point. But thank you to everyone who helped!
Quote:
What's up with byuu?
Taking a break from social media. All is going well.
Seem your in a great space right now.
Best of luck to you.
Hey all,
While exploring and working on various miscellaneous SNES-related interests of mine, I found bsnes-mcfly. Now, I switched to bsnes-mcfly from higan due it's increased usability, but it still was lacking a few features I was really hoping for. Thankfully, hex_usr kindly put all the code on GitLab so I was able to fork the repo and just do it myself.
It's been a couple months and I've since found the time to refine my improvements and modifications into a form a bit more suitable for a pull request. Unfortunately, I'm finding that hex_usr's repository (or maybe it's GitLab) doesn't seem set up for pull request interaction I'm familiar with on GitHub; further, byuu recently removed the forums from his site, and I don't really have a way to contact him to send a message. As such, I've decided to announce my changes here, hoping it may be useful to a wider audience. I hope to start a discussion about seeing these changes -- or at least the concepts -- migrate back into bsnes-mcfly and, perhaps even more appropriately, bsnes/higan as well.
Right, enough build-up. Here's the short list of what I've done:
[1]- Compilation fixes for Qt 5.11+. Resolve paintEngine warnings. Fixes the segfaulting that occurs when program window is closed.
[2]- Add UI setting to control GPU pipeline flushing. This noticeably reduced input latency for me (maximal reduction would be a 1 frame period, or ~16ms. I'd guess this yields probably a ~10ms reduction on average?)
[3]- Add UI settings to adjust rewind history buffer: both length and maximal granularity, in snapshot quantity and number of frames, respectively.
[4]- Major performance improvement: eliminating OpenMP's ridiculous thrashing. I've repeatedly profiled & measured a significant drop in CPU usage. Before: anywhere from 5-9 CPU cores each @ 60-80%. After: 1 CPU core @ 80%.
[5]- Add support for adaptive VSync intervals. This helps avoid a client delay while swapping buffers if the VSync time slice is ever missed.
[6]- Add support for GLsync token injection into render pipeline. (Further reduced CPU usage for me, from 1 core @ 80% down to a comfortable ~40%).
[7]- Fix build issues arising from LTO optimizer. Enable LTO for builds.
More on [5]: More or less, it's approximately that VSync continues normally until FPS < 60, at which point the GPU will let the buffer swap clock slide and return to the CPU immediately, just as if VSync were disabled. Basically, you only perform VSync while you have performance to spare
More on [6]: The primitive way to do this, as was already in higan actually, is to glFinish(). This change adds support for GL_ARB_sync (conveniently made mandatory as of GL 3.2), so the CPU can poll instead of block. So, I still process window & input events, but just stop the emulator core cycles. Once the fence is triggered, emulator clocking resumes. Some gfx stacks are kind of dumb, apparently (
*cough* my nVidia Quaddro
*cough*) and use a heavy, resilient spinlock for glFinish. This naturally drives CPU usage up a bit as well.
More on [7]: byuu refers to what is actually WPO (whole-program optimization) via a setting called 'LTO'. WPO and LTO are similar, but not the same. Both are working, but with LTO being more aggressive, I had to adjust the linker settings a bit so a 'more suitable' ELF header would be generated and it could run properly. I'll need a bit more thought and more testing before I feel comfortable committing the LTO bit though.
So, give it a try if you'd like. Here's the repository:
ar/bsnes-mcfly.
hex_usr: there are 7 ar/* branches of mine that have all my changes grouped by general feature/change. I derived my master branch simply by taking yours and rebasing all the ar/* branches atop of it.
byuu: I'd like to recommend by VSync and GLsync token changes for use in bsnes/higan. Oh, and definitely the OpenMP pruning, as well. I haven't compared bsnes-mcfly to your HEAD, but those primitives were...not suitable for the places and patterns they were in (or, my CPU is
very fast or
very different, heh). One or two could possibly be made more suitable with some loop rewrites, but from what I saw, OpenMP isn't exactly going to be the right tool for the job.
Thoughts welcome.
Thanks!
I was just thinking about how to bring bsnes-mcfly back. I noticed
the disappearance of byuu's message board too, and I'm a little worried about the future of higan.
The problem is, I don't have Windows 7 anymore, so producing Windows builds is not trivial. I suppose I could use Windows 10 to make bsnes-mcfly builds... but I'm afraid. We all know how little Microsoft care about privacy, even going so far to
make Visual Studio inject telemetry into compiled builds. It's a good thing I use MinGW instead of Visual Studio, but I still can't shake the fear that any Windows build I make could be compromised.
If anyone using Windows 7 or Windows 8.1 wants to test, I've made
bsnes-mcfly v106r14c. This version is based on higan v106r88, which is the last version available on
the semi-official higan Git repository. It adds the much-coveted Blur Emulation option (called "Simulate hires blurring") to support Kirby's Dream Land 3's use of pseudo-512 for transparency, among other things.
hex_usr wrote:
producing Windows builds is not trivial
VM?
creaothceann wrote:
hex_usr wrote:
producing Windows builds is not trivial
VM?
RAM to have the host and guest loaded at once costs money, VMware costs money if you need any of the features that aren't in the GPL version of VirtualBox, and Windows to run in a VM costs money to activate and phones home. Technically, one can
use unactivated Windows and the PUEL version of VirtualBox[1] without charge, but legally I wouldn't recommend it.
I have yet to play with
sudo apt install mingw-w64, but it could be an option.
[1] The VirtualBox Extension Pack may be used without charge under a license that forbids anything resembling commercial use. A skilled lawyer might convince a judge that even fulfilling bug bounties on free software or taking subscriptions on Buy Me a Coffee or Patreon could be considered commercial use. Licenses for commercial use of the Extension Pack start at $5000 for 100 seats. Oracle appears to have made a business decision not to cater to home businesses or other small businesses.
Windows Vista and newer will unactivate themselves at some point when they cannot phone home. There's software around that mimics the licensing server and allows things to work but it is still legally troublesome.
Quote:
I don't really have a way to contact him to send a message.
The changes you've made sound interesting, but it's going to be quite difficult to search through your rep to find changes to a fork of code I haven't touched in over eight years ... if you have a single diff file of your changes, I can try to go through them for things that are still relevant to v107. Of course, I'd be happy with patches against the official Gitlab as well ^-^;
I'm most interested in the OpenMP stuff. I'm guessing you're referring to the nall::image usage? OpenMP indeed has some truly intensive overhead, and most of the time it's not worth using it at all. I've been thinking of stripping it out from there, but I've also been planning to rewrite nall::image to a new class that takes template type parameters for each channel. The extreme support in nall::image for format conversion massively cripples its performance. 99% of the time one just wants ARGB8888, and 1% of the time 30-bit or 64-bit images.
I wish I knew how much it was OpenMP not being good versus threading not being good ... because the new bsnes v107's scanline-based renderer gets hamstrung a lot in its multi-threading, and I am not sure if it's worth writing per-platform threading primitives to replace OpenMP or not.
I ... don't know what you're referring to with these GLsync tokens, sorry. Also no familiarity with GL_ARB_sync, but it sounds interesting!
Quote:
WPO and LTO are similar, but not the same.
What are the differences, if I may ask? I always expect WPO/LTO to help dramatically with all the base CPU classes and their virtualization, and indeed if I just manually merge the processor/ classes with their respective CPUs (duplicating the code in many places), I do get 3-5% program speed-ups, but -fwhole-program and -flto optimizations do not seem to convey any benefits in practice. The code runs at the same speed, or slower, and now linking is a nightmare.
Quote:
I noticed the disappearance of byuu's message board too, and I'm a little worried about the future of higan.
higan will be fine. I don't need a forum, and I really shouldn't have a Twitter account either. The less I post online, the better it is for everyone.
byuu wrote:
The changes you've made sound interesting, but it's going to be quite difficult to search through your rep to find changes to a fork of code I haven't touched in over eight years ... if you have a single diff file of your changes, I can try to go through them for things that are still relevant to v107. Of course, I'd be happy with patches against the official Gitlab as well ^-^;
hex_usr has been keeping bsnes-mcfly approximately up-to-date with your repository, so the changes are actually on top of v106.88, which is your current master version at the time I'm writing this. I can set up a GitLab mirror and make some pull requests, if that'd be easier for you?
byuu wrote:
I'm most interested in the OpenMP stuff. I'm guessing you're referring to the nall::image usage? OpenMP indeed has some truly intensive overhead, and most of the time it's not worth using it at all. I've been thinking of stripping it out from there, but I've also been planning to rewrite nall::image to a new class that takes template type parameters for each channel. The extreme support in nall::image for format conversion massively cripples its performance. 99% of the time one just wants ARGB8888, and 1% of the time 30-bit or 64-bit images.
I wish I knew how much it was OpenMP not being good versus threading not being good ... because the new bsnes v107's scanline-based renderer gets hamstrung a lot in its multi-threading, and I am not sure if it's worth writing per-platform threading primitives to replace OpenMP or not.
I profiled the emulator to identify the bottlenecks rather than seek out parallelization opportunities, which would be an interesting exercise. What I can say is that OpenMP is a great way to realize performance gain for the right workloads, but the amount of work has to be larger than the synchronization impact. The best workloads would be some O(n^2) or O(n^3) reduction, e.g. a matrix multiply. On modern Intel CPUs, usually N needs to be ~o(1 000) or ~o(10 000) before there's any noticeable improvement; using small kernels over the 240 scanlines is not going to be a good candidate.
However, there could be gain from running multiple workers in parallel from the top level -- the per-platform threading would achieve this type of parallelization. You can probably get away with not writing these yourself though. With newer implementations of OpenMP you can have a top-level #pragma omp parallel with #pragma omp task, and there's also a #pragma for simd. The latter suggests GCC should try extra hard to use any on-board SIMD units, but it may not be any better than simply adding -ftree-vectorize to -O3.
byuu wrote:
What are the differences, if I may ask? I always expect WPO/LTO to help dramatically with all the base CPU classes and their virtualization, and indeed if I just manually merge the processor/ classes with their respective CPUs (duplicating the code in many places), I do get 3-5% program speed-ups, but -fwhole-program and -flto optimizations do not seem to convey any benefits in practice. The code runs at the same speed, or slower, and now linking is a nightmare.
LTO and WPO both deal mostly with the IPA/IPO optimizer pass (inter-procedural analysis/inter-procedural optimization), particularly with regards to references to external functions or variables. Usually, the compiler can't be sure that a reference will be to the same piece of code that gets run at runtime. This is usually due to unresolved dynamic references in other .so files, satisfied by the OS loader at initial runtime, but can also arise with global variables and anything considered common data (i.e. anything in .comdat).
WPO has the optimizer pretend that each translation unit's (TU's) references to external functions or variables be treated as static for purposes of optimizing that TU. Note with C++, inline functions are marked as COMDAT, and at link, each file's COMDAT gets merged into the global .comdat. At link, WPO will localize whichever inline functions it is able.
LTO takes this idea a step further, by having GCC dump bytecode of its internal GIMPLE tree into the object file. When doing the final link, all GIMPLE trees are merged into a single representation of the union of all TUs, and a final IPA pass is performed on this whole tree (this is equivalent to everything having been compiled as one single TU). The side effect is that IPA gets performed for references between files, inlined functions can be more widely applied, and the COMDAT contents can be more aggressively reduced. The downside to LTO is that it's inherently serial and so can be slower (but can be sped up by -fno-fat-lto-objects), and it needs more RAM than would WPO to store everything during link. One typically wouldn't use either WPO or LTO if creating a .so file. And, one cannot use both flags simultaneously.
How effective WPO and LTO usually depends fairly heavily on symbol visibility. By default, all symbols have global, or 'default' visiblity. Usually one either marks symbols designed not to be exported as 'hidden' via a function/variable __attribute__((visibility("hidden"))), or defaults to hidden with -fvisibility=hidden and explicitly export a public API as __attribute__((visibility("default"))). higan is a bit unconventional as to how it's laid out, but adding something like -fvisibility-inlines-hidden might be a good way to test any effects.
Edit: Also, for what it's worth, my experience is that -O2 outperforms -O3 for most workloads. I'm not a fan of -O3, as it tends to inflate code size enough to the point it reduces the effectiveness of the BTB caching HW in the CPU.
---
I've committed my previously-mentioned fix for bsnes-higan's LTO linking issues to my fork. I had to modify the symbols in the OpenGL binding code as the global symbols weren't actually being globalized correctly (the ELF header had STT_FUNC where STT_OBJECT should've been used).
Quote:
I can set up a GitLab mirror and make some pull requests, if that'd be easier for you?
A set of "diff -ru" patches with descriptions of how and why you're changing things thrown onto eg pastebin would be easiest, if you don't mind. Otherwise, however you want to do it, I'll make it work.
Quote:
using small kernels over the 240 scanlines is not going to be a good candidate.
Each scanline is demanding enough that in practice, it is. Not nearly by as much as we'd like, of course. But it definitely helps with the PPU.
Quote:
it may not be any better than simply adding -ftree-vectorize to -O3.
It may be better now, but -ftree-vectorize has caused me no end of pain in the past. It broke a lot of valid code in very subtle ways.
...
Thanks for the WPO/LTO explanation. I'm still the biggest fan of PGO, but it's just way too much work per release. Especially when I have 21 cores to exercise now.
I'll give -O2 a try again. -O3 has always been faster, and if that's still the case, I'll stick with -O3.
byuu wrote:
I'm still the biggest fan of PGO, but it's just way too much work per release. Especially when I have 21 cores to exercise now.
Automated playback of an input file (e.g. a TAS) could help there.
byuu wrote:
I'll give -O2 a try again. -O3 has always been faster, and if that's still the case, I'll stick with -O3.
Might get different results on different CPUs, e.g. AMD vs Intel.
Sure thing, byuu. I'll gather together the raw changes with corresponding descriptions. I just need to explore whether it can apply (relatively) cleanly atop higan's master, just in case any bsnes-mcfly-specific stuff has worked its way in there over time.
Quote:
Each scanline is demanding enough that in practice, it is. Not nearly by as much as we'd like, of course. But it definitely helps with the PPU.
...
It may be better now, but -ftree-vectorize has caused me no end of pain in the past. It broke a lot of valid code in very subtle ways.
I wanted to let you know I spent some time looking into your claims and whether it'd be possible to better leverage OpenMP, and have some findings to shoot your way. Kindly forgive any of my misassumptions below, as I don't know the details of the render procedure or how the various modes should work -- I'm an ARM firmware/architecture expert in my day job, but know jack all about the SNES.
Oh, just to get this out of the way first: I tried -ftree-vectorize and, while the code seemed to still run okay, it did absolutely destroy performance akin to what you claimed. Well, it's not a default optimizer flag for a reason. There are a few patterns it can really help for, but I guess I didn't realize how few those were.
Now, I saw two immediate possibilities for scanline rendering parallelization:
[1] Parallelize the renderBackground and renderWindow functions, ensuring a sync barrier prior to continuing to update the above/below window data. Unfortunately, this would require an intelligent map reduction in order to respect the various priority values (a z-order, I think). This is feasible for a GPU compute unit, but is more trouble than it's worth for a CPU or general compute platform.
[2] Parallelize at the top level, which I believe is flush(). The PPU memory points to different locations for each scanline, so there's no interdependence and all state is effectively thread-local. Unfortunately, even using OpenMP only for >16 scanlines with a 2-thread limit and various scheduling hints to loosen constraints, CPU usage grew by ~70%. The threads have to sync before flush() returns, and the overhead from that thread barrier is still substantial. Well, I don't have to sync them, but I'm pretty sure things wouldn't look right otherwise.
Do you think these can be pushed up any higher so there's more data to run through? The thread dispatch/idle overhead appears fine, work does get dispatched properly and there is some threaded improvement, it's just the context switches from that 'join' barrier at the end that's killing things. It appears flush() gets called whenever VRAM or OAM are written in writeIO(), but as this is determined by bus address it seems it'd probably be inherently serial, right?
I investigated caching and hit/miss performance. On my CPU, an Intel Coffee Lake (nearly equivalent to Kaby Lake and Skylake), CPU usage appears highly dependent on caching. I took a look into mostly at data cache rather than instruction cache, but nothing looked too amiss. I found a couple places to insert prefetch hints, and will re-test to see if they do anything. But, I'd suspect performance differences from O3 or WPO/LTO are largely from ICACHE and code positioning within the binary. There are a few low-effort ways to help the linker better position code, but higan's cascading fractal web of includes and header implementations somewhat overwhelms me, so I didn't explore further.
Finally, I checked branch predictor performance. A couple things stood out with absurdly high misprediction rates.
Firstly, For indirect mispredictions, the SFC::CPU::read(uint24) function results in many indirect mispredictions usually via bus.read() and nall::function::operator() const, apparently uncertain whether to assume readAPU or readCPU. The same read(uint24) function is also called very often via vptr from WDC65816::fetch() on each step(), that site generating very many more mispredictions from the virtual call itself.
This happening from a virtual call is very common, but can be improved in certain calling cases via a speculative devirtualization optimizer pass, i.e. -fdevirtualize-speculatively and possibly -fdevirtualize-at-ltrans at >= -O2 (or -findirect-inlining).
Secondly, for conditional mispredictions, consider the below code from higan/cpu/timing.cpp:
Code:
20 auto CPU::step(uint clocks) -> void {
21 status.irqLock = false;
22 uint ticks = clocks >> 1;
23 while(ticks--) {
24 counter.cpu += 2;
25 tick();
26 if(hcounter() & 2) pollInterrupts();
27 if(joypadCounter() == 0) joypadEdge();
28 }
[snip]
The biggest source of conditional mispredictions were line 26 (22% of executions mispredicted), and line 23 (10% being mispredicted). Ideally we could eliminate these to avoid the pipeline stalls, either by informing GCC of branch probabilities, or by unrolling / specializing the loop and explicitly hoist inner conditions out.
I think I've managed to glean that hcounter tracks the horizontal scanline, joypads are sampled every 256 cycles, and pollInterrupts() is supposed to run every 4 cycles (once per, uh, PPU 'dot clock'). As written, the 4-cycle check boils down to every other loop iteration, which explains the high misprediction rate on line 26. The mispredictions from line 23 are then almost certainly due to many calls to CPU::step() with a small argument value, especially e.g. step(2) or step(4).
What's the reason for stepping the CPU/PPU counter 2 cycles at a time? hcount() appears to always change by 2 -- is it correct to assume that hcount() cannot be odd? If this is true, a good solution is probably to add a special loop variant to handle clocks argument values divisible by 4, calling tick() twice and allowing the pollInterrupts check to be entirely removed, From there, one can survey the callers of step() and augment line 23 with an approximate branch probability, One could also specialize a clone of the step() function for certain values, and if properly referenced by the caller, the line 26 condition could be removed as well.
Anyway, do with that what you will... I'm happy to talk and explore this further, I just want to first make sure that I'm not being annoying by pestering you with text walls you aren't interested in!
Quote:
Automated playback of an input file (e.g. a TAS) could help there.
This, or some bypass-all-UI-and-just-go would be lovely. It can be hard to measure changes without also coupling moderate amounts of noise and/or variance. I've just been letting an intro play for longer to average this out, but running while sampling all the CPU counters isn't free (i.e. slow or eats disk, depending).
> CPU usage grew by ~70%
I certainly understand that the overall power usage will go up way more than the framerate gain, but we're so desperate for performance with my emulators that it's better to get the small FPS bump than leave all the other cores idle.
> Do you think these can be pushed up any higher so there's more data to run through?
Unfortunately not. Most games, 99% probably, will batch all 224 or 240 scanlines of a frame at once. Usually you'll get a game that disables the top and bottom edges of the screen, for extra Vblank time, and there's a fallback to stop OpenMP from trying to run on batches that are too small.
> This happening from a virtual call is very common
The problem here is that many, many CPU cores are shared all over the place in higan. The Z80 core is the most common, with probably six systems using it. So I have to make it a base class with virtual calls to complete it.
If I tried CRTP, or a direct #include of each CPU core inside each processor, the code size and compilation times would skyrocket.
> What's the reason for stepping the CPU/PPU counter 2 cycles at a time?
The actual CPU oscillator runs at ~21.4MHz, but in practice there's no real way to step by one cycle, so it's effectively ~10.7MHz. However, I leave it as 21.4MHz for the sake of documentation: everyone that talks about SNES raw clock cycles work in these 21.4MHz units.
> If this is true, a good solution is probably to add a special loop variant to handle clocks argument values divisible by 4, calling tick() twice and allowing the pollInterrupts check to be entirely removed
It still can't be removed. You may start step<4>() with hcount()&3 == 0 or 2. If you call pollInterrupts() on the wrong one, it won't work, the values won't match up.
In my commercial forks, my step functions are indeed turned into templatized versions to unroll the while loops.
In higan, it's important to minimize code repetition, so I often pay performance penalties to avoid manual unrolling.
What this loop would really benefit from is a binary min heap priority queue to fire off the interrupts when they're supposed to trigger, rather than testing for them on every four clock cycles. However, that's a huge, monstrous can of worms because the SNES is packed full of special edge cases that games actually rely on where the interrupt trigger points change after scheduling them. Having to parse through the min heap to pull out stale events every time this could occur would be very painful. And even then, the interrupts are very nuanced: they don't just fire ... they start to raise the IRQ lines, where a line status read will abort it. Then they hold the IRQ line steady, where reading the line will reveal it's set but not lower the line. Then finally they've fired, and the read will reveal it was set, and lower the status line. Hard to describe in text, but the point is, it's a huge, massive, pain to get the details 100% right.
If you look at Snes9X, the project's been in development since 1996/7, and still gets IRQ fixes to this day. It's really, really hard code to optimize without unintended regressions. I had IRQs working correctly in 2-3 years, but at tremendous performance penalties. Not saying either approach is better. I just prefer not to spend decades fighting stubborn IRQ edge cases.
> Anyway, do with that what you will... I'm happy to talk and explore this further, I just want to first make sure that I'm not being annoying by pestering you with text walls you aren't interested in!
I've considered all of this before, of course. But I'm happy someone's taking an interest in my code, and you may still come up with something I have not, so cheers ^-^