FCEUX crashes when I close a ROM

Ever since I switched to Windows 10, FCEUX crashes every time I select File -> Close. I find this a little annoying, because there are times when I want to keep the emulator open while I do something else but I don't want a game running in the background. Does this happen to anyone else? Should this be reported to anyone?

Download link, plz? I'd like to test it.

Doesn't happen to me.

One thing I would try is to temporarily rename the config file (fceux.cfg), and try if it does the same on a fresh config.

I got the latest stable release (2.2.3 win32) here: http://www.fceux.com/web/download.html

And also the latest build here: https://ci.appveyor.com/project/zeromus ... /artifacts

Both versions show the behavior I described above on my machine.


The only things I changed were the keys for controller 1, enabled the NTSC filter and enabled all scanlines. But I'll try a clean config.

I get the same behavior on Win10 running FCEUX 2.2.3 with a controller configured and NTSC filter:



Although, after I disabled the filter it worked as expected, then I re-enabled it and now FCEUX just closes with an error.....

Hum... So it might be the NTSC filter after all... Thanks for testing. I'll try without the filter when I get home.

FCEUX has always crashed on me when trying to use the NTSC filter, unless I disable hardware acceleration.

Yeah, just tested here and the problem does indeed only happen when the NTSC filter is enabled. The hardware acceleration options didn't change anything for me.

So... do you think anything can be done about this or it is what it is? Maybe something weird happens when the emulator stops sending images to the NTSC filter?

EDIT: Switching from another filter to the NTSC filter after having closed a game crashes the emulator too.

Sounds like a use after free bug, or something in a destructor. I might be able to take a look at it.

Oh lol, the repo is still on SVN? Maybe tomorrow.

It's relative popularity is clearly in decline to Git but SVN is widely used, actively maintained, and certainly not obsolete. I don't really see why not proactively doing non-productive work like changing the version control system for popularity's sake is worth a "lol".

If it brings contributors, or even drive-by pull requests, it's productive.

Sorry, I probably should have just held my tongue. I have no desire to provoke an argument about whether FCEUX would theoretically benefit from moving to Github (something which would take a significant amount of work by its maintainers). I was merely expressing displeasure at the idea that "still using SVN" is something to laugh at.

(BTW, the same comment without the "lol" or "still" would have been completely germane to me. If you like Git better and don't have SVN tools at the ready, I don't mind that part at all.)

What's the practical difference between a diff -ub attachment to an issue in an issue tracker and a pull request in a web frontend to Git, other than that the latter has automatic checking for whether it merges cleanly?

To me, the practical difference when I build FCEUX from source on a Debian box is that git svn clone takes a lot longer than git clone because it has to download some object for each revision one by one. So does the pull command git svn rebase, which also has rebase semantics as opposed to merge semantics.

If you like Git, you can use it locally and then submit a diff against origin. I don't know how to spin up the development environment in Windows or the exact set of packages to dnf in Fedora, but this should "git" you started in Debian or Ubuntu:

I apologize, it was mostly out of frustration that I'd have to relearn git-svn and manage to update code without ruining some private branches. Did not mean any derision against the FCEUX maintainers.

The fix was really simple. I submitted an issue and the fix at https://sourceforge.net/p/fceultra/bugs/804/ in case anyone is interested. Patch is attached in case you want to build from source yourself.

Thanks for the patch. I pushed it through.

Cool! Thanks a bunch guys, for working on this!

Laziness, every additional step discourages contribution.

That said, scons is also a barrier, it's a terrible build system that almost nobody uses, but perhaps I'm in the minority with this opinion.

Everything's a step, including the choice of repository host. For example, FCEUX not following the masses from SourceForge to GitHub introduces a step because potential contributors are more likely to already have only a GitHub account and thus have to register for SourceForge. Or a different project using GitLab or Savannah when a particular contributor uses GitHub or Bitbucket or SourceForge also introduces a step. But some more purist projects consider it an essential one because GitHub and SourceForge don't work unless a user whitelists the site's proprietary JavaScript.

I had the problem with crashing on FCEUX when I was playing with adding new mappers and launched newly produced INES 2.0 ROM with CHR-ROM banks set to 0 and CHR-RAM size in INES2.0 part also set to 0.

huh, I presumed they'd already implemented Magic Floor's CHRless mapper (the one using the CIRAM as CHR)?

Why [else] would you want CHRless?