This could be two separate issues, but I suspect they are related.

When playing Lethal Enforcers, it seems impossible to get past the target "calibration" screen. It's almost as if something is "stuck". It could be that I am simply doing something wrong, but when I tried implementing this feature in libretro I could not get it working there either.

Another thing to add is that when setting up input, simply clicking the mouse twice when trying to assign the trigger will cause a segmentation fault - in other words, you must click the options at the bottom of the window for one of the three mouse buttons, but nowhere else in the window or you will segfault. This is the case when there is a game playing, or when there is no game playing. It also does not seem to be affected by what the controller port 2 device is set to in the main window.

OS: Linux (maybe others?)

Going to Help > Documentation links to https://byuu.org/doc/bsnes, which throws a 404 page, as of version 115.

oh well, you could make an android version since most of them play snes via emulator and Android devices

Like higan-emu/higan#39 but for bsnes

Hi, both games show the known clean image icon and while Super Mario Kart (USA) with DSP1 works, the variant using DSP1B gives a black screen. Using bsnes built against latest commit.

The game hashes shown by manifest viewer:
sha256: 89ad4ba02a2518ca792cf96b61b36613f86baac92344c9c10d7fab5433bebc16 (DSP1)
sha256: 76d293e5a772eb2f326e173eac62ca323873b1f329f9b935a97ba86974e1fcd5 (DSP1B)

Update: In higan built against latest commit both variants work.

I currently use higan v106, which has this option -- currently bsnes only has "Reset Emulation", which doesn't re-initialize the WRAM like Power Cycle does.

The only way to do this in bsnes today is to Unload Game, then load it again.

I'm probably missing something, but what are the compilation instructions for Linux?

TIA!

BTW. The Discussion Forum registration, seems to be broken. The "word" is not accepted (although I pasted it from FAQ).

I don't know if you are already doing this or not but I was wondering if you plan on integrating future revisions of Sameboy into the emulator for it's Super Game Boy emulation. Sameboy is only on revision 0.12.3 so it would make sense to update BSNES's Sameboy core as new releases come out.

I would like to see the ability to force SuperFX 1 or SuperFX 2 in any SuperFX games, as I think this is a feature much older versions of BSNES had. To clarify: I'd like the ability to force either SuperFX revision in any game, allowing me to say... either force SuperFX 2 in the first Star Fox, or force SuperFX 1 in Yoshi's Island.

This is a minor quality of life issue.

Windows allows you to switch the audio output device on the fly (between speakers and headphones, for example). This is supposed to apply system-wide, but bsnes' audio output device selection only allows setting a specific audio device for backends other than waveOut. Meaning you can get a situation where you've set headphone output for the system, but bsnes's setting is still set to speakers. So, instead of simply using Windows' widget to set it for all applications (which usually respect this setting), you have to set it separately specifically for bsnes as well.

The solution is to add a setting for the system default device to the enumeration.

Thank you for your consideration.

Works on Snes9x.

Hi

When I saw that bsnes had been updated with the latest SameBoy my heart skipped a beat but it appears the buildbot is failing building Windows binaries.

What causes the builds to fail and is there a kindhearted soul out there that have managed to build the latest bsnes with all commits up to f98cb01

Many thanks in advance!!

I realise that hacks don't usually count but this hack runs on the real hardware on SD2SNES with no issues. In the latest bsnes and higan upon opening the hack it just presents a black screen and you only hear the sound of a coin being collected (which is the intro sound for SMWC presents screen) then nothing. The hack is found here https://www.smwcentral.net/?p=section&a=details&id=14812

In this article, Byuu mentions that the PPUs aren't fully documented and understood yet.
https://byuu.org/articles/edge-of-emulation

I found the documentation from the Official Software Development Kit of the Super Nintendo if that's of any help to Byuu and others in the emulation community? It's got quite a lot f information on the PPUs [THIS LINK REMOVED FOR ETHICAL AND LEGAL REASONS.]

It's very important to put together an official website for bsnes, with features, screenshots, and download links. It could also prove helpful to include documentation for bsnes on said page at some point.

bsnes has a URL in the about box which points to the bsnes-emu GitHub repository. It should be updated to point at the new webpage once this is done.

I believe this would now be in bsnes' purview as a compatibility hack.

It's a known issue (MMX3 Zero Project blackscreening). The expanded relocalisation hack by Solid One also softlocks during the intro.

