Mesen - NES Emulator

Discuss emulation of the Nintendo Entertainment System and Famicom.

Moderator: Moderators

Sour
Posts: 890
Joined: Sun Feb 07, 2016 6:16 pm

Re: Mesen - NES Emulator

Post by Sour »

fred wrote:I ran into issues with blargg's dmc-rates test and saw that subtracting 1 from the rate lookup table worked, but I don't understand why.
I'm putting this here because I see you did the same but with an explanation (DeltaModulationChannel.cpp - line 146), how does the real thing work?
As far as I know, the answer is in the comment above it (quoted from the wiki) - "The rate determines for how many CPU cycles happen between changes in the output level during automatic delta-encoded sample playback.".
So a value of 100 means the output changes every 100 cpu cycles. For the other channels, a value of 100 means it would change every 101 cycles. Since the clock divider logic is shared between all channels, I subtracted 1 from the DMC init value to match.
nothingtosay wrote:
Rahsennor wrote:Fixed a really goofy bug in my APU emulation, and now it sounds like this. Better?
Sounds pretty correct to me, I'm happy to report! :D Please share what you did and any other information relevant to achieving this.
I'd be interested to know as well - unfortunately it looks like your code isn't open source (yet?)
fred
Posts: 67
Joined: Fri Dec 30, 2011 7:15 am
Location: Sweden

Re: Mesen - NES Emulator

Post by fred »

Ohhhh. I see now! Thanks for the explanation!
User avatar
rainwarrior
Posts: 8731
Joined: Sun Jan 22, 2012 12:03 pm
Location: Canada
Contact:

Re: Mesen - NES Emulator

Post by rainwarrior »

nothingtosay wrote:I know that overall Nintendulator is less accurate than Mesen, at least according to the existing test ROMs
Test ROMs only test for very specific things, though. If there's no test ROM for something yet, it's probably a relatively unknown behaviour still, and any emulator, even one that seems "more accurate" than others, is liable to have arbitrary/random decisions applied to that grey area.

For example, NSFPlay seems to implement a free-running clock divider, but it implemented the 8-step sequence as a 16-step sequence instead of an additional division of the clock by 2, so it seems to be semi-correct, reducing the potential phase shift by half? When this was written there was no deliberate attempt here to get that particular behaviour correct, because it was unknown to the author. These were just decisions made to fill the "gaps" between the things that are known.

There's always more than one way to implement anything, and in terms of emulation "unknown" often means "doesn't appear to matter". You have to find a test case, ideally a test ROM, that can show you what the true behaviour should be.

Like, the 16-step sequence in NSFPlay is apparently wrong, but the original implementer did it that way, and it's taken many years to finally notice a case where it matters. Because I don't tend to change code that was already passing all of my own tests, I saw no reason to change it. Now I have a reason.
nothingtosay wrote:Nintendulator handles this particular edge case better.
Not necessarily. My point was that variation of SMB3 over time could easily be caused accidentally by something else, and it's possible that there are stable timings where it shouldn't change over time. This particular effect is very sensitive to a lot of things that SMB3 isn't any kind of control for.

Anyhow, just be wary of just looking at one particular example doing what you expect, and presuming this is correct. SMB3 was a good example for noticing this subtle effect exists, but it's not the proper tool to figure out exactly how to implement it correctly.
nothingtosay wrote:
rainwarrior wrote:(You mentioned a test case by Blargg, but I'm not certain if it's supposed to be a test of this specific thing either.)
I assume you were talking to me in this paragraph, but Sour was the one who brought up the APU test ROM.
Sorry for the confusion, I'm probably just conflating the whole conversation into one big "You". :P
nothingtosay wrote:I don't know the first thing about programming so I have no capability of making a test ROM for this. If I were able, it's definitely the kind of project I'd devote some time to.
I'll write my own test for it when I get back to NSFPlay, if someone else doesn't do it before then.
Rahsennor
Posts: 479
Joined: Thu Aug 20, 2015 3:09 am

Re: Mesen - NES Emulator

Post by Rahsennor »

nothingtosay wrote:Sounds pretty correct to me, I'm happy to report! :D Please share what you did and any other information relevant to achieving this.
Sour wrote:I'd be interested to know as well - unfortunately it looks like your code isn't open source (yet?)
Long story short, I was resetting the clock divider on writes to $4003 and $4007.

Short story long, that was a hack I added to pass the apu_mixer tests. Once I removed it, I eventually traced the real fault to a typo in the 8-step sequencer, postincrement instead of preincrement, meaning it was perpetually 45 degrees out of phase. And then I had to fix a trail of code that depended on the old functionality.

This is why my code isn't open source yet. I'd just be spreading the stupid. :roll: I can post my APU code anyway if you want it, but it's not very readable.
nothingtosay wrote:I don't know the first thing about programming so I have no capability of making a test ROM for this. If I were able, it's definitely the kind of project I'd devote some time to.
I have a few test ROMs in mind, for this and other stuff I haven't seen (good) tests for, but life has other plans for me at the moment.
User avatar
Eugene.S
Posts: 317
Joined: Sat Apr 18, 2009 4:36 am
Location: UTC+3
Contact:

Re: Mesen - NES Emulator

Post by Eugene.S »

Thank you, Sour. Bisqwit's NTSC-decoder is implemented.
Sour
Posts: 890
Joined: Sun Feb 07, 2016 6:16 pm

Re: Mesen - NES Emulator

Post by Sour »

Rahsennor wrote:Long story short, I was resetting the clock divider on writes to $4003 and $4007.
Yea, that's pretty much the issue I had and what I fixed as well.
Eugene.S wrote:Thank you, Sour. Bisqwit's NTSC-decoder is implemented.
This is now available in 0.7.0 along with AVI recording. Also, 0.6.1 was released last week with a few fixes and Linux support.
User avatar
feos
Posts: 108
Joined: Tue Apr 19, 2011 11:26 am
Location: RU

