nesdev.org

I've tried Jnes, FCEUX and Nestopia. I'm not sure if they have settings that will stop the tearing but by default they tear.

In FCEUX use fullscreen and set Sync Method in video settings to Wait for VBlank.

In Nestopia use fullscreen and check Vsync in the Timings setting.

FCEUX didn't work but Nestopia did. Thanks!

Is there a setting for VirtuaNES I can try? I get vertical and horizontal tearing on that one.

rainwarrior wrote:In FCEUX use fullscreen and set Sync Method in video settings to Wait for VBlank

VSync has never worked correctly for me in FCEUX on any computer.

If you use Linux with the proprietary nvidia drivers, any emulator will work without tearing.

I get a proper vsync in FCEUX only if hardware acceleration is enabled (there is a checkbox to disable hardware acceleration which must be clear).

Unfortunately, the "none" scaling filter seems to use bilinear interpolation when hardware acceleration is not disabled, which looks poor. For some reason, the vsync appears to be broken when hardware acceleration is disabled. So... either you can have a blurry image with vsync, or a clear image with tearing. Kind of a crummy trade. I should report this... (edit: has been fixed already in the interim build.)

khorven wrote:I've tried Jnes, FCEUX and Nestopia. I'm not sure if they have settings that will stop the tearing but by default they tear.

You didn't disclose what OS and graphics card (and driver version) you're using. This matters, believe it or not, especially in the case of Windows. Windows XP behaves differently than Vista than 7 (no idea about 8 (do not care)).

rainwarrior wrote:I get a proper vsync in FCEUX only if hardware acceleration is enabled (there is a checkbox to disable hardware acceleration which must be clear).

Unfortunately, the "none" scaling filter seems to use bilinear interpolation when hardware acceleration is not disabled, which looks poor. For some reason, the vsync appears to be broken when hardware acceleration is disabled. So... either you can have a blurry image with vsync, or a clear image with tearing. Kind of a crummy trade. I should report this...

Warning: NSFW language ahead (because koitsu is an angry panda today).

Re: blurry but has working vsync: it sounds like they use a hardware memory surface for "hardware acceleration" support, rather than a SystemMemory surface. Other emulators (see VirtuaNES and Nestopia) let you choose the surface type.

VirtuaNES also has a multitude of options that can help/make use of Vsync in windowed mode (talking about "Use HEL", "Use Sleep", and "Sync drawing"). I've been working on an updated English language plugin for VirtuaNES (well, a specific version of VirtuaNES actually) that cleans up all the Engrish (some of the items don't even make any sense).

The 4 emulators I use and what I use them for, since I get asked this a lot. I use Windows XP + nVidia GPUs, by the way:

* Nestopia -- for playing games or testing emulator compatibility
* VirtuaNES -- for playing games, doing glitch videos (special version of VirtuaNES), or testing emulator compatibility
* FCEUX -- for game dev or reverse-engineering
* Nintendulator -- for game dev or reverse-engineering

At least on XP, Nestopia seems to have the best Vsync model in windowed mode -- I get no stuttering or oddities (barring something in the background doing lots of I/O or causing lots of interrupts). However, with Windows 7 on the same machine (as in formatting C: and installing 7), I see periodic "stuttering" in Nestopia (and some other emulators). It's not quite a Vsync issue from what I can tell, and it's very very hard to describe. It's fucking annoying and is one of the literal hundreds of reasons why I stick with XP.

I don't use emulators in full-screen mode at all. In fact, in general I hate games that don't decently support windowed mode (Bethesda, I'm looking at you, you pricks) and for a lot of reasons. Some relate to legacy/historic idiotic design choices in emulators or games (shit everyone here has seen, I promise you -- anyone remember that Genesis emulators (Gens?) that actually changed/forced your desktop bitdepth to 16-bit, claiming "this is the only way to do it" and then later arguing "it's for speed"? Utter complete nonsense), others are present-day nonsense (for example trying to pick locks in Fallout 3 in windowed mode is like trying to shove a horse up your own asshole). One gaming company who seems to get windowed mode mostly correct (thank GOD!) is Blizzard.

The amount of "behavioual oddities" (with the UI, application, etc.) in FCEUX and Nintendulator are pretty major. It always makes me laugh when I see emulators (not just NES ones) where if you click a menu option while playing a game, the sound engine isn't told to halt, so you end up hearing a repeated looping noise (followed by there being 50 releases of the emulator where this idiocy is never addressed -- do the authors not actually use their own software?). Another one that still to this day doesn't make any sense are "pixel shift" anomalies in the rendering area when doing things like opening up a preferences menu (this is very hard to describe, it just looks like the visual rendering area where the game is suddenly "shifts" in one 4 quadrants by a pixel or two -- god I hate 3D crap!).

Either way, the latter two emulators get the job done and have great development features, but things like that are why I don't use them for general gameplay.

koitsu wrote:anyone remember that Genesis emulators (Gens?) that actually changed/forced your desktop bitdepth to 16-bit, claiming "this is the only way to do it" and then later arguing "it's for speed"? Utter complete nonsense

There was a reason for this: to avoid the 16-bit to 24/32-bit conversion when blitting, which was done in software. Emulators were hardcoded to output 16-bit colors. Of course, if you really wanted speed back then, you'd have gone fullscreen anyway - it was back in the day where rendering anything to a window involved a copy of the framebuffer to VRAM, and the only way to by-pass this was to go fullscreen (where DirectX would override the GDI - this is also the reason why many games would fail to support alt+tab properly when fullscreen, they would have to reinitialize the entire video system from scratch when that happened if they had supported it, not to mention reloading all the assets).

These days there isn't any reason to do it. Then again these days also there isn't any reason to use those inaccurate emulators either =P

EDIT: oh, and the pixel shifting thing you mention seems to depend completely on the video hardware. I noticed my Nvidia card never does it, but when I have to use some S3 integrated chip the issues would appear always (in fact the texture would never be aligned which results in a seam in diagonal across the screen!).

Sik wrote:Then again these days also there isn't any reason to use those inaccurate emulators either =P

I agree, provided you're using a desktop PC. Laptops or tablets with an Atom CPU may still need an emulator that's less accurate than Nintendulator or bsnes in order to keep full speed. I've found FCEUX to be an appropriate balance between speed and accuracy on my Dell netbook, and I just live with the tearing until I get home to my PowerPak.

The scaling issue has now been fixed in FCEUX, so you can get vsync and clean pixels at the same time. You can download the latest interim build (r2492) or just wait for the next version.

Vsync in FCEUX still only works if hardware acceleration is enabled, but with the scaling fixed there's no longer a reason to disable it.

koitsu wrote:I see periodic "stuttering" in Nestopia (and some other emulators). It's not quite a Vsync issue from what I can tell, and it's very very hard to describe. It's fucking annoying and is one of the literal hundreds of reasons why I stick with XP.

This is probably due to a delayed frame while waiting for the audio buffer to drain (a side of effect of generating audio and video at two different rates). It is fucking annoying.

Upgrade from XP and try nemulator . It dynamically adjusts the audio playback rate to match the video playback rate and the result is a tear-free/stutter-free experience.

EMUya also runs at 60fps tear free, stutter free. Its however currently only on the Ouya.

Zelex wrote:Its however currently only on the Ouya.

Which is the key. Consoles need to deal with only two SD (480i and 576i), two ED (480p and 576p), and two HD (720p and 1080p) output video modes, which have well-defined dot clocks. Ouya doesn't even have the SD or ED modes as I understand it. PCs, on the other hand, have to deal with a much wider variety of desktop and laptop monitors.