All bsnes and higan cores in Retroarch, besides this one, support RetroAchievements (even higan Accuracy and nSide Balanced, contrary to the info in the docs).

It would be great to have this excellent up-to-date core also supporting RetroAchievements. Maybe code from the other bsnes/higan cores can be ported to this one to save time.

I'm not sure where bsnes is going to end up, but I am going to repost this issue here in hopes it doesn't get lost.

Original link: https://github.com/byuu/bsnes/issues/304

OS: Slackware64-current
Compilter: clang-10.0.0
bsnes: v115

This is somewhat pedantic, so please handle it how you feel best.

I found this segfault in the input settings, to reproduce:

1. Start bsnes.
2. Navigate to Settings -> Input ...
3. Click any button mapping and then press Assign.
4. Without assigning any keys to the button press the drop down menu under Port:.
5. Select a different controller port, for example Controller Port 2.
6. Segfault.

Thread 1 "bsnes" received signal SIGSEGV, Segmentation fault.
nall::shared_pointer<hiro::mTableViewItem>::data (this=0x0)
    at ../nall/shared-pointer.hpp:160
160	    if(manager) return (T*)manager->pointer;
(gdb) bt
#0  0x00000000005ab1c0 in nall::shared_pointer<hiro::mTableViewItem>::data() const (this=0x0) at ../nall/shared-pointer.hpp:160
#1  0x00000000005ab1b6 in nall::shared_pointer<hiro::mTableViewItem>::operator*() const (this=0x0) at ../nall/shared-pointer.hpp:168
#2  0x00000000005ab1a6 in hiro::TableViewItem::self() const (this=0x0)
    at ../hiro/core/shared.hpp:670
#3  0x0000000000756196 in hiro::TableViewItem::offset() const (this=0x0)
    at ../hiro/core/shared.hpp:670
#4  0x000000000073c9ac in InputSettings::updateControls()
    (this=0x36c2d28 <inputSettings>) at target-bsnes/settings/input.cpp:71
#5  0x000000000073d553 in InputSettings::reloadMappings()
    (this=0x36c2d28 <inputSettings>) at target-bsnes/settings/input.cpp:127
#6  0x000000000073d09a in InputSettings::reloadDevices()
    (this=0x36c2d28 <inputSettings>) at target-bsnes/settings/input.cpp:112
#7  0x000000000074fef9 in InputSettings::create()::$_12::operator()() const
    (this=<optimized out>) at target-bsnes/settings/input.cpp:21
#8  0x000000000074fe9a in nall::function<void ()>::lambda<InputSettings::create()::$_12>::operator()() const (this=<optimized out>) at ../nall/function.hpp:72
#9  0x0000000000598999 in nall::function<void ()>::operator()() const
    (this=<optimized out>) at ../nall/function.hpp:29
#10 0x000000000055f22f in hiro::mComboButton::doChange() const
    (this=<optimized out>) at ../hiro/core/widget/combo-button.cpp:23
#11 0x000000000055f1dd in hiro::pComboButton::_updateSelected() (this=0x4164420)
    at ../hiro/core/../gtk/widget/combo-button.cpp:85
#12 0x000000000055e9b9 in hiro::ComboButton_change(_GtkComboBox*, hiro::pComboButton*) (comboBox=<optimized out>, p=0x0)
    at ../hiro/core/../gtk/widget/combo-button.cpp:5
#13 0x00007ffff731ec32 in g_closure_invoke () at /usr/lib64/libgobject-2.0.so.0
#14 0x00007ffff733111c in  () at /usr/lib64/libgobject-2.0.so.0
#15 0x00007ffff7339bce in g_signal_emit_valist ()
    at /usr/lib64/libgobject-2.0.so.0
#16 0x00007ffff733a232 in g_signal_emit () at /usr/lib64/libgobject-2.0.so.0
#17 0x00007ffff7893291 in  () at /usr/lib64/libgtk-x11-2.0.so.0
#18 0x00007ffff7898b08 in gtk_combo_box_set_active_iter ()
    at /usr/lib64/libgtk-x11-2.0.so.0
#19 0x00007ffff7898cd0 in  () at /usr/lib64/libgtk-x11-2.0.so.0
#20 0x00007ffff731ec32 in g_closure_invoke () at /usr/lib64/libgobject-2.0.so.0
#21 0x00007ffff733111c in  () at /usr/lib64/libgobject-2.0.so.0
#22 0x00007ffff7339bce in g_signal_emit_valist ()
    at /usr/lib64/libgobject-2.0.so.0