Re: Mesen - NES Emulator

Post by feos »

AVI dumper produces heavy av desync for me with both codecs (haven't tried uncompressed). The video looks sped up inconsistently.

Also, Sour, why didn't you make use of the constexpr functionality the same as it's used in Bisqwit's original method? That thing makes float calculations happen on compile time. Does moving them to happen only once per frame result in the same speed as if they were done via constexpr? And do you know if VS14 puts lambdas as inlines? Bisqwit said it matters.
Sour
Posts: 890
Joined: Sun Feb 07, 2016 6:16 pm

Re: Mesen - NES Emulator

Post by Sour »

Since you said both codecs, I'm guessing you compiled it yourself?
There is no desync on my end (just tried a ~45 secs video) - what are you using to play the AVI files? It is possible that the AVI header is not being generated with the right values and causing inconsistencies between players.

My implementation adds a bunch of filter settings (brightness, saturation, hue, etc.), so none of these values are actually known at compile time (so it's impossible to use constexpr). There was a small performance impact, but not that significant. They are only updated once per frame - which is not that much compared to rendering ~500k pixels at 8x res.

I'm pretty sure the lambdas are inlined - I cannot put breakpoints in them in release builds, which is usually caused by functions getting inlined by the compiler.
User avatar
feos
Posts: 108
Joined: Tue Apr 19, 2011 11:26 am
Location: RU

Re: Mesen - NES Emulator

Post by feos »

I recorded the video with the ntsc filter, and on my machine filter alone works at 20 fps, and with avi dumping it becomes even less. Try to make it lag and then record.

I tried x64 MPC on Win7, x86 MPC and VirtualDub on WinXP, they all give clear desync and/or video speed up for me.
Sour wrote:My implementation adds a bunch of filter settings (brightness, saturation, hue, etc.), so none of these values are actually known at compile time (so it's impossible to use constexpr).
You could also update them only when the values are changed by the user, I did that in fceux.
Sour
Posts: 890
Joined: Sun Feb 07, 2016 6:16 pm

Re: Mesen - NES Emulator

Post by Sour »

The ntsc filter at 4x while recording dropped to around 20fps on my end, but still recorded fine.
But the ntsc filter at 8x dropped to 2fps and that seemed to cause some issues (only recorded like 2 seconds worth though) - I'll test this some more later, thanks for letting me know!
feos wrote:You could also update them only when the values are changed by the user, I did that in fceux.
Yea, at the moment it recalculates them every frame - it's not that much of an overhead though. It's probably equivalent to < 0.1% of the time it takes to render the frame itself (at 8x at least). It's only this way because I forgot to implement that check, though - the code for the other NTSC filter does it, iirc.
User avatar
feos
Posts: 108
Joined: Tue Apr 19, 2011 11:26 am
Location: RU

Re: Mesen - NES Emulator

Post by feos »

What if Mesen outputs YUV signal directly instead of RGB? That will skip the decoding step and probably speed things up a bit. And in case you're using an index-based palette approach for the picture, you could generate YUV internally that way as well, with no need to encode initial RGB signal either.
Sour
Posts: 890
Joined: Sun Feb 07, 2016 6:16 pm

Re: Mesen - NES Emulator

Post by Sour »

feos wrote:What if Mesen outputs YUV signal directly instead of RGB?
That's actually a pretty good idea, but it looks like YUV texture support in DirectX11 is not available in Windows 7? Trying to use DXGI_FORMAT_AYUV fails on my computer, and most YUV-related formats have this note in the documentation: "Direct3D 11.1: This value is not supported until Windows 8."

An alternative seems to be to use a shader to perform the conversion - but I am mostly clueless about shaders (which is why they're still not supported in Mesen)
User avatar
feos
Posts: 108
Joined: Tue Apr 19, 2011 11:26 am
Location: RU

Re: Mesen - NES Emulator

Post by feos »

Is dx11 a hard requirement? Also I dunno how it's set up in Mesen, but won't it work like, say, in video players? They all can handle YUV on any machine.
Sour
Posts: 890
Joined: Sun Feb 07, 2016 6:16 pm

Re: Mesen - NES Emulator

Post by Sour »

feos wrote:Is dx11 a hard requirement? Also I dunno how it's set up in Mesen, but won't it work like, say, in video players? They all can handle YUV on any machine.
Replacing DX11 with something else would be a fair amount of work (especially since it would make no sense to just remove DX from the graphics code and keep using it for sound/gamepads). I'd rather not use SDL for the Windows version - I don't like having to ship an extra DLL with Mesen when I can easily use DX directly.

I did a tiny bit of research and noticed VLC has a "Use hardware YUV->RGB conversions" option - I tried to lookup some information about it, and ended up finding a bunch of threads by users having problems when the option is enabled.
LAV Video Decoder (which is what I apparently use for playback in MPC) on the other hand appears to be doing YUV->RGB translation in software

The filter runs at 60fps in 8x res on my 1st gen i5 (overclocked to ~3.4ghz), so I'm not sure why it runs at 20fps for you.
Are you using an even older CPU? Or maybe you're on a dual core CPU? A dual core would probably have a hard time since there are 4 threads working at the same time when using the NTSC filter (nes emulation, ntsc filter top half, ntsc filter bottom half and rendering with DX)
User avatar
feos
Posts: 108
Joined: Tue Apr 19, 2011 11:26 am
Location: RU

Re: Mesen - NES Emulator

Post by feos »

Running faster than full speed on my machine is an indication of a really fast emulator core (or filter). My computer is from 2008 (it was the cheapest one in the store).
Post Reply