nesdev.com

Under *n*x, there's the "Xvideo" X11 extension, which provides access to hardware-accelerated colorspace transforms. I have no idea if there's a Windows variant of that, though.

Also, I didn't mean dropping DX11, but probably using lower versions?

Older versions are starting to be pretty ancient by now, though. DX9's latest release dates back to 2010 (and it was first released in 2003...). I'm not much of a DX expert, but from my understanding, the API between DX9 and DX10 was completely changed and converting to DX9 would pretty much imply rewriting all the code. Not to mention worldwide Windows XP usage is down to 5%, so there is not much incentive for me to switch to DX9 at this point.

Also, just to know, is it the 8x resolution version of the filter that's running at 20fps on your computer?
If your CPU is a dual core though, it's very likely the filter is performing even worse than it would normally due to how the core is built. If the filter doesn't render the picture within 16ms, the emulation thread ends up doing a spinlock while waiting for the next thread (to keep latency as low as possible). With a dual core CPU, though, this means that the emulation thread is wasting a whole core while the other 2 threads are trying to finish rendering the picture - this is far from being an ideal scenario.

It's the speed of the 2x resolution, and yes, it's dual core.

I'm trying to run Mesen on OSX using mono. Mesen version is 0.7.0, from the official website. Mono version is 4.4.2, installed SDL2. When I run "mono mesen.exe", it creates a file "libMesenCore.dll", and I get an error "Mesen could not launch because it was unable to load MesenCore.dll due to missing dependencies". Any hints on what to try?

If you're using a precompiled version, it's likely the standard C++ library on your system doesn't match what Mesen is compiled against. If you can, I'd suggest trying to compile Mesen yourself and see if that works. Also, keep in mind that I haven't done any OSX testing, so it is fairly likely that there may be issues (and I won't really be able to help fix them as I do not own a Mac)

Running 0.7.0 on Linux using Mono, and it crashed twice. One time, it crashed while paused in Super Mario Bros. while opening the video settings with a crash log, and the other time, I scaled the video down to zero, and then back up. It is also extremely jittery despite the emulator reporting a constant 60-61 FPS with and without VSync enabled.

Crash log:
Native stacktrace:

mono() [0x4b18ff]
mono() [0x42982c]
/usr/lib/libpthread.so.0(+0x11080) [0x7fe4f4381080]
/usr/lib/libc.so.6(+0x128952) [0x7fe4f3ee3952]
/home/syboxez/.local/bin/libMesenCore.dll(_ZN11SdlRenderer6RenderEv+0x121) [0x7fe4e737ad81]
/home/syboxez/.local/bin/libMesenCore.dll(_ZN13VideoRenderer12RenderThreadEv+0x26) [0x7fe4e73712e6]
/usr/lib/libstdc++.so.6(+0xbb970) [0x7fe4e6baa970]
/usr/lib/libpthread.so.0(+0x7454) [0x7fe4f4377454]
/usr/lib/libc.so.6(clone+0x5f) [0x7fe4f3ea37df]

Debug info from gdb:

terminate called without an active exception

=================================================================
Got a SIGSEGV while executing native code. This usually indicates
a fatal error in the mono runtime or one of the native libraries
used by your application.
=================================================================

EDIT: Jitteriness was caused by GNOME's desktop compositing. Tried in MATE, and it worked somewhat, but there was massive amounts of screen tearing, even with VSync turned on.

I just released version 0.8.0.

It includes a lot of debugger improvements, a few emulation fixes, and a handful of options to enable/disable model-specific behaviors (e.g noise channel loop flag, $2004 read behavior, oam addr bug, making the PPU reset or not when resetting console, nes-001 vs nes-101 open bus behavior for input ports, etc.)

Interesting you made some model-specific behavior settings. I've been thinking about this with regards to audio, since that's my biggest area of interest, but, like I've said before, I have no capability of programming it myself. You may have seen this recent thread where Great Hierophant made some comparison recordings of NESes and I posted some of two revisions of the Famicom. You incorporated NTSC video simulation into your emulator, but I find it jarring to have it on and then have such bright audio that hasn't been smoothed by analog output. Would you be interested in adding EQ presets for different audio output methods?

With a suitable piece of audio, whether from a game or a test ROM (I think tepples might have some advice here on what to use), I could make recordings on hardware and through Mesen and give you comparative EQ values to create settings to make Mesen's audio sound like an early model and a later model Famicom over RF, a Twin Famicom over RF (which is essentially the same) and standard coaxial A/V cable, and an NES over both as well. I plan on buying an A/V Famicom sometime not too long from now, and I guess that would just leave the toploader NES to acquire. It would also be possible to make mixing presets for expansion audio to mimic hardware (roughly, since, as rainwarrior points out, different individual Famicoms have variances and heat differences can affect it as well). If you're interested, I'd be happy to contribute.