#23 0x00007ffff733a232 in g_signal_emit () at /usr/lib64/libgobject-2.0.so.0
#24 0x00007ffff7a258da in gtk_widget_activate ()
    at /usr/lib64/libgtk-x11-2.0.so.0
#25 0x00007ffff7928a6d in gtk_menu_shell_activate_item ()
    at /usr/lib64/libgtk-x11-2.0.so.0
#26 0x00007ffff7928cf6 in  () at /usr/lib64/libgtk-x11-2.0.so.0
#27 0x00007ffff7916d2b in _gtk_marshal_BOOLEAN__BOXED ()
    at /usr/lib64/libgtk-x11-2.0.so.0
#28 0x00007ffff731ec32 in g_closure_invoke () at /usr/lib64/libgobject-2.0.so.0
#29 0x00007ffff73308b6 in  () at /usr/lib64/libgobject-2.0.so.0
#30 0x00007ffff7339277 in g_signal_emit_valist ()
    at /usr/lib64/libgobject-2.0.so.0
#31 0x00007ffff733a232 in g_signal_emit () at /usr/lib64/libgobject-2.0.so.0
#32 0x00007ffff7a26aac in  () at /usr/lib64/libgtk-x11-2.0.so.0
#33 0x00007ffff7914ffc in gtk_propagate_event ()
    at /usr/lib64/libgtk-x11-2.0.so.0
#34 0x00007ffff79153ab in gtk_main_do_event () at /usr/lib64/libgtk-x11-2.0.so.0
#35 0x00007ffff777bc0c in  () at /usr/lib64/libgdk-x11-2.0.so.0
#36 0x00007ffff7234b2d in g_main_context_dispatch ()
    at /usr/lib64/libglib-2.0.so.0
#37 0x00007ffff7234d80 in  () at /usr/lib64/libglib-2.0.so.0
#38 0x00007ffff7234e0f in g_main_context_iteration ()
    at /usr/lib64/libglib-2.0.so.0
#39 0x00007ffff79146dd in gtk_main_iteration_do ()
    at /usr/lib64/libgtk-x11-2.0.so.0
#40 0x000000000056e5ee in hiro::pApplication::processEvents() ()
    at ../hiro/core/../gtk/application.cpp:47
#41 0x000000000056e598 in hiro::pApplication::run() ()
    at ../hiro/core/../gtk/application.cpp:30
#42 0x0000000000570546 in hiro::Application::run() ()
    at ../hiro/core/application.cpp:38
#43 0x00000000006f1dbe in nall::main(nall::Arguments) (arguments=...)
    at target-bsnes/bsnes.cpp:55
#44 0x00000000006f18aa in nall::main(int, char**)
    (argc=<optimized out>, argv=<optimized out>) at ../nall/main.hpp:20
#45 0x00000000006f1f26 in main(int, char**) (argc=0, argv=0x4bb0738)
    at ../nall/main.hpp:41

MiSTer-devel/SNES_MiSTer#213

(4th dungeon) Character sprite is clipping into some layers.

https://youtu.be/RNTP8tl1yYY

Or higan, for that matter. I have no idea how I'm supposed to compile this into something usable. I never compiled code before.

QT4 has been EOL since December 2015, so basically 5 years now. Porting to QT5 should be a priority at some point as newer versions of both windows and linux distros could potentially (unlikely soon however) break functionality of the UI suddenly.

Presuming #78 gets merged, there will be four hacks left that aren't directly related to intentional accuracy sacrifices for speed. Two in particular look like low hanging fruit:

https://github.com/bsnes-emu/bsnes/blob/master/bsnes/target-bsnes/program/hacks.cpp#L25

//the dialogue text is blurry due to an issue in the scanline-based renderer's color math support
if(title == "マーヴェラス") fastPPU = false;
//stage 2 uses pseudo-hires in a way that's not compatible with the scanline-based renderer
if(title == "SFC クレヨンシンチャン") fastPPU = false;

These work correctly with the pixel-based PPU. I can't make sense of how to port the fixes from it to the scanline-based PPU, but I'm making an issue report in the hopes someone else can.

The color blending code for the pixel-based PPU is here:
https://github.com/bsnes-emu/bsnes/blob/master/bsnes/sfc/ppu/screen.cpp#L32

The color blending code for the scanline-based PPU is here:
https://github.com/bsnes-emu/bsnes/blob/master/bsnes/sfc/ppu-fast/line.cpp#L106

