Is there an emulator that can do fullscreen without tearing?

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.

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.)

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)).

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.

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!).

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.

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.

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.

RockNES has support for video triple buffering.

I ran into a similar problem with my emulator and screensaver: it seemed like Windows 7 was automatically dropping video frames; games would play back at the proper speed, sound was fine, for all intents and purposes the game was running full speed but the video was definitely not showing 60 FPS.

To solve this problem, I implemented a Direct2D renderer - previously I only supported GDI and DirectDraw, both of which exhibited this frame dropping problem under Win7. Somehow, someway, Direct2D works a lot better - I guess the driver code utilized by Direct2D (for my GPU) must somehow be different/better then whatever was running underneath DirectDraw + GDI.

I was able to do this in a way that does not force any hard dependencies on the emulator binary and DirectX, meaning the emulator can run fine on XP with an ancient version of DirectX; Direct2D is just not available in that case. If anyone is interested in knowing more I'll elaborate.

I myself also experience exactly koitsu and luke said. And i hate it to pure death
precisly 100% what luke said, no problems, no slowdown, nothing at all like that. JUST stutter

My best friend recently wanted me to try out a top of the line gaming PC he built, to replace this old outdated laptop im currently using.

It has Win 7, ATI Radeon 7970 Graphics Card (i think that's the lastest model released currently right now by AMD ??), im not sure what the CPU is, but AMD Phoenon 6-core something something. sorry i dont know exactly what it was called.

And when i go to test all my emulators and games. I notice this incredibly annoying as hell "micro stutter" happen in every single little thing i ever try.
NES emu's, snes, genesis, gameboy..
PC games like Rosenkreustillete, Megamari... just about anything.

It made me so mad cause it's impossible for me to really "enjoy" playing anything.

But on this really old outdated laptop im using. -
Win XP, Intel Core 2 Duo CPU, a dumb "integrated" video card. not dedicated

Everything performs so much "better" on here, stuff just "screen tears" until using vblank in programs/emu's. It's much more comfortable than that ridiculous micro-stuttering on the new comp.
I dont understand why the better comp performs so much worse compared to this laptop in my opinion.
I dont even use that comp because that stutter is so headache-inducing to me.
And then i read a wikipedia article that states, radeon 7970 supposedly is the MOST affected graphics card to date with the problem... dahhh

I just want a PC that doesn't do either stuttering or screen tearing period ever. It matters to me alot, just to be completely honest.

You would think it would matter to hardware/OS companies. Gaming is a big part of computing, and this stuff bugs a lot of people. I know it bugs me. Especially since these problems were ironed out in the DOS days. Why should it be so difficult now? VSync should be an easily accessible feature in any OS/software environment that might be used to make a game, and it shouldn't cause unnecessary stutter.

DOS wasn't multitasking. You could get away with just polling the vblank flag (VGA got rid of the vblank interrupt) and you would still be guaranteed that the moment it went from 0 to 1 vblank had just started.

Even then I find it weird, because I'm pretty sure vblank should work... Stuttering comes from the fact programs don't get a vblank-based timer anymore (and if you're doing fixed framerate, there isn't much use for it since the refresh rate can be anything), the closest you can get is the rendering thread stalling when it swaps the buffers with vsync on... and only when it never misses a vblank period.

Also reminds me, vsync doesn't work on multimonitor systems at all, because the OS insists on treating them like a single huge monitor, and the monitors aren't in sync (they may not even have the same refresh rate!). Kind of stupid, it'd make more sense to treat each monitor as a completely separate display... I guess we're stuck with this because when multimonitor support was added in Windows the concept of multiple workspaces was uncommon (also probably because programs were never made for multiple displays and there could have been something misbehaving horribly - remember Windows' backwards compatibility history).

On every platform I've ever developed for, modern or old, vsync has never been difficult at all for fullscreen applications.

Windowed applications are the opposite-- there is still no consistent solution for Windows. I am not certain if the situation is equally hopeless on other platforms (I've had conflicting reports-- also some people claim to be able to do it in Windows, but I have yet to see such an implementation that works for more than that one person).

As for getting rid of stutter, aside from generic issues like synchronizing audio and video, on Windows it is important to set your game's thread priority higher than default if you want it to run smoothly without stutter. If you fail to do this, it will be in competition with other running programs, because the OS is never given the hint that this game should be running more smoothly than the rest of the things you have running.

There is a corollary that it is also important to lower the thread priority when it is not needed (e.g. game minimized or paused) or at least have very low CPU usage during these times so that the user can get back their CPU when they want to run other programs temporarily.

I think this completely depends on the driver. If you're stuck with only copy on present (as opposed to swap on present), forget it.

It probably could be solved at the driver level, but that's completely outside the game programmer's control. Nobody wants to distribute thousands of hacked drivers with their game, and who would trust them enough to install them over the ones made by the manufacturer?

That said, on the driver side, I doubt it's as simple as swap vs copy when you're dealing with a windowed environment (and a copy can be vsynced just fine by the hardware if done properly). There's a lot of ways to skin that cat.

The problem is how much you can copy, especially being a standard blit instead of something that'd go through the usual rasterizer, and especially considering other programs may want to do exactly the same (I guess this is also why Direct2D fares better in this sense, it only uses the rasterizer, for pretty much everything).

WedNESday (hopefully to be released later this year) can do fullscreen AND windowed with no tearing.

I see different methodologies/implementations in every emulator, and use different settings in every emulator, to try and minimise (or completely subvert) tearing in windowed mode. Because I don't like being ambiguous, I'll give details. Again (because all of this data matters), I'm using Windows XP with an nVidia GTX 760 card, driver set 335.23, stock settings. CPU is an Intel i7-2600K.

Data point: Nestopia is the one emulator which rarely stutters or tears (maybe 1-2% of the time), so for playing actual games, it's what I use. And since I run in windowed mode, I tend to focus on 2x (linear) scaling because it adds to the "pixel" look and makes it easier on the eyes. I hate scalines and post-effect crap. Anyway, this is what I use:


There you go. I'd really recommend someone look into what VirtuaNES is doing with those two options checked...

I don't think it's even worth trying to get a vsync in windowed mode (there are lots of solutions that appear to work under the right conditions on a specific machine, but it really can't be done in a consistent/robust manner- there just has never been an API for it), but I'm certainly disappointed by emulators which fail to provide vsync in fullscreen mode. Every emulator should be able to do that; the ones that can't are simply doing it wrong, except in the case where the user's hardware settings have globally disabled vsync. It's a bit sad that you have to try so many permutations to get it working in a lot of emulators, but at least it can be done eventually most of the time.

I also get awful audio stuttering in FCEUX unless vsync is disabled. I use FCEUX for debugging/testing and making videos though, not for playing, so it's not a significant issue for me (maybe one of us should submit a bug report, though). Also, it seems like the audio buffer settings apply unless you restart, so that might explain why they seem to do nothing sometimes.

I've always found Nestopia to be the nicest one for just playing games. It always just worked properly for me in terms of setup/vsync/options. Lately I've become a fan of puNES as well, though it's in a less complete state.

Seeing as windowed VSYNC is nothing more than a short piece of code its definitely worth trying. Is using Present not consistent across machines?

I couldn't agree more with emulators that don't provide fullscreen VSYNC seeing as that is guaranteed.

BTW, I forgot of another emulator that seems to get windowed vsync correct (on XP) -- Fusion. No "special settings", just enable "Vsync" in the Video pulldown and that's it. Though that emulator does take up 15% CPU of my i7-2600K (pretty much one core maxed out at all times, even with Sleep-while-waiting enabled), still...

The README had this to say about it:

Yes, a wait loop should max out one core, by design.

That's one of many problems of trying to do windowed vsync that way:
1. wasting CPU polling the vsync
2. various factors may contribute to a fixed delay between vsync and your actual video update (causes a consistent tear)
3. windows may interrupt your program at a critical time anyway (causing an occasional tear)
4. the timing of your window's actual video update can be buffered/rescheduled by the operating system (making the vsync irrelevant)
5. vsync may not actually correspond to a real hardware state (in some cases it is just a dummy timer)
6. vsync may not signal at all, causing program to fail (rare)

All that said, sometimes you are getting a real vsync signal, and the conditions for timing are right, and you get a tear-free window. It's generally a matter of luck. Issue 1 you just have to live with if you want to use this method (and a good reason to make it optional). Issue 2 can be mitigated with a user configurable timer of some sort that inserts a delay between vsync and the video update, but this tends to be really fiddly. 3 is usually infrequent, occasionally very frequent. 4 and 5 are conditions that will make the effort entirely useless on that system. 6 is another reason it needs to be an option.

Actually, sometimes under lucky conditions the standard DirectX/OpenGL/Windows APIs for double buffering will appear to work in a window, and you'll get no tearing without the wasted CPU cycles. This is not guaranteed or even specified behaviour, but in some situations it does produce a consistent/stable timing with a tear-free result.


I've never liked the vsync poll method, because it's an out-of-spec solution that fails to work in a lot of cases (and the CPU load is a significant problem in itself). It's possible though that the hardware/driver situation is better than it used to be and maybe it works on more systems now? My own experience is certainly not a comprehensive survey.

FCEUX drives me absolutely BONKERS because it has persistent audio stuttering issues no matter which audio/video settings I choose. It's fine much of the time, but every now and then the audio will get noticeably stuttery and "garbled" for a few seconds and then go back to normal. It's like dragging fingernails down a chalkboard every time it happens. What's really odd is that the problem only manifests itself when it's outputting audio through my Sound Blaster X-Fi (and previously, my Audigy 2) - if I switch to the on-board SoundMAX, the problem goes away. The stuttering also occurs whether or not I disable desktop composition in the application's Compatibility tab (Windows 7's DWM forces its own Vsync on all programs when this is on).

Vsync also completely fails to work, but I have never, ever been able to make it work properly on any computer or OS. Someone really needs to overhaul the ancient audio/video code instead of constantly poking the UI and TAS-specific junk.

Relevant system specs:

AMD Phenom II X2 555 BE (3.2 GHz)
AMD Radeon HD 6770
Sound Blaster X-Fi Titanium PCI-E (or Analog Devices SoundMAX AD1988B, integrated)
Windows 7

Could you try my emulator ( how it vsync's )

Still working on the compatibility and stuff. But should run a considerable amount of games.

My emulator utilizes Direct2D for vsyncing.. Best results is offcourse obtained when the displayrefresh is set at 60Hz or multiple of it. (120/180/240hz/etc)

Since I run XP, Direct2D isn't available for me, only GDI is.

The emulator (maybe only in GDI mode?) takes up about 100% of one CPU core, so I see ~14-15% CPU at all times. FPS count in the emulator is 59-61 (usually 60) as it should be. As discussed previously with other emulators (ex. Fusion) that might be normal based on what your algorithm is. Does it tear? Occasionally, but not too often (maybe every 20 seconds of play, where the tearing gradually appears from the bottom and works its way up, then goes away).

It might be worth Emailing Steve Snake (author of Fusion) and ask exactly how he does his main loop + Vsync method. I'm betting he'd have some insights into doing audio/video synchronisation as well, which leads me to...

I did find other anomalies/oddities, but I'll post those in the other thread since they don't pertain to Vsync.