Also relevant to audio filtering: this thread.

I have a hunch that we won't see the 75µs audio preemphasis filter in any Famicom or NES RF modulator.

I'm more than happy to try - it would be pretty interesting to have sound presets for the different models.
However, just keep in mind that my sound processing skills are pretty terrible.
Everything sound-related in Mesen at the moment is pretty basic stuff (and the more "complex" stuff usually involved me googling until I found a suitable solution).
I'm sure I can eventually pull something off - I just don't know how much time it might take.

Maybe somebody here knows of some open source multiband equalizer program you could use or adapt. 30 bands should give pretty good precision, but I can give volume change values for even more than that. I know there are linear phase and minimum phase EQs out there, but I don't really have any advice on which you should seek for this purpose. Linear phase is usually used for just a few bands that cover a broad range of frequencies, so maybe minimum phase is more appropriate. I'm no authority though, I haven't gotten educated on the details of equalizers.

In the thread lidnariq linked to, tepples said, "Perhaps I need to write something that outputs pink (1/f) noise through $4011 for calibrating EQ." I know he and lidnariq are very knowledgeable, so if tepples thinks that's the best method and lidnariq agrees, if somebody can hook me up with a ROM that does that, I can load it onto my Everdrive and record it. I'll have to get a pin converter to use the Everdrive with my NES, though. So, addressing your statement that you don't know how much time it will take, I'm in no big rush. I want to see this happen, and if having recordings sooner rather than later might motivate to do it, I can do that, but I'm patient too. Take your time to figure out how this can best be done. I also need to get the blown capacitor or voltage regulator in my earlier model Famicom fixed before I can use it, so...

Well, in what must be record time (just four hours after my last post!) tepples made a test ROM, so I felt I had to do something with it as proper thanks. I made some recordings and EQ profiles, with a Famicom and a Twin Famicom, and I figured I'd share an example result. http://www.mediafire.com/file/h0e2rh90y ... arison.zip

In the zip is the title screen music of the US Legend of Zelda recorded from Mesen's sound recorder (Mesen original.wav), the Twin Famicom through its RCA audio out with a rather thick RG6 cable (Twin Famicom.wav, obviously), and then Mesen EQ.wav was created by matching the frequency spectrum of the pink noise recorded through the Twin Famicom to the spectrum of the pink noise recorded from Mesen and then applying it to Mesen original.wav. All three files are sample-aligned and volume matched with ReplayGain. I think you'll find that the Twin Famicom recording and Mesen with EQ applied sound very, very similar. Spectrum analysis also shows them to be extremely similar, as you'd hope, up to about 20 kHz, which is a limitation of my EQ plugin.

I found a tiny library that seems to work.
https://github.com/thedrgreenthumb/orfanidis_eq

I've managed to make games sound like they have way too much treble, so I assume it's working!

It supports arbitrary numbers of bands (with 5, 10, 20, 30 presets) and lets you set the gain for each band. The built-in bands seem to go from 20hz to 20khz, but that's probably something I can change if need be (though that's pretty much the limits of the human ear so...).

Seems to support chebyshev type 1 & 2 filters, and butterworth (whatever those are!).
It seems to cause a ~15% performance loss in stereo mode. So half that for mono, and probably possible to make it a bit faster than what I just tried as a test, too. Either way, it's not that bad (especially for an optional feature).

At this point I guess I can setup the gains based on measurements to build some preset filters, and add an equalizer in the audio options, too.
I have no idea how to determine gain values for each band though (or for that matter, how to pick how many bands is appropriate)

You probably don't actually need a graphic EQ instead of just a few lowpass and highpass filters at the correct corner frequencies.

Although we have data about the characteristics of the NES-001 RCA audio output, we've never sat down and done the same for RF output.

Pass band: Frequencies that you do want
Stop band: Frequencies that you DON'T want.
Ripple: Non-monotonic change in amplitude as a function of frequency
—
Butterworth: No ripple in either pass band or stop band; the steepest possible filter per order without any ripple
Chebyshev 1: Ripple in pass band, no ripple in stop band
Chebyshev 2: Ripple in stop band, no ripple in pass band
Elliptic: Ripple in both, steepest possible filter per order.

Filters with no ripple in the stop band rapidly block everything well below the noise floor. Filters with ripple in the stop band have to choose just how much erroneous is permissible. Sometimes a sharper filter is worth it.