Also worth noting is this issue affects higan-emu's ppu-performance, only there's no hacks in place with it:
https://github.com/higan-emu/higan/blob/master/higan/sfc/ppu-performance/dac.cpp#L33

A fix for this would improve both emulators.

In higan-emu/higan#118 @jchv implemented a very nice GitHub Actions based CI system for higan. We should copy that to bsnes too, for consistency and because it integrates more nicely with GitHub releases than Cirrus CI does.

This would also go a long way towards fixing #22.

Add Windows, Linux, and macOS builds to the Github release please! I don't understand why there are no builds for v115.

I started playing through Seiken Densetsu 3 today. When I get to the point where a second character joins my party, control switches to the new character even though the game says control remains with the first. The switch character button stops functioning, as well as the pause button. Resetting the emulator doesn't fix the issue, nor does restarting the program. I've replicated this on a second fresh playthrough.

Currently, bsnes does not support the Barcode Battler II, a device that plugged into the controller port and scanned barcode data for use with games that supported it.

no$ has some documentation on it, but it is incomplete and somebody would probably need to spend some time with an actual device and an oscilloscope, or write some test ROMs, to figure out how it actually works.

Makefiles produced by GNU Autotools support two separate build settings that control where make install will install files:

• $prefix defaults to /usr/local, describes where files will be at runtime, and may be compiled into the executable
• $DESTDIR defaults to the empty string, describes where files will be placed at install time, and must not be compiled into the executable

The idea is that when building an RPM or DPkg package, distro maintainers can set $prefix to the path where the program will be installed on the target system, and set $DESTDIR to build it in some isolated temporary location that doesn't need root access to write to. For example, if the makefile says:

install out/myprog $(DESTDIR)$(prefix)/bin/myprog

...then a user may run make install to get /usr/local/bin/myprog, but a distro package may run make DESTDIR=/tmp/build/myprog prefix=/usr install to get /tmp/build/myprog/usr/bin/myprog, which gets archived into a package, which gets installed as /usr/bin/myprog.

bsnes does not support this scheme. There are no build settings to control what paths get compiled into the executable, so the only thing that matters is where files are placed at install time, which is effectively a combination of $prefix and $DESTDIR. In bsnes' build system, this setting is confusingly named $prefix.

However, while bsnes system is simple and self-consistent, it's inconsistent with the rest of the world and causes confusion and grief for people trying to integrate bsnes with any kind of larger packaging system. Although it makes bsnes a little more complicated, we should add $DESTDIR support to the build system, probably along the lines of:

• add a new, empty DESTDIR variable to nall/GNUmakefile, near where prefix is declared
• add $(DESTDIR) to all the Linux/BSD install commands in bsnes/target-bsnes/GNUmakefile

Current Design: The current flow for the UI is for the user to click System and and then click Load Game, then to either scroll through their list of games, or to click the search/filter field and type in text at the bottom, and press enter. Also, the user cannot sort the file listing, like most other file explorers. They cannot sort by date modified, or change the order of descending/ascending for the current sort by name default. Finally, the use of this field is unintuitive because pressing enter if the field is blank doesn't clear the search results, it actually presses the "Cancel" but AFAICT, which is confusing. To clear the filter, you have to press the search button that is to the left, when enter would have ran the query.

Proposed Change: Make it so the default state of the load game screen begins with the search/filter field having the text cursor, and make it so the user doesn't have to press enter (make it adaptive) to filter the results. In summary, each of the changes that would help. Then, because the search button is not needed, and because this is more of a filter results than a search (semantics I guess), change the search button to simple text that says "Filter:" or "Search:" instead. Add ascending/descending by name and by date modified to the load game ui component. Finally, make it so pressing Enter when the load game screen is in focus always does "Open", and pressing Esc always does "Cancel" to avoid confusion. Here's the individual items that would need to be addressed if this were used.

• Change start condition of load game screen to have the text cursor be active in the search/filter field.
• Change the search/filter field so that it is adaptive (filters in real-time as you type with some kind of update delay interval, as opposed to requiring a press of the Enter key/Search button)
• Change the search icon+button to merely plain text that says "Filter:" or "Search:" or leave it the same but with an indicator that the search is to the right of it. Or have text when the field is blank behind the field itself which says "Filter by name here" or something like that.
• Add ascending/descending by name and by date modified capabilities.
• Change key press functionality to "Enter" always pressing "Open" and "Esc" always pressing "Cancel"

Thanks.

