bsnes was developed by its author as a response to less accurate emulators like ZSNES. The goal of having near perfect emulation accuracy meant performance took a hit. Eventually the original version of bsnes was renamed higan and development of bsnes ceased.
However as of 2018 bsnes has been revived by its author (byuu). The goal of this revival is provide an emulator with high accuracy with good performance that is easier to use than higan and with that attract a wider audience.
In addition to the normal ("stable") release of bsnes (which is recommended for most users) there are two other options: the Nightly builds and the HD mod. The Nightly builds may include cutting edge new features (see the author's homepage for details), while the HD build contains graphical improvements for certain games, notably those which make use of "mode 7" such as F-Zero and Mario Kart. The HD version was featured in this Ars Technica article.
As for higher resolutions: It is possible and already supported in the code. I can do it when I hard-code the higher factor. But reading it from the settings/configuration does not work correctly (updates only one of the two causing crashes). The main cause for such issues is that I don't entirely unterstand the bsnes settings/configuration system. I'm sure when byuu integrates the code this issue will be gone in 2 minutes and the slider can be extended. (Maybe switching without restart will also be possible?)
bsnes/higan is a powerful emulation software that effectively replicates the hardware and gameplay of the Super Nintendo Entertainment System (SNES). Thus allows us to run and play digital copies of the read-only memory chips, popularly known as ROMs on our devices without the need of having an actual SNES Console.
With integer scaling on, bsnes uses a lower resolution than it could.Fullscreen resolution is set to 1920x1200. The output video has a resolution of 1280x960 (x4). It has room to go up to 5x. Aspect ratio is set to core provided.
AFAIK, the current bsnes and bsnes-hd-beta cores do not have any way to natively downsample and will always have double vertical and horizontal res to accommodate mid-scanline res changes. This is functioning as expected and as intended.
I may have run into a similar issue IIRC. I tend to use controller mapping software for most of my emulators in order to map emulator functionality to controller functions (save states, load states, etc.). As a result my workaround here was fairly simple; I just mapped the bsnes exit emulator key to the controller combination I would normally use to exit an emulator.
You can configure the key used to exit bsnes in the input settings (the settings in bsnes, not in GameEx). I believe I have mine set to F5, but for some reason I think I altered it from the bsnes default, possibly due to a conflict with my controller mappings. This setting could just as easily be set to exit bsnes when esc is pressed (or whatever your global exit key is in GameEx).
Hmm . . . all good information. I'm not sure where to take it from here. I suggest putting this in as a feature request. In the meantime I think your options are either to alter your exit button combo for the purposes of bsnes, or to consider an alternate approach like an AutoHotKey script. AutoHotKey was basically designed to handle stuff like this, and it's fairly easy to write up a simple button swap script.
Higan is a free and open source emulator for multiple video game consoles, including the Super Nintendo Entertainment System. Originally called bsnes[4] (which was later reused for a new emulator by the same developer), the emulator is notable for attempting to emulate the original hardware as accurately as possible through low-level, cycle-accurate emulation and for the associated historical preservation efforts of the Super NES platform.[5][6]
Development of the emulator began with the name bsnes on October 14, 2004. The first version was released in May 2005 for Microsoft Windows. The early versions would require high-power hardware to run games in a consistent manner and therefore garnered controversy.[8] Since then, it has been ported to Linux, macOS, and FreeBSD. Initially developed under a custom license, later releases were licensed under various versions of the GNU General Public License. On August 9, 2012, the project was renamed to higan, to better reflect its new nature as a multi-system emulator.
In 2008, British Internet magazine Webuser recommended bsnes for "some fun old-school gaming".[16] In 2009, Japanese game magazine GameLabo recommended it for "those seeking a realistic playing experience".[17]
The package.patch included sets release as build. However, traditionally bsnes has three options to choose from: performance, balance, and accuracy. More detailed information on these different core options you can find on the docs.libretto website. Short story, these core options influence compatibility with certain games when using cycle accurate settings. AFAIK release doesn't do anything, and it'll default back to performance anyway.
Edit: Forgot to add, in order to get cheats, shaders, firmware working they'll need to be copied from /usr/share/bsnes/ to .config/bsnes/. It would be nice nice if that functionality could be added to the makepkg.
I've been working on my homebrew game today and tested it on several emulators. I don't understand why, but my game runs faster on bsnes than it does on every other emulator I've tried. I'm pretty sure I never noticed a speed difference before, but today it is pretty obvious. I'm wondering what speed my game will run on real hardware, because I enjoy how fast it runs on bsnes.
Original bsnes calculates a corrected width before calculating scaled size and discards fractional part of the resulting value instead of rounding. This results in an error that is higher than with rounding and grows proportionally with scaling ratio.
Compared to the original bsnes GUI, bsnes-plus features several improvements to the debugging and memory editing windows, as well as numerous emulation improvements from later versions of bsnes. See the GitHub project page here for a full list of features, and instructions for building on non-Windows platforms.
Emulators for playing older games are immensely popular online, with regular arguments breaking out over which emulator is best for which game. Today we present another point of view from a gentleman who has created the Super Nintendo emulator bsnes. He wants to share his thoughts on the most important part of the emulation experience: accuracy.
My experience in emulation is in the SNES field, working on the bsnes emulator. I adored the ideal behind Nestopia, and wanted to recreate this level of accuracy for the Super Nintendo. As it turns out, the same level of dedication to accuracy pushed requirements up into the 2-3GHz range, depending on the title.
As an example, compare the spinning triforce animation from the opening to Legend of Zelda on the ZSNES and bsnes emulators. On the former, the triforces will complete their rotations far too soon as a result of the CPU running well over 40 percent faster than a real SNES. These are little details, but if you have an eye for accuracy, they can be maddening.
Hi,
very nice work. However, I think there is something wrong with the scanlines. Check how scanlines look, say, in Kega Fusion or even Snes9x, where they are perfectly even, and compare this to the scanlines in the screenshots you have posted. There are distortions that follow a regular pattern, which suggests that the image is squeezed. (I use Simple Smoothing & Blargg's NTSC filter on bsnes, so I never noticed, but when I checked it earlier, it looked the same on my computer. I'm using Richard Bannister's port on OS X.)
-adrenaline (from byuu.org forums)
Hey man! I know the bloom shader I'm using does a sort of squeeze/offset to produce the blur, but you said you saw it on your machine without the bloom, too? Would you be interested in posting a couple of comparison shots depicting the distortion? If it is indeed something that needs fixing, perhaps I could just bring over one of the other emus' scanline filters into bsnes to correct it.
It isn't. DOSBox doesn't do cycle accurate CPU emulation so you can't emulate specific CPUs. Because of that, it's one of its strengths - speed. Your dusty old Pentium 4 2.4GHz can imitate an approximate Pentium 200 quite well in it, but you don't get a BIOS, proper ISA/PCI bus and other things a tight-as-nails accurate 'bsnes' emulator would expect.
df19127ead