For manufacturing cost reasons, most SNES games only provide a very small number of in-game save slots, which can be quite limiting for long games like RPGs. In addition, it is possible for in-game saves to be corrupted because of bugs in the original game (hello, FF6!) or lost due to the use of features like save-states.

Save-states are plentiful, they can never be corrupted by the game or lost due to other features, but they only work with a single version of a single emulator, which is effectively a different dataloss bug.

bsnes should provide a hybrid of the two, by recording all in-game saves and allowing the player to switch back to any previous save.

It might work like this:

• when bsnes detects the game writing to SRAM (with hysteresis, like the "Auto save memory periodically" option)), it should record:
  • the new SRAM contents
  • the current date and time
  • maybe a screenshot
• In the Tools menu, there should be a Save Manager, similar to the current State Manager. It would allow the user to browse list of available saves, ordered by timestamp, give them more descriptive names, etc.
• Restoring a previous save should copy the old save data into place, and reset the emulation.
• Restoring a previous save then making a new save will just append the new snapshot to the end of the list, we don't need to track forking timelines or whatever (we could, like full-on Git branching, but most PC games that offer unlimited in-game saves don't bother, so I don't think it's worth the effort)

I have tried for so long to get Super Mario Kart to load and it keeps saying that dsp1b.bin is missing even though it is in the folder and then the game does not load. I am disappointed at this gaping bug because I am not able to play Super Mario Kart.

I was recording a movie file while using savestates, attempting to make a segmented run that I could play back. However, the movie file seems to contain every input I made during the time the movie was recording, without regard to savestates, so it desyncs the first time I did a Load State during the recording process.

If the movie recording was also affected by savestates, this would match the behavior of Snes9x-rr with SMVs and lsnes with LSMVs.

I was using the release version of v115, if this makes a difference.

I have found that changing the shaders in BSNES cause a BSOD in Windows 10.

• OS: Windows 10, 19041.572
• GPU: GeForce RTX 2070
• BSNES: v115
• Caused by: Changing shader in the menu

I have .dmp files if needed, and can upload them in a private and secure location.

The official bsnes releases ship with a default configuration file and shaders. It would be ideal to grab the settings.bml file from the bsnes v115 release, and ensure that this and the shaders appear inside nightly release builds.

The December 1994 build of Star Fox 2 (also known as the Winter CES build) black screens on the latest version of bsnes.
Music for the intro will play without displaying any graphics until it eventually gets stuck playing the same sequence of notes over and over.

sha1: 78bd997be4cf54b952dec88957d59e8ec30c7723 (SF.ROM)

The header is misplaced, bytes 7FB0-7FBF need to be copied over to 7FC0-7FDF. Tested working on Snes9x.

Hi, This is Derkoun, of bsnes-hd.
I just wanted to start this issue as a place to discuss anything you want to upstream from bsnes-hd,
and also further development of HD Mode 7 and other HD features in bsnes and/or bsnes-hd,
see #12 (comment)

Current design of the input mapping for bsnes for Windows (not certain about other builds for other operating systems) makes it so to assign inputs I have to do the following:

1. Click the Named input I want to map, such as "Up"
2. click "Assign"
3. press the button on my gamepad
4. repeat

Many other emulators in their UI's and frontends in general allow you to press a button that automatically guides you through the process, ie "Press up twice" (like mednafen) and then it proceeds to the next on "Press down twice".

It would be helpful to add this feature to the input mapping. Anytime I have to remap inputs, it's needlessly laborious.

Thank you.

In POSIXy environments, make install installs a bsnes.desktop file that (among other things) says:

Exec=bsnes

That is, "to execute this application, launch the first bsnes executable on the default $PATH". However, we have no guarantee that our install destination is on the default $PATH (and on many Linux distros, it isn't) so this doesn't work as well as it should.

Instead of installing the file with cp, we should use sed at install time to set the actual path we installed the binary to, just to be sure it works.

Hi, is this still being developed?
Anyways, I'd like to ask if it is possible to add CHD compression support for MSU-1 files. It would allow us to greatly reduce its size while having just one file for all track (as long as it works like it does for disc based games).

I'd also like to be able to choose a folder path for these files (like what already exists for games, patches, saves, cheats, states and screenshots) so I dont have a bunch of MSU files on my games folder.

I'm mostly just curious, but I suppose this idea would reduce input lag that tiny bit more...

Could we take advantage of high-refresh monitors by drawing at more than 60fps? It seems like the newly-calculated scanlines could be updated 4 times per frame on a 240Hz monitor, for instance.

At least in the GTK+2 build, there are hotkeys for "Toggle Fullscreen" and "Toggle Pseudo-Fullscreen". We should figure out how those are different and document it somewhere.

All of the super Nintendo roms that Nintendo has rereleased have been modified to use PCM audio data, and as a result, only work properly on their emulators. I think it would be nice to see these properly supported in bsnes.

Hi,

As illustrated in the SNES development manual, the S-CPU should be able to access ROM outside of the first 2MB range on SuperFX carts via banks 80-FF:

Currently, no emulator supports this feature (as far as I am aware), and although no official SuperFX game utilizes this memory region, I believe the addition of this feature would greatly benefit the homebrew and ROM hacking community.

Thanks!

A few minor emulation fixes have landed in higan since bsnes was forked. We should cherry-pick those fixes across to maintain parity. You can generate a list of candidates in the higan repository with git log v110.. higan/sfc (assuming byuu already synced any changes from the fork-point to v110), but as of this writing they include:

• higan-emu/higan@caed155
• higan-emu/higan@56bdd46
• higan-emu/higan@e422ddc

(I'm not sure about that middle one, but it's worth investigating)

bsnes currently uses a copy of the boards.bml database from 2018, while higan's copy was updated in 2020 and includes more entries.

boards.bml is an actual file in the repo, but I don't think the bsnes compilation process uses that file directly - I think there's an additional, manual step of encoding it into a C++ source file that can be built into the bsnes binary, probably using the sourcery tool.

Please update the drivers to more modern versions, the ones included in the emulator are outdated .... mainly DX9-> DX11, XAudio2.1-> Newer Version and Xinput

God bless you...

Background: I was trying out this ROM hack yesterday and noticed that my framerate was capped at around 50 FPS, making it unplayable. This shouldn't be a matter of just processing power, because my PC has very high specs. In fact, I then went on to test out other hacks - ones that I was able to play just fine on this system previously - and they all had the same 50 FPS cap.

I then went on to try different things and figured out that the cause of this problem is the combination of certain audio APIs with certain audio output devices. My PC speakers died on me yesterday, so I was forced to switch to an USB headset I had lying around. I set up BSNES to use WASAPI with my USB headset. Trying out different audio APIs with the same headset, I could observe that every one of them led to a different framerate cap, all below 60 FPS. Disabling audio entirely or switching the audio output back to my broken PC speakers restored the intended framerate cap of 60 FPS.

It's worth noting that I went on to play the hack in RetroArch + Snes9x core afterwards, which did not show these symptoms, so it seems to be something unique to BSNES. I don't know what could be causing it, though. Maybe some kind of audio syncing. Since this is a USB headset, I suppose it technically counts as its own sound device (rather than using the Sound Blaster Z in my PC), so maybe BSNES uses audio in a way that isn't compatible with all audio devices or something like that.

This USB headset is pretty much from a no-name brand, but I can imagine that other audio devices could lead to similar issues. Also I just went ahead to check if there's an option for audio-syncing, and indeed there is one. When I disable it, the framerate is actually capped at 60 FPS, so that confirms that audio-syncing is the issue here, but I'm not sure whether this can be considered an actual bug or whether this is something that is just inherent to certain audio devices/drivers and that BSNES can't do anything about.

The repository byuu/bsnes had a list of real hardware graphical glitches, not emulation bugs, (not transferred to the website) that had vanished recently. A good majority of these were initially noted by @Max833. These issues are useful for avoiding false positives and false negatives when reporting emulation bugs on a per-game basis.

Hello i am new here but i am just in huge love on HD Mode 7 =)
And i am dream to see texture filtration to be implemented
something like this
https://www.youtube.com/watch?v=E6ut__me_FI
it uses my custom shader for reshade, you can get it here (i know it not perfect, maybe some one can improve it)
http://raven-05.narod.ru/reshade/temp3.fx

I am using the latest nightly build.

Open any ROM.
Select Tools/Cheat Finder...
Press scan
Double click on any of the finds.
Enter a name and click Add.
You see wrong error message.
Remove empty line and press Add.

Problem is that that line does not filter out empty lines and then decodeSNES() reports an error.

Looks like this issue still remains (https://archive.is/Mm4NZ#selection-1835.80-1835.141)

When you press b at this place, the password menu gets skipped sometimes. The same happens when you press b at the start - the new game starts immediately and you can't choose "